SSH-Zugriff verweigert bei externem Zugriff über DynDNS

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

    Quote from Dekar

    Die Portweiterleitung ist richtig eingerichtet, denke ich. Ansonsten könntest du dich überhaupt nicht mit dem Pi von außen verbinden. Es wird an einer lokalen Einstellung liegen. Neben der sshd_config wäre auch interessant, was der SSH-Daemon ausgibt:

    sudo journalctl -u ssh

    Das Kommando sollte auf deinem Pi existieren, auch beim Lite-Image von Raspbian, denn diese Kombination habe ich hier auch so auf einem Pi 3 installiert.

    Hat doch geklappt. Keine Ahnung, was das eben war:

    Hier ein Auszug aus den Ergebnissen:

    Was zur Hölle ist denn das ??? Wird der "von außen bombardiert" mit Anfragen oder wie darf ich diese Einträge interpretieren ?


    Quote

    Zum Testen nutze ich einfach Tethering bei meinem Smartphone. Komme also quasi von extern.

    Hast Du keinen Freund mit einem nativen IPv4-Internetanschluss, der den lauschenden Port das sshd aus dem Internet scannen könnte?

    Starte mal vor dem Verbindungsversuch mit dem Smartphone, auf deinem PI:

    Code
    sudo tcpdump -c 10 -vvveni <Interface> port 22 and not net <internes-Subnetz>

    (Interface und internes-Subnetz anpassen; ohne spitze Klammern). Wenn Du Bildschirm und Tastatur hast, kannst Du "

    Code
    and not net <internes-Subnetz>

    " aus dem Filter des tcpdump, weglassen.

    Wie ist nach dem Verbindungsversuch mit dem Smartphone, die Ausgabe von tcpdump?

    EDIT:

    Wie ist dein PI3 mit der FB-cable verbunden? Kabel oder WLAN?

    Ist in deiner FB-cable das QoS (... beim WLAN) aktiviert oder deaktiviert?

    Interessant. Dazu hätte ich eine Frage: Ist es an der Stelle unschädlich zwei SSH-Konsolen offen zu haben (sprich: 1x Putty SSH über internes Netz und 1x Putty SSH extern über Smartphone) ?

    Der PI3 ist mit Kabel zur FritzBox verbunden. Einstellungsoptionen für Qos fürs WLAN finde ich nicht in meinem Menü (FRITZ!OS:06.65)

    rpi444

    vor dem Verbindungsversuch :



    nach dem Verbindungsversuch:

    Sieht ziemlich gleich aus.... Deutet wohl darauf hin, dass hier doch nichts gefunkt wird, oder ?

    Quote from raspi_I

    rpi444

    vor dem Verbindungsversuch :



    nach dem Verbindungsversuch:

    Sieht ziemlich gleich aus.... Deutet wohl darauf hin, dass hier doch nichts gefunkt wird, oder ?

    Naja, ich weiß ja nicht ob Du den Filter richtig hattest. Versuch mal mit:

    Code
    sudo tcpdump -c 50 -vvveni eth0 port 22 and not net 192.168.178.0/24


    EDIT:

    ... oder mit:

    Code
    sudo tcpdump -c 50 -vvveni eth0 port 22 and not host 192.168.178.20

    Poste mal auch die Ausgabe von:

    Code
    sudo netstat -tlpena | grep -i :22

    von deinem PI.

    Quote from raspi_I

    Interessant. Dazu hätte ich eine Frage: Ist es an der Stelle unschädlich zwei SSH-Konsolen offen zu haben (sprich: 1x Putty SSH über internes Netz und 1x Putty SSH extern über Smartphone) ?

    Ja, das ist unschädlich.

    Quote

    Ich habe die o. g. Einstellungen mit "not host 192.168.178.0/24 und 192.168.178.10" verwendet. Es kommen keine Pakete an beim Zugriffsversuch. Beim Angeben von 192.168.178.10 (feste IP des PI3) kommt allerdings die Meldung:

    Wenn ich in den Filter 192.168.178.20 schreibe, warum ignorierst Du das und schreibst 192.168.178.10 rein?

    EDIT:

    ... und warum host wenn es ein net (.0/24) ist?

    Quote from raspi_I

    Kannst du bitte mal deine aktuelle Konfiguration angeben?

    Also Port "von aussen" und Port am RasPi für den ssh-Zugriff (nur die Ports, keine IPs und auch nicht deine DynDNS-Addresse

    Eingang FritzBox Port 22 - Weiterleitung auf Port 22 aufm Pi

    Ok, dann drehen wir uns im Kreis:

    Deine Fritzbox scheint ein Login auf Port 22 abzuweisen, das habe ich weiter oben schon vor Stunden geschrieben...

    Lass deinen RasPi so, wie er ist (Port 22), ändere die Portweiterleitung auf der FB zum Beispiel von Port 12345 auf Port 22 deines RasPi und connekte dich dann mit Angabe des Ports "12345" von aussen per DynDNS...

    Quote from rpi444

    Wenn ich in den Filter 192.168.178.20 schreibe, warum ignorierst Du das und schreibst 192.168.178.10 rein?

    EDIT:

    ... und warum host wenn es ein net (.0/24) ist?

    Sorry, dachte die .20 sollte stellvertretend für die IP-Adresse des Pi3 im Heimnetz stehen.

    Diesmal hat er Folgendes ausgespuckt beim Anmeldeversuch:

    Code
    16:20:23.218274 e0:28:6d:4c:83:71 > b8:27:eb:c2:5a:56, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 53, id 7598, offset 0, flags [none], proto TCP (6), length 44)
    62.183.127.123.15488 > 192.168.178.10.22: Flags [S], cksum 0x2ca4 (correct), seq 1293166645, win 35005, options [mss 1460], length 0
16:20:23.218386 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
16:20:24.279818 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
16:20:26.359807 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
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
    Quote from raspi_I

    Diesmal hat er Folgendes ausgespuckt beim Anmeldeversuch:

    Code
    16:20:23.218274 e0:28:6d:4c:83:71 > b8:27:eb:c2:5a:56, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 53, id 7598, offset 0, flags [none], proto TCP (6), length 44)
    62.183.127.123.15488 > 192.168.178.10.22: Flags [S], cksum 0x2ca4 (correct), seq 1293166645, win 35005, options [mss 1460], length 0
16:20:23.218386 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
16:20:24.279818 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
16:20:26.359807 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
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

    Der ssh-Client sendet ein syn und vom sshd-Server kommt 4x syn+ack. Der Client hätte schon auf den 1. syn+ack vom server, mit einem ack antworten müssen (was er aber nicht getan hat).

    Ich empfehle dir ssh (als Client) mit einer Linux-Live-CD/DVD, zum testen.

    Quote from raspi_I

    Was zur Hölle ist denn das ??? Wird der "von außen bombardiert" mit Anfragen oder wie darf ich diese Einträge interpretieren

    Korrekt. Das liegt insbesondere daran, dass du Port 22 von deiner Fritzbox weiterleitest. Genau dieser Port wird immer systematisch von Bots überprüft. In diesem Fall kommt die IP aus China und man hat versucht, sich als "root"-Nutzer im System einzuloggen. Ich würde also den Tipp von Zentris befolgen und in der Fritzbox einen anderen Port auf den 22-Port vom Pi zu mappen.

    Zum eigentlichen Problem: Du könntest auch mal zum Test den Router neu starten, falls du das noch nicht getan hast. Das hat bei mir in einigen Fällen mit seltsamen Fehlern schon geholfen. Ansonsten wie von rpi444 vorgeschlagen einfach mal einen anderen SSH-Client verwenden.

    Änderung des ssh Ports bremst ScriptKiddies aber keine Profis. Trotzdem würde ich auch den Port ändern. Aber es natuerlich nicht bei diesen Sicherungsmassnahmen alleine belassen :!:

    Also nochmal: Änderung des Ports ist keine Sicherheitsmaßnahme, sondern eine Verschleierungsmaßnahme. Diese Maßnahme dennoch anzuwenden bleibt dir natürlich unbenommen! Aber allein hier schon von einer Absicherung zu sprechen führt komplett in die Irre. Das mag auf den ersten Blick seltsam erscheinen, aber nur weil ihr die Versuche von Logins im Log seht, heißt das ja nicht, daß das System unsicher ist. Es heißt nur, daß da jemand versucht entweder den Rechner oder dessen Netz auf Lücken abzuklopfen. Ob da Lücken sind, entscheidet sich nicht nach dem Port an dem ein Dienst läuft. Und wenn euch die Logeinträge stören, könnt ihr wahlweise rsyslogd instruieren die ins Nirwana zu schicken (würde ich zwar nicht empfehlen, aber wenn's einen so richtig juckt, ist das eine Methode) oder über fail2ban oder meinen oben beschriebenen Ansatz die Anzahl der Versuche die ein Angreifer bei euch hat so stark zu begrenzen, daß es euch eben nicht mehr juckt.

    Es gibt übrigens noch einen netteren Weg um Verbindungen zu einem SSH-Daemon zu debuggen als mit tcpdump. Also, nehmen wir mal an du hast dich auf deinen RPi im internen Netz verbunden. Jetzt richtest du deinen Router so ein, daß der Port 1022 des RPi (weiterlesen nicht vergessen!) auf einen Port der externen Adresse umgeleitet wird, auf den du ihn haben willst. Ist mir ja wumpe ob du nun den Port umbiegst. Wichtig ist, daß du verstehst daß es sich dabei um keine Sicherheitsmaßnahme handeln würde.

    Jetzt zum Port 1022. Du läßt deinen SSH-Server so laufen wie er es schon tut (Port 22) und startest eine zweite Instanz (als Root!), aber im Vordergrund und am Port 1022.

    Code
    $(which sshd) -Ddp 1022

    Der Befehl nimmt an, daß du Bash oder eine kompatible Shell einsetzt welche `$()` versteht. Was tut der Befehl nun? `which sshd` ermittelt den absoluten Pfad zu sshd ... und mit `$(which sshd)` fügst du genau diesen ermittelten Pfad als erstes in deine Kommandozeile ein. Du kannst es stattdessen je nach Distribution auch mit /usr/sbin/sshd versuchen. Kann klappen, muß aber nicht. Warum brauchen wir das? Nunja, sshd verweigert bei Aufruf ohne absoluten Pfad in manchen Konfigurationen den Dienst.

    Dann `-D` welches dafür steht daß sich sshd nicht als Daemon (Hintergrundprozeß) in den Hintergrund verabschiedet. `-d` um Debugausgaben zu erhalten. Da kannst du bis zu drei kleine d aneinanderreihen, also bspw. `-ddd` und zuguterletzt `-p 1022` welches sshd anweist an dem besagten Port zu lauschen.

    Läuft das Teil und ist dein Router entsprechend konfiguriert den Port weiterzuleiten, schaust du dir einfach die Ausgaben des sshd auf dem Terminal an, denn da werden nun jede Menge Ausgaben auftauchen, sobald sich ein Client von extern verbindet.

    Achtung: bei dieser Methode beendet sich der Daemon nachdem die Verbindung getrennt wurde. Der muß also manuell (z.B. über deine Terminalverbindung im internen Netz) wieder gestartet werden um noch einen Versuch zu unternehmen. Usw. usf. ... man kann sich mit der Methode also bei unbedachter Anwendung aussperren!

    Diese Methode kann man im übrigen auch hervorragend bei allerlei anderen Problemen mit sshd einsetzen. Habe damit schon die exotischsten Probleme in kurzer Zeit gelöst. Einzige Vorbedingungen sind 1.) ein alternativer Weg sich auf den Server einzuloggen um sshd zu starten (dazu kann man einfach den sshd auf dem Standardport laufenlassen) und 2.) falls man den Standardport weiter benutzt, ein anderen Port als 22 der zum Start der zweiten sshd-Instanz benutzt werden kann.

    Wenn ihr schnell hilfreiche Antworten wollt, lest bitte diesen Artikel (Fehlerberichte - wie Sie Softwarefehler melden sollten) und beherzigt die darin enthaltenen Ratschläge. Herzlichen Dank!

    Quote from raspi_I
    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

    Poste mal von deinem PI auch die Ausgaben von:

    Code
    nc -zv 9.9.9.9 53
nc -zv heise.de 80
ping -c 3 -W 2 9.9.9.10
sudo iptables -nvx -L

    rpi444 statt `iptables -nvxL` kann man auch `iptables-save` (gern auch mit `-c`) nehmen. Persönlich finde ich das sogar übersichtlicher, aber ich weiß daß andere das nicht immer so sehen. Aber als ich es das erste Mal benutzt hatte, schien es mir deutlich angenehmer als die Alternative, zumal ich so auch gleich die NAT-Tabelle zu sehen bekomme, für die man bei der von dir gezeigten Methode noch `-t nat` anfügen muß (und dann aber ausschließlich die NAT-Tabelle sieht).

    Wenn ihr schnell hilfreiche Antworten wollt, lest bitte diesen Artikel (Fehlerberichte - wie Sie Softwarefehler melden sollten) und beherzigt die darin enthaltenen Ratschläge. Herzlichen Dank!

    Quote from Assarbad

    ..., zumal ich so auch gleich die NAT-Tabelle zu sehen bekomme, für die man bei der von dir gezeigten Methode noch `-t nat` anfügen muß (und dann aber ausschließlich die NAT-Tabelle sieht).

    Ja, das ist alles richtig und bekannt was Du da schreibst, aber ich will die NAT-Regeln (wenn es welche hier gibt?) (noch) nicht sehen. Eigentlich geht es mir nur um evtl. Regeln in der OUTPUT chain:

    Code
    sudo iptables -nvx -L OUTPUT

    Für mich ist die Ausgabe von "iptables -nvx -L" in diesem Fall, übersichtlicher als die Ausgabe von "iptables-save -c".

    Moin,

    ich habe probiert eine Portweiterleitung auf meiner Fritzbox einzurichten (jeweils einmal den Port 1022 und dann 12357 (>9999) als Eingangsport auf der FB und dann Weiterleitung auf Port 22 des RPI)

    Ich habe, nach Einrichtung der entsprechenden Portweiterleitung die FB neu gestartet und auf der Webseite dyndnss.net ein Update durchgeführt.

    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.

    ____________________________________________________________________________________________________________________

    Hier noch die fehlenden Dateiauszüge bzw. der Versuch eines alternativen SSH-Client:

    (folgt gleich)

Participate now!

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

Register Yourself Login