SSH-Server beantwortet keine Verbindungsanfragen

Ich versuche, mit OpenSSH einen SSH-Server auf meinem lokalen Computer einzurichten. Wenn ich versuche, von einem Remotehost auf meinen lokalen SSH-Server eine SSH-Verbindung herzustellen, antwortet der SSH-Server nicht und die Anforderung läuft ab. Ich bin mir ziemlich sicher, dass es eine wirklich offensichtliche Lösung dafür gibt, die ich einfach übersehen habe.

Folgendes passiert, wenn ich versuche, SSH von einem Remote-Host aus auszuführen:

yoshimi@robots:/$ ssh -vv volt@99.3.26.94
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.94ist mein lokaler SSH-Server.

SSH wird ausgeführt

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 - es wird direkt in das Apache-Webverzeichnis gewechselt. Port 22 - nicht so sehr.

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.94ist mein lokaler SSH-Server.

Es ist nicht IPTables (ich denke)

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 ein relativ frisches Debian-Netzwerk.

Also dann: Was könnte es noch sein? Es scheint auf jeden Fall eine Art Firewall zu sein, um den Datenverkehr einfach zu ignorieren, aber wenn es nicht der Router ist, dann sind es keine iptables und es ist keine weitere Firewall auf dem SSH-Server. Was zum Teufel gibt es noch?

BEARBEITEN: Verbindungsanforderung von internem Netzwerkfehler

yoshimi@robots:/$ ssh volt@192.168.1.90
ssh: connect to host 192.168.1.90 port 22: No route to host

Eine sehr enttäuschende Selbstantwort

Nachdem ich dieses Problem für einen Tag beiseite gelegt hatte und darauf zurückkam, war ich erleichtert und beunruhigt (eher beunruhigt als erleichtert), als ich feststellte, dass alles auf mysteriöse Weise richtig funktionierte.

Also, was war das Problem?

Es wurden keine Einstellungen geändert oder angepasst - nicht auf dem Router, nicht auf dem SSH-Server und nicht auf dem Computer des SSH-Clients. Man kann mit ziemlicher Sicherheit sagen, dass der Router den eingehenden Datenverkehr trotz der richtigen Einstellungen nicht ordnungsgemäß verarbeitet. Angesichts der Tatsache, dass dinky Home Router-Software nicht wirklich für die Portweiterleitung ausgelegt ist, hat der arme Kerl eine Weile gebraucht , um die notwendigen Änderungen umzusetzen.

Aber es ist wie 6 Stunden gewesen !!

Ja Alter, ich weiß. Ich verbrachte den ganzen Tag versucht , herauszufinden , was falsch war - und nicht immer es finden , weil es nicht war etwas nicht in Ordnung. Offensichtlich kann es 6 Stunden - möglicherweise länger - dauern, bis die Router-Einstellungen wirksam werden.

Woher weiß ich, ob dies mein Problem ist?

Ein nützliches Werkzeug, das mir bei dieser Eskapade begegnet ist, ist tcpdump. Dieser schlanke kleine Kerl schnüffelt nach Verkehr und bietet wertvolle Einblicke in die tatsächlichen Vorgänge. Außerdem hat er einige hervorragende Filterfunktionen, mit denen Sie genau eingrenzen können, wonach Sie suchen. Zum Beispiel der Befehl:

tcpdump -i wlan1 port 22 -n -Q inout

Tells tcpdumpsuchen Verkehr über die wlan1 - Schnittstelle ( -i= ‚Schnittstelle‘), nur über Port 22, ignoriert DNS - Namensauflösung ( -n= 'no - Namensauflösung), und wir wollen sowohl ein- und ausgehenden Datenverkehr sehen ( -Qnimmt in, outoder inout; inoutist die Standardeinstellung).

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

1. Wenn eingehender Datenverkehr vom Remotecomputer, aber kein ausgehender Datenverkehr vom lokalen Server angezeigt wird, liegt das Problem beim Server: Möglicherweise muss eine Firewall-Regel geändert werden usw.
2. Wenn Sie sowohl eingehende als auch ausgehende Daten sehen , Ihr Remotecomputer jedoch keine Antwort erhält, ist dies höchstwahrscheinlich der Router: Er lässt den eingehenden Datenverkehr zu, verwirft jedoch Ihre ausgehenden Pakete.
3. Wenn überhaupt kein Datenverkehr vorhanden ist, liegt wahrscheinlich auch ein Routerproblem vor: Die SYNPakete des Remotecomputers werden vom Router ignoriert und verworfen, bevor sie überhaupt Ihren Server erreichen.

Und sobald Sie herausgefunden haben, wo das Problem liegt, ist eine Lösung (normalerweise) trivial.

Ich verwende Mint (Ubuntu).

Ich hatte alles getan ... öffentlicher Schlüssel im richtigen Format in authorized_keys, chmodding, chowning, ssh und sshd neu starten usw. Wie alles überall dokumentiert wurde.

Für mich war es die ufw Firewall. Das Fehlen einer SSH-Antwort hat mich darauf aufmerksam gemacht, aber ich konnte kein Problem in beide Richtungen in einem LAN anpingen.

Ich habe getestet von:

sudo ufw service stop

... und es hat perfekt funktioniert, dh ich habe eine Antwort von einem SSH-Anruf erhalten.

Also starte ufw nochmal:

sudo ufw service start

... und füge die Regel hinzu:

sudo ufw allow openssh

Alles funktioniert jetzt gut.

Wenn Sie wie ich UFW aktiviert haben (in meinem Fall unter Linux Ubuntu), versuchen Sie Folgendes:

sudo ufw enable OpenSSH

Dies ermöglicht OpenSSH in der Firewall.

Nur für andere:

Ich musste die Option -P in tcpdump anstelle von -Q verwenden

tcpdump -i wlan1 port 22 -n -P inout

Die meiste Zeit ist Firewall ein Schuldiger. Tun service iptables stopund service ip6tables stop.

Wenn das Beenden des Dienstes nicht funktioniert, führen Sie eine iptable-Spülung durch.

iptables --flush.

Wenn es sich um eine VM handelt, machen Sie dasselbe auch im Host