☰

SSH zum Remote-Server hängt, funktioniert aber lokal (Putty/Cygwin/Windows 10 zu Linux)

tag-icon • tag-icon networking ssh cygwin putty
SSH zum Remote-Server hängt, funktioniert aber lokal (Putty/Cygwin/Windows 10 zu Linux)

Ich habe einen Linux-Server, auf dem OpenSSH läuft. Ich kann sowohl vom lokalen LAN als auch remote eine Verbindung herstellen. Es gibt jedoch einen Client (einen Windows 10-Laptop), der nur lokal eine Verbindung herstellen kann. Wenn ich versuche, eine Remote-Verbindung herzustellen, wird die Authentifizierung akzeptiert, aber der SSH-Client auf dem Laptop hängt und muss mit Process Explorer beendet werden. Ich dachte, das Problem könnte sein:

  1. Windows-Firewall – Nö. Habe sie ausgeschaltet, aber das gleiche Verhalten.
  2. SSH-Client (Cygwin) – Nein. Mit Putty ist das gleiche Verhalten aufgetreten.
  3. Windows 10 – Nein. Ich kann erfolgreich eine Remoteverbindung von einem anderen Win10-Computer aus herstellen.

Ich habe eine Neuinstallation von Cygwin und Putty versucht.

Ich habe versucht, ssh mit mehreren -v-Optionen auszuführen und die Ausgabe mit der des anderen Win10-Rechners zu vergleichen, der eine Verbindung herstellen kann. Die Ausgabe war bis zu einem gewissen Punkt identisch:

Authenticated to <<IP REMOVED>>.
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

>>>  "bad" machine hangs here

debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome to Linux Mint 17.3 Rosa (GNU/Linux 3.19.0-32-generic x86_64)

Welcome to Linux Mint

In seltenen Fällen ist es weitergegangen – ein- oder zweimal sogar bis zur Willkommensnachricht – aber die Verbindung reagiert nie auf Tippeingaben.

Ich habe versucht, sshd -d manuell auf dem Server auszuführen und die Ausgabe zwischen einer „schlechten“ Remote-Sitzung und einer „guten“ von einem anderen Client zu vergleichen. Die Ausgabe ist identisch.

Zusammenfassend: Es scheint nicht an der Windows-Firewall, der Client-Software, Win10, der Portweiterleitung zum Server, DNS oder dem Server selbst zu liegen. Das Problem betrifft nur diesen einen Client-Rechner und nur, wenn eine Verbindung von außerhalb des lokalen LANs hergestellt wird. Die Authentifizierung ist erfolgreich. Und auf dem Client-Rechner läuft derselbe OS/SSH-Client wie auf einem anderen Rechner, der das Problem nicht hat, und ich kann auch in den Protokollen nichts finden, was ihn von dem anderen unterscheidet.

EDIT: Ich sollte auch erwähnen, dass die SSH-Verbindung zu anderen Remote-Servern von allen Maschinen aus einwandfrei funktioniert. Es scheint nur dieses Server/Client-Paar zu sein und nur bei einer Remote-Verbindung.

UPDATE: Weitere Informationen finden Sie in meinen Kommentaren direkt weiter unten – das Problem scheint nur das lokale Netz zu betreffen.

Welche weiteren Schritte kann ich unternehmen, um das Problem zu beheben?

Antwort1

Für mich sieht es so aus, als ob an dem Punkt, an dem es hängt, keine TCP-Pakete vom Server mehr den Client erreichen. Ich denke, das liegt daran, dass es manchmal an verschiedenen Punkten hängt und das Problem je nach Netzwerkkonfiguration unterschiedlich ist. Es könnte sich beispielsweise um eine unerwünschte Interaktion zwischen Portweiterleitung, NAT und/oder Firewalls handeln. Die Frage ist jedoch, wie man diagnostiziert, warum dies bei einem Client passiert, bei einem anderen jedoch nicht. Mir fallen zwei Ansätze ein:

  • Du könntest es versuchenPaketüberwachungauf Server und Client und an verschiedenen Punkten entlang der Route, um zu prüfen, ob und an welchen Punkten tatsächlich Pakete verloren gehen.

  • Sie können experimentieren, um zu versuchen, eine Beziehung zwischen Netzwerkeinstellungen und dem Vorhandensein oder Nichtvorhandensein des Problems auf verschiedenen Clients zu finden. Tauschen Sie alle oder einige Netzwerkeinstellungen und IP-Adressen zwischen einem funktionierenden und einem nicht funktionierenden Client aus, um zu sehen, ob das Problem dadurch behoben wird.

verwandte Informationen