☰

SSH stellt keine Verbindung her – Zeitüberschreitung beim Vorgang

tag-icon • tag-icon ssh osx-yosemite ubuntu-14.04
SSH stellt keine Verbindung her – Zeitüberschreitung beim Vorgang

Seit heute Morgen erhalte ich die folgende Fehlermeldung, wenn ich versuche, eine Verbindung zu meiner Fernbedienung herzustellenUbuntu 14.04 LTSMaschine über sshvon einemMacBook Air Yosemite 10.10.1.

ssh_exchange_identification: read: Operation timed out

Bei Verwendung -vvvder Flagge erscheint die folgende ausführliche Meldung

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: identity file /Users/felix/.ssh/id_rsa type -1
debug1: identity file /Users/felix/.ssh/id_rsa-cert type -1
debug1: identity file /Users/felix/.ssh/id_dsa type -1
debug1: identity file /Users/felix/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Operation timed out

Viele Monate lang funktionierte diese Verbindung einwandfrei. Ich hatte nie Probleme. Andere Lösungen wie gefundenHierUndHierhat nicht geholfen.

Irgendwelche Vorschläge, wie dieses Problem behoben werden kann?

Antwort1

debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Operation timed out

Laut Ihrer Debug-Ablaufverfolgung können Sie eine Verbindung zum Remote-SSH-Server herstellen, und der Server trennt die Verbindung nicht, sendet jedoch seine Software-Identifikationszeichenfolge nicht. Dies ist das Erste, was Client und Server tun, und es geschieht im Klartext.

Ich glaube, das Problem lässt sich auf eines von drei Dingen reduzieren:

  1. Ein Netzwerkgerät zwischen Ihnen und dem Server stört die Verbindung. Wenn sich der Remote-Host beispielsweise hinter einem NAT-Router befindet, ist die Portweiterleitung für Port 22 möglicherweise falsch eingerichtet und Sie stellen eine Verbindung zum falschen Dienst her.

  2. Das SSH-Serverprogramm auf dem Remote-Host hängt möglicherweise oder funktioniert nicht richtig. Ich habe beispielsweise schon erlebt, dass so etwas passiert, wenn der Host stark überlastet ist oder nur wenig virtuellen Speicher hat. Oder der Server verwendet möglicherweise etwas wieTCP-Wrapper, und es führt eine DNS-Abfrage an Ihre Client-IP durch, deren Auflösung sehr lange dauert.

  3. Der Remote-Host ist ungewöhnlich eingerichtet und der auf Port 22 ausgeführte Dienst ist kein SSH-Server.

Wenn Sie auf den Server zugreifen können, konzentrieren Sie Ihre Fehlerbehebung dort. Suchen Sie die Protokolle für den SSH-Server – sie sollten vorhanden sein, /var/logund prüfen Sie, ob etwas über diese fehlgeschlagenen Verbindungsversuche protokolliert wurde. Versuchen Sie, SSH vom Server aus auf den lokalen Host auszuführen, und prüfen Sie, ob das ordnungsgemäß funktioniert.

Wenn Sie Root-Zugriff auf den Server haben, können Sie versuchen, eine Debug-Instanz von zu starten, sshdum zu sehen, was protokolliert wird, wenn Ihr Client eine Verbindung herstellt. Halten Sie den normalen sshdServer an und führen Sie in einem Root-Terminalfenster aus /path/to/sshd -d. Dadurch wird eine Kopie von sshd ausgeführt, die eine Verbindung akzeptiert und Debug-Informationen in das Terminalfenster druckt. Versuchen Sie, das Problem zu reproduzieren, und untersuchen Sie dann, was der Server protokolliert hat.

Wenn Sie den normalen SSH-Server nicht offline nehmen können, können Sie SSHD auf einem anderen Port ausführen: /path/to/sshd -p 42 -dführt eine Kopie von SSHD aus, die auf Port 42 lauscht. Geben Sie beim Ausführen des SSH-Clients dieselbe Portnummer an: ssh -p 42 user@host. Wenn Ihre Probleme auf ein störendes Netzwerkgerät zurückzuführen sind, kann sich dieses anders verhalten als Verbindungen zu Port 22.

verwandte Informationen