SSH-Server antwortet nicht auf Verbindungsanforderung

Question

Ich versuche, mit OpenSSH einen SSH-Server auf meinem lokalen Rechner einzurichten. Wenn ich versuche, von einem Remote-Host aus per SSH auf meinen lokalen SSH-Server zuzugreifen, antwortet der SSH-Server nicht und die Anforderung läuft ab. Ich bin ziemlich sicher, dass es dafür eine offensichtliche Lösung gibt, die ich einfach übersehen habe.

Folgendes passiert, wenn ich versuche, mich per SSH von einem Remote-Host aus anzumelden:

yoshimi@robots:/$ ssh -vv [email protected]
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 99.3.26.94 [99.3.26.94] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 99.3.26.94 port 22: Connection timed out
ssh: connect to host 99.3.26.94 port 22: Connection timed out

Wo robotsist mein Remote-Host und 99.3.26.94mein lokaler SSH-Server?

SSH läuft

volt@arnold:~$ ps -A | grep sshd
 5784 ?        00:00:00 sshd

Wo arnoldist mein lokaler SSH-Server?

Die Portweiterleitung ist auf dem Router eingerichtet

Ich habe meinen Heimrouter so eingerichtet, dass er die Ports 80 und 22 an meinen SSH-Server weiterleitet. Interessanterweise funktionierte Port 80 problemlos – er führt direkt zum Apache-Webverzeichnis. Bei Port 22 war das nicht so.

NMap sagt, es ist gefiltert

yoshimi@robots:/$ nmap -p 22 99.3.26.94

Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-02 14:45 EDT
Nmap scan report for 99-3-26-94.lightspeed.bcvloh.sbcglobal.net (99.3.26.94)
Host is up (0.33s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

Wo robotsist mein Remote-Host und 99.3.26.94mein lokaler SSH-Server?

Es sind nicht IPTables (glaube ich)

volt@arnold:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

… Und ich habe keine anderen Firewalls installiert – es ist eine relativ neue Debian-Netzwerkinstallation.

Also dann:Was könnte es sonst sein?Das Ignorieren des Datenverkehrs scheint sicherlich eine Art Firewall-Problem zu sein, aber wenn es nicht am Router, nicht an iptables und auch nicht an einer anderen Firewall auf dem SSH-Server liegt, ... was zum Teufel gibt es dann sonst noch??

BEARBEITEN: NetStat-Serverausgabe

Vom SSH-Server:

tcp6       0      0 :::22                   :::*                    LISTEN      5784/sshd       

Answer 1

Eine sehr enttäuschende Selbstantwort

Nachdem ich dieses Problem einen Tag lang beiseite gelegt und mich dann wieder damit befasst hatte, war ich sowohl erleichtert als auch beunruhigt (eher beunruhigt als erleichtert), als ich feststellte, dass auf mysteriöse Weise alles richtig funktionierte.

Also, was war das Problem?

Es wurden keine Einstellungen geändert oder angepasst – weder am Router, noch am SSH-Server und nicht am Computer des SSH-Clients. Man kann ziemlich sicher davon ausgehen, dass der Router den eingehenden Datenverkehr trotz der richtigen Einstellungen nicht richtig verarbeitet hat. Angesichts der Tatsache, dass die Software für Heimrouter nichtWirklichDa es für die Portweiterleitung konzipiert ist, hat der arme Kerl eine Weile gebraucht, um die notwendigen Änderungen umzusetzen.

Aber es sind schon 6 Stunden vergangen!!

Ja, Alter, ich weiß. Ich habe den ganzen Tag damit verbracht, herauszufinden, was los war – und habe es nie gefunden, weil eswar nichtirgendetwas ist falsch. Offensichtlich kann es 6 Stunden – möglicherweise länger – dauern, bis die Routereinstellungen wirksam werden.

Woher weiß ich, ob dies mein Problem ist?

Ein raffiniertes Tool, das ich bei diesem Ausflug entdeckt habe, ist tcpdump. Dieser kleine, schlanke Kerl überwacht den Verkehr für Sie und bietet wertvolle Einblicke in das, was tatsächlich vor sich geht. Außerdem verfügt er über einige tolle Filterfunktionen, mit denen Sie genau eingrenzen können, wonach Sie suchen möchten. Zum Beispiel der Befehl:

tcpdump -i wlan1 port 22 -n -Q inout

Gibt an tcpdump, dass nach Datenverkehr über die Schnittstelle wlan1 ( -i= „Schnittstelle“) gesucht werden soll, nur über Port 22, die DNS-Namensauflösung ignoriert werden soll ( -n= „keine Namensauflösung“) und sowohl eingehender als auch ausgehender Datenverkehr angezeigt werden soll ( die Standardeinstellung -Qlautet in, out, oder inout; inout).

Wenn Sie diesen Befehl auf Ihrem SSH-Server ausführen, während Sie versuchen, eine Verbindung über einen Remote-Computer herzustellen, wird schnell klar, wo genau das Problem liegt. Es gibt im Wesentlichen 3 Möglichkeiten:

1. Wenn Sie seheneingehendDatenverkehr von der Remote-Maschine, aberkein ausgehenderDatenverkehr von Ihrem lokalen Server, liegt das Problem beim Server: Wahrscheinlich gibt es eine Firewall-Regel, die geändert werden muss usw.
2. Wenn Sie sehensowohl eingehende als auch ausgehende, aber Ihr Remote-Computer erhält keine Antwort, liegt es höchstwahrscheinlich am Router: Er lässt den eingehenden Datenverkehr zu, verwirft jedoch Ihre ausgehenden Pakete.
3. Wenn es gibtüberhaupt kein Verkehr, handelt es sich wahrscheinlich ebenfalls um ein Routerproblem: Die SYNPakete des Remote-Computers werden vom Router ignoriert und gelöscht, bevor sie überhaupt Ihren Server erreichen.

Und wenn Sie erst einmal herausgefunden haben, wo das Problem liegt, ist die Lösung (normalerweise) trivial.