SSH-Zugriff verweigert bei externem Zugriff über DynDNS

    Quote from raspi_I

    Ein Portscan ergab in beiden o. g. Fällen, dass der Port geblockt war. Ein Verbindungsaufbau mit Putty "Network error; Connection refused".

    Funktioniert also augenscheinlich nicht.

    Du hast jetzt eine neue/andere Baustelle aufgemacht. Der sshd-Server war über den Port 22, aus dem Internet erreichbar.

    M. E. wäre es besser gewesen, den Fehler weiter zu suchen ... und wenn der Fehler gefunden ist, kannst Du noch immer auf einen anderen Port umstellen.

  • SSH-Zugriff verweigert bei externem Zugriff über DynDNS? Schau mal ob du hier fündig wirst!

    Nur zur Sicherheit: Du musst natürlich den Port im SSH-Client (also Putty) auf 1022 bzw. 12357 ändern, wenn du dich mit der externen IP verbindest. :)

    Quote from Dekar

    Nur zur Sicherheit: Du musst natürlich den Port im SSH-Client (also Putty) auf 1022 bzw. 12357 ändern, wenn du dich mit der externen IP verbindest. :)

    Schon klar ;)

    Geht trotzdem net.

    ________________________

    Update: Hab den Port nun wieder auf (FB:22 -> RPI:22) gelegt. - @rpi44: Ich finde auch, dass ich mich lieber erstmal auf mein Hauptproblem konzentrieren sollte. Portverlegung dann lieber später.

    Auch mit MobaXTerm als alternativem Client geht es nicht.

    Edited 2 times, last by raspi_I (December 10, 2017 at 1:54 PM).

    Quote from fred0815

    Was hast du denn jetzt, IPv4, IPv6, oder echtes DualStack ?

    Warst du mal da und hast getestet ?

    https://www.wieistmeineip.de/ipv6/

    Nun ja, ich hatte DS-Lite. Dann habe ich mit Vodafone gesprochen und habe mir IPv4 einrichten lassen.

    Laut Übersicht ist die FB über IPv4 und IPv6 verbunden.

    Dynamic DNS ist aktiviert:

    aktiviert, bmrpi.dyndnss.net, IPv4-Status: angemeldet

    Und funktioniert auch: Auf dyndnss.net wird mir meine aktuelle Router IPv4 auch angezeigt.

    Code
    16:20:30.439822 b8:27:eb:c2:5a:56 > e0:28:6d:4c:83:71, ethertype IPv4 (0x0800), length 58: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    192.168.178.10.22 > 62.183.127.123.15488: Flags [S.], cksum 0x3104 (incorrect -> 0x0255), seq 4188292934, ack 1293166646, win 29200, options [mss 1460], length 0

    Mit einem Linux-ssh-Client könnte man jetzt feststellen, ob die syn+ack-Antwort des sshd-Servers, bei dem Client ankommt.

    Quote from rpi444
    Code
    16:20:30.439822 b8:27:eb:c2:5a:56 > e0:28:6d:4c:83:71, ethertype IPv4 (0x0800), length 58: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    192.168.178.10.22 > 62.183.127.123.15488: Flags [S.], cksum 0x3104 (incorrect -> 0x0255), seq 4188292934, ack 1293166646, win 29200, options [mss 1460], length 0

    Mit einem Linux-ssh-Client könnte man jetzt feststellen, ob die syn+ack-Antwort des sshd-Servers, bei dem Client ankommt.

    Ja ok. Dann probier ich es mal mit ner Live-CD.

    Update:

    Kurzfassung: Hat auch nicht geklappt.

    Langfassung: Hab Desinfect gebootet , ne Konsole geöffnet, dann via ssh benutzername@domain -p 22 versucht zu verbinden.

    Nachdem ich diese (erstmalige) Zertikatanfrage mit Yes beantwortet habe und meinen Benutzernamen eingegeben habe, bin ich wieder (analog zu Putty, MobaXterm) bei der Passwortüberprüfung gescheitert ("Permission denied").

    Edited once, last by raspi_I (December 10, 2017 at 3:09 PM).

    Quote from raspi_I

    Langfassung: Hab Desinfect gebootet , ne Konsole geöffnet, dann via ssh benutzername@domain -p 22 versucht zu verbinden.

    Nachdem ich diese (erstmalige) Zertikatanfrage mit Yes beantwortet habe und meinen Benutzernamen eingegeben habe, bin ich wieder (analog zu Putty, MobaXterm) bei der Passwortüberprüfung gescheitert ("Permission denied").

    Ja, aber so hast Du noch nicht festgestellt, ob die syn+ack-Antwort vom Server beim Client auch angekommen ist.

    Versuch mal auf dem Linux-Client (zum richtigen Zeitpunkt) mit:

    Code
    sudo tcpdump -c 30 -vvven 'tcp[tcpflags] & (tcp-syn) != 0 and tcp src port 22'

    Wi-Fi_Signal_Strength  txpower
    iptables chains order scheme iptables-diagram
    nftables-diagram

    Meine PIs

    PI4B/8GB (border device) FreeBSD 15.1R-p1 (arm64): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI4B/4GB FreeBSD 14.4R-p7 (arm64): SSH-Serv., WireGuard-Serv., ngircd-Serv., Mumble-Serv., ddclient

    PI4B/8GB Bookworm-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

    Edited once, last by rpi444 (December 10, 2017 at 3:38 PM).

    Quote from raspi_I

    Ja. Anmelden geht einwandfrei.

    Evtl. vom Linux-Client auch mit:

    Code
    ssh -vvv benutzername@domain -p 22

    (für zusätzliche/ausführliche Infos) versuchen.

    Quote from rpi444

    Ja, aber so hast Du noch nicht festgestellt, ob die syn+ack-Antwort vom Server beim Client auch angekommen ist.

    Versuch mal auf dem Linux-Client (zum richtigen Zeitpunkt) mit:

    Code
    sudo tcpdump -c 30 -vvven 'tcp[tcpflags] & (tcp-syn) != 0 and tcp src port 22'

    Würde das praktisch so aussehen ?:

    LIveCD starten.

    Konsole öffnen "sudo tcpdump........" starten

    2. Konsole öffnen "ssh ......." starten

    Anschließend die Auswertung in der 1. Konsole

    Quote from raspi_I

    Würde das praktisch so aussehen ?:

    LIveCD starten.

    Konsole öffnen "sudo tcpdump........" starten

    2. Konsole öffnen "ssh ......." starten

    Anschließend die Auswertung in der 1. Konsole

    Ja, und die "verbose" Ausgabe (-vvv) in der 2. Konsole beachten bzw. nicht vergessen.

    Erledigt !

    Hier sind die Ausgaben von ssh:


    und tcpdump:

    Code
    17:14:19.119704 8c:1a:bf:af:b4:bb > 18:a6:f7:61:88:18, ethertype IPv4 (0x0800), length 74: 
(tos 0x0, ttl 48, id 0, offset 0, flags [DF], proto TCP (6), length 60)

78.46.37.55.22 > 192.168.43.127.59564: Flags [S.], cksum 0xacb4 (correct), seq 3545369893, ack 3845689052, 
win 5792, options [mss 1360,sackOK,TS val 2440943528 ecr 360183,nop,wscale 7], length 0
    Quote from raspi_I

    Erledigt !

    OK. Vergleiche mal an deinem Vodafone-Anschluss (d. h. auf deinem PI3), die Ausgaben von:

    Code
    dig +short myip.opendns.com @208.67.222.222
dig +short bmrpi.dyndnss.net @9.9.9.9

    Sag mal, du hast doch gesagt, dass du den Pi 3 mit Debian Stretch Lite benutzt. Wieso erscheint im Log vom SSH-Client als "remote protocol version" dann OpenSSH 5.5p1 (Debian Squeeze)?

    Code
    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze4
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze4 pat OpenSSH_5* compat 0x0c000000

    Bei mir (Pi 3, Debian Stretch Lite) wird eine ganz andere Version angegeben:

    Code
    debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u1
debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u1 pat OpenSSH* compat 0x04000000

    Bist du dir sicher, dass du auf die richtige lokale IP-Adresse weiterleitest?

    Quote from Dekar

    Wieso erscheint im Log vom SSH-Client als "remote protocol version" dann OpenSSH 5.5p1 (Debian Squeeze)?

    Weil es evtl. nicht sein PI3 war:

    Code
    whois $(dig +short bmrpi.dyndnss.net @9.9.9.9) | grep -i address
address:        Hetzner Online GmbH
address:        Industriestrasse 25
address:        D-91710 Gunzenhausen
address:        Germany
remarks:        * abuse@hetzner.de, not this address. *
address:        Industriestrasse 25
address:        D-91710
address:        Gunzenhausen
address:        GERMANY
    Quote from rpi444

    OK. Vergleiche mal an deinem Vodafone-Anschluss (d. h. auf deinem PI3), die Ausgaben von:

    Code
    dig +short myip.opendns.com @208.67.222.222
dig +short bmrpi.dyndnss.net @9.9.9.9

    Die jeweiligen Einträge verweisen tatsächlich auf unterschiedliche IPv4-Adressen:

    Ausgabe myip.opendns.com war 77.23.156.5

    Ausgabe bmrpi.dyndnss.net ist die aktuelle IPv4 (78.46.37.55) welche die FB bezogen hat und die bei dyndnss.net hinterlegt ist..

    Hat dies was damit zu tun dass es dauern kann bis die DNS-Einträge quasi in den diversen DNS-Servern eingetragen werden ??

    Quote from rpi444

    Weil es evtl. nicht sein PI3 war:

    Code
    whois $(dig +short bmrpi.dyndnss.net @9.9.9.9) | grep -i address
address:        Hetzner Online GmbH
address:        Industriestrasse 25
address:        D-91710 Gunzenhausen
address:        Germany
remarks:        * abuse@hetzner.de, not this address. *
address:        Industriestrasse 25
address:        D-91710
address:        Gunzenhausen
address:        GERMANY

    Aber wie soll das denn möglich sein ?? Dann hätte ich diese Domain doch gar nicht bei dyndnss.net anmelden können ???

    Quote from raspi_I

    Aber wie soll das ...

    Hast Du auf deinem PI3, die Ausgaben von:

    Code
    dig +short myip.opendns.com @208.67.222.222
dig +short bmrpi.dyndnss.net @9.9.9.9

    verglichen?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login