PuTTY zeigt Verbindungszeitüberschreitung an: Ursachen finden

PuTTY zeigt Netzwerkfehler: Verbindungstimeout an? Beim Öffnen der Sitzung bedeutet das, dass innerhalb der erwarteten Zeit keine nützliche Antwort empfangen wurde. Die Adresse oder der Port könnten falsch sein, der Netzwerkpfad könnte nicht erreichbar oder asymmetrisch sein, oder ein Gerät könnte die Pakete unbeantwortet lassen. In diesem Stadium sind das Passwort und der SSH-Schlüssel noch nicht betroffen.

Ein Verbindungsabbruch ist etwas anderes: Die TCP-Verbindung wurde abgelehnt, beispielsweise durch einen Port ohne Dienst oder durch ein inter inkommunierendes Gerät. Diese Ablehnung beweist allein noch nicht, dass der richtige Server geantwortet hat. Für diesen anderen Aspekt, siehe das Diagnoseverfahren für Connection refused in PuTTY. Das Handbuch beschreibt offiziell den PuTTY-Timeout als das Fehlen einer Antwort vom Server und erwähnt insbesondere einen isolierten oder abgeschalteten Server und eine zu überprüfende Adresse. Es wird auch darauf hingewiesen, dass ein Timeout nach einem Verlust der Verbindung während einer Sitzung auftreten kann: Dieser Leitfaden konzentriert sich auf das Öffnen der Sitzung.

Verfahren Sie, ohne den Server blind zu ändern: Überprüfen Sie zuerst das Ziel und den Pfad von Windows aus und vergleichen Sie diese Beobachtungen mit dem Hören, dem Rückweg und der Filterung auf der Linux-Seite. Für Serverbefehle verwenden Sie eine unabhängige Konsole, die vom Anbieter, VM oder physischen Zugriff bereitgestellt wird. Lassen Sie alle bereits offenen SSH-Sitzungen unberührt.

Identifizieren Sie den Timeout, bevor Sie etwas ändern

Notieren Sie den exakten Text, der von PuTTY angezeigt wird, die Uhrzeit mit Zeitzone, die verwendete Sitzung, den Hostnamen, den Port und die Stelle, an der der Fehler auftritt. Achten Sie auch darauf, ob Sie über einen in PuTTY konfigurierten Proxy, ein VPN oder einen Bastion gehen. Die im PuTTY-Event-Log verfügbaren Details können helfen, den versuchten Pfad und die Adresse zu bestätigen.

• Timeout beim Öffnen: Es wurde keine nützliche Antwort innerhalb der Zeit empfangen. Das deutet auf Adresse, Routing oder stilles Filtern hin, ohne diese Ursachen voneinander zu unterscheiden.
• Connection refused: Der Pfad hat eine TCP-Ablehnung erhalten. Überprüfen Sie das spezielle Kapitel zum Verbindungsabbruch.
• Server hat unseren Schlüssel abgelehnt: Der Transport hat die Authentifizierungsstufe erreicht; es ist ein anderer Ausfall. In diesem Fall können Sie den Leitfaden zur Verwendung eines SSH-Schlüssels mit PuTTY konsultieren.
• Eine etablierte Sitzung wird nach einer Inaktivitätszeit unterbrochen: Das ist nicht dasselbe wie ein Timeout beim Öffnen. Zählen Sie nicht auf eine Keepalive-Einstellung, um einen anfänglichen, nicht antwortenden TCP-Pfad zu beheben.

Überprüfen Sie nicht universell eine Dauer in PuTTY: Eine längere Wartezeit behebt weder einen fehlenden Pfad noch ein gefiltertes Paket.

Überprüfen Sie die Adresse, den DNS und den tatsächlich veröffentlichten Port

Öffnen Sie die in PuTTY gespeicherte Sitzung und überprüfen Sie den Host und den Port in den SSH-Einstellungen. Das Hostfeld enthält einen Namen oder eine Adresse, keine URL mit https://. Bestätigen Sie diese Werte beim Administrator oder in der Konsole des Anbieters, bevor Sie sie ersetzen. Um die Felder einer Sitzung zu überprüfen, folgen Sie den Einstellungen einer SSH-Sitzung in PuTTY.

In PowerShell ersetzen Sie server.example.net durch den validierten Namen und 22 durch den tatsächlich veröffentlichten externen TCP-Port für Ihren Zugriff. Diese Werte sind Beispiele, nicht die Parameter Ihres Servers.

Resolve-DnsName server.example.net -Type A
Resolve-DnsName server.example.net -Type AAAA
Test-NetConnection -ComputerName server.example.net -Port 22 -InformationLevel Detailed

Die ersten beiden Befehle zeigen separat die durch die DNS-Auflösung erhaltenen IPv4-Adressen (A) und IPv6-Adressen (AAAA). Vergleichen Sie die zurückgegebene Adresse mit der erwarteten Adresse in der Konsole des Anbieters. Ein AAAA-Eintrag kann PuTTY einen anderen IPv6-Pfad als den IPv4-Pfad nutzen lassen. Die Microsoft-Dokumentation zu Test-NetConnection beschreibt das TCP-Ergebnis und die Routendiagnose.

Im detaillierten Ergebnis von Test-NetConnection notieren Sie insbesondere RemoteAddress, SourceAddress, InterfaceAlias und TcpTestSucceeded. Sie können separat eine bereits validierte Adresse testen, um ein Problem bei der Auflösung von einem TCP-Ausfall zu unterscheiden. Verwenden Sie keine zufällig gefundene Adresse und akzeptieren Sie keinen neuen Host-Schlüssel ohne zuverlässige Überprüfung.

• TcpTestSucceeded: True bedeutet, dass dieser Test TCP zu diesem Ziel, diesem Port und diesem Pfad zu diesem Zeitpunkt erfolgreich hergestellt hat. Dies überprüft jedoch nicht die SSH-Identität des Servers. Wenn PuTTY weiterhin fehlschlägt, vergleichen Sie die verwendete Adresse und den Port, den möglicherweise vorhandenen Proxy und die Sitzungseinstellungen.
• TcpTestSucceeded: False weist auf einen TCP-Testausfall hin, unterscheidet jedoch allein nicht zwischen einem Timeout und einer Ablehnung, noch lokalisiert es den Verlust. Bewahren Sie die exakte Meldung von PuTTY auf und fahren Sie mit den Überprüfungen fort.

Eine private Adresse ist im Allgemeinen nur über das vorgesehene Netzwerk oder ein VPN mit dem richtigen Pfad erreichbar. Im Falle von NAT kann der vom Client verwendete Port von dem internen Port, der gehört wird, abweichen: Beispielhaft kann ein konzeptioneller externer Port 2222 auf den internen Port 22 umgeleitet werden. Lassen Sie diese Zuordnung bestätigen; ersetzen Sie diese Beispiele nicht durch angenommene Werte. Leeren Sie nicht reflexartig den DNS-Cache: Tun Sie dies nur, wenn ein obsoletes lokales Eintrag nachgewiesen wurde.

Vergleichen Sie Windows-, VPN- und Netzwerkpfade

Überprüfen Sie das aktive Netzwerk, den Zugang zum erwarteten VPN oder Bastion, die Routen und die verwendete Quelladresse. Wenn PuTTY über einen Proxy geht, validiert ein direkter PowerShell-Test diesen Proxy nicht: Die beiden Versuche nehmen dann nicht unbedingt denselben Pfad.

Die folgenden Befehle sind Lesevorgänge auf der Windows-Seite. Ersetzen Sie für tracert 192.0.2.20 durch die Adresse eines Servers, den Sie testen dürfen. 192.0.2.20 ist eine Adresse, die für Dokumentationsbeispiele reserviert ist, nicht die tatsächliche Adresse Ihres Servers.

ipconfig
route print
Test-NetConnection -ComputerName server.example.net -DiagnoseRouting -InformationLevel Detailed
tracert -d 192.0.2.20

ipconfig und route print helfen dabei, die lokalen Schnittstellen und Routen aufzuzeichnen. -DiagnoseRouting fordert eine Routendiagnose an; dies ist ein separates Parameter-Set vom Test mit -Port, kombinieren Sie die beiden nicht im selben Befehl. tracert zeigt einzelne Etappen der Route an, aber Sterne können einfach anzeigen, dass keine ICMP-Antworten zurückgesendet werden. Sie bezeichnen mit einiger Sicherheit nicht das Gerät, das SSH blockiert. Ebenso beweist ein erfolgreicher Ping nicht, dass SSH zugänglich ist, und ein fehlgeschlagener Ping beweist nicht, dass der Server abgeschaltet ist.

Wenn dies erlaubt ist, vergleichen Sie denselben Host und denselben Port von einem anderen Netzwerk, wobei die anderen Parameter unverändert bleiben. Ein Erfolg über einen Hotspot deutet beispielsweise auf einen Unterschied im Pfad, der Quelle oder den Berechtigungen im ersten Netzwerk hin; es beweist jedoch nicht automatisch, dass der Internetanbieter den Port 22 blockiert. Eine Liste von erlaubten Quelladressen kann diesen Unterschied erklären. Überprüfen Sie die ausgehenden Windows-Regeln und die Netzwerkrichtlinien mit dem Administrator. Deaktivieren Sie weder die Firewall noch das Antivirusprogramm und umgehen Sie keine Netzwerkpolitik.

Überprüfen der Dienste und der Rückroute von Linux aus

Führen Sie diese Lesevorgänge von der unabhängigen Konsole des Servers aus und nicht im fehlerhaften PuTTY-Fenster aus. Ersetzen Sie 192.0.2.10 durch die Quelle, die der Server tatsächlich sieht, nach NAT oder VPN. 192.0.2.10 ist eine Dokumentationsadresse, die ersetzt werden muss, keine reale Client-IP. Für ein IPv6-Ziel verwenden Sie ip -6 route get mit der beobachteten IPv6-Adresse.

ip -br address
ip route
ip route get 192.0.2.10
sudo ss -ltnp
systemctl list-unit-files 'ssh*' --no-pager
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

ip -br address fasst die Adressen der Schnittstellen zusammen; ip route zeigt die IPv4-Routen an und ip route get gibt den gewählten Weg zur Quelle an, die erreicht werden soll. Vergleichen Sie diesen Weg mit dem tatsächlichen Pfad: Das Vorhandensein einer Standardroute beweist nicht, dass die Antwort den Client erreicht. In einer Distribution, in der die Binärdatei nicht unter /usr/sbin/sshd liegt, passen Sie den bekannten Pfad an, anstatt auf dessen Fehlen zu schließen.

ss -ltnp zeigt die profilen TCP-Sockets an, die je nach Berechtigung mit dem zugehörigen Prozess verknüpft sind. Überprüfen Sie den internen Port und die Höradresse: Ein Hören, das auf 127.0.0.1 beschränkt ist, ist von außen nicht erreichbar. Ein Hören auf [::] garantiert nicht allein die IPv4-Zugänglichkeit. Die öffentliche IP-Adresse eines Servers hinter NAT erscheint nicht unbedingt auf seinen Linux-Schnittstellen.

Identifizieren Sie die tatsächlich verwendete Diensteinheit, bevor Sie deren Status überprüfen. Je nach Distribution kann sie ssh.service oder sshd.service heißen; die Aktivierung über Sockets kann ssh.socket verwenden. Eine unbekannte Einheit bedeutet daher nicht unbedingt, dass SSH fehlt. Überprüfen Sie nur die aktualisierte Einheit, zum Beispiel:

systemctl status ssh.service --no-pager

Ersetzen Sie ssh.service durch die vorhandene Einheit. Das Handbuch von OpenSSH für sshd beschreibt -t als eine Überprüfung der Konfiguration und der Schlüsselübereinstimmung und -T als Anzeige der effektiven Konfiguration. Diese Optionen starten den Dienst nicht neu. Die Regeln Match können von den Verbindungseinstellungen abhängen; -T allein beweist daher nicht die für jeden Client geltende Konfiguration. Bei einer Aktivierung über Sockets beachten Sie auch das tatsächliche Hören mit ss und die Socket-Einheit.

Die Direktiven ListenAddress und Port legen Adressen und Ports zum Hören in der Konfiguration fest; sie garantieren weder das Routing noch eine Firewallregel noch die Veröffentlichung des Ports durch das NAT. Ein nicht hörender Port produziert oft eine Ablehnung, wenn das Paket ohne stilles Filtern den Host erreicht: Schließen Sie daher nicht darauf, dass jedes Timeout bedeutet, dass der SSH-Dienst gestoppt ist.

Den Filter vor Ort identifizieren, ohne SSH für ganz Internet zu öffnen

Identifizieren Sie die tatsächlich verwendete Firewall, bevor Sie deren Regeln interpretieren. Diese Befehle sind Lesevorgänge und sind möglicherweise nicht alle in Ihrer Distribution verfügbar:

sudo ufw status verbose
sudo nft list ruleset
sudo firewall-cmd --get-active-zones

Wenn firewalld aktiv ist, überprüfen Sie anschließend die tatsächlich mit dem Interface verbundene Zone, indem Sie ZONE durch ihren Namen ersetzen:

sudo firewall-cmd --zone=ZONE --list-all

Ein fehlender Befehl beweist nicht, dass kein Filtern existiert: Eine Regel könnte in einem anderen Manager, auf einem Router oder beim Anbieter vorliegen. Kombinieren Sie keine Firewall-Manager, um die Störung zu beheben.

Überprüfen Sie für die Regel, die dem beobachteten Pfad entspricht, das TCP-Protokoll, den internen Port, die vom Server gesehene Quelladresse, die Reihenfolge der Regeln und die Aktion. Eine Regel DROP kann die Verbindung unbeantwortet lassen; eine REJECT-Regel kann je nach Art der Ablehnung zu einer Ablehnung führen. Überprüfen Sie auch die Sicherheitsgruppen oder Cloud-Firewalls, die Route des Anbieters, den Router, die NAT-Umleitung, das VPN und gegebenenfalls CGNAT. Ein Test der öffentlichen Adresse aus dem LAN hängt insbesondere von der Unterstützung von NAT-Loopback ab; eine Umleitung funktioniert nicht zwingend hinter einem CGNAT.

Ändern Sie nur eine Regel oder einen Pfad, die durch die Beobachtungen identifiziert wurden, und beschränken Sie die Quelle auf die erforderlichen Adressen. Öffnen Sie den Port nicht standardmäßig auf 0.0.0.0/0 und verschieben Sie SSH nicht als automatische Umgehung auf Port 443.

Kreuzen Sie die Protokolle und eine kurze TCP-Aufzeichnung

Überprüfen Sie die Protokolle um die notierte Zeit herum und passen Sie die Einheit an die tatsächlich verwendete an:

sudo journalctl -u ssh.service --since '10 minutes ago' --no-pager

Ersetzen Sie ssh.service durch die vorhandene Einheit, wie sshd.service oder, je nach Fall, ssh.socket. Einige Distributionen protokollieren auch Ereignisse in /var/log/auth.log oder /var/log/secure. Ein Timeout, das vor dem SSH-Austausch auftrat, hinterlässt möglicherweise keinen Authentifizierungseintrag: Ein leeres Protokoll beweist nicht, dass kein Versuch unternommen wurde.

Wenn tcpdump und GNU timeout verfügbar sind und Sie das Erfassen autorisiert sind, ersetzen Sie die Port- und Adresse mit dem internen Port und der Quelle, die der Server tatsächlich sieht. Starten Sie die Erfassung kurz vor einem neuen PuTTY-Versuch:

sudo timeout 10 tcpdump -ni any -c 20 'tcp port 22 and host 192.0.2.10'

In diesem Befehl sind Port 22 und 192.0.2.10 dokumentarische Beispiele, die durch die beobachteten Werte ersetzt werden müssen, keine Daten Ihres Problems. Die Erfassung stoppt nach zehn Sekunden oder nach zwanzig Paketen. Verwenden Sie nicht die Optionen -A oder -X und lassen Sie keine dauerhafte Erfassung laufen. Maskieren Sie Adressen, bevor Sie eine Ausgabe teilen.

• Kein SYN am beobachteten Punkt: Überprüfen Sie nach der Überprüfung der Schnittstelle, des Erfassungsfilters, der Zeit und der Quelladresse das Ziel, den Weg oder ein Vorgeschaltetes Filtern. Dies beweist nicht allein, dass eine Cloud-Firewall den Verkehr blockiert.
• SYN erhalten, keine Antwort beobachtet: Überprüfen Sie das lokale Filtern, das Hören und die Erfassungsbedingungen. Beschuldigen Sie sshd nicht ohne weiteren Beweis.
• SYN empfangen, dann SYN-ACK gesendet, aber kein ACK am Ende sichtbar: Überprüfen Sie den Rückweg oder ein Filtern auf Seiten des Clients/intermediär. Eine Erfassung auf Serverseite lokalisiert nicht endgültig den Verlust.
• SYN gefolgt von einem RST: Sie befinden sich im Bereich der TCP-Ablehnung; überprüfen Sie das Diagnoseverfahren für Connection refused.
• Vollständiger TCP-Handshake: TCP funktionierte zu diesem Zeitpunkt. Vergleichen Sie die Erfassung mit dem PuTTY-Versuch, dem Proxy und dem erreichten SSH-Schritt. Dies beweist weder die Identität des Servers noch eine erfolgreiche Authentifizierung.

Beheben Sie eine nachgewiesene Ursache und validieren Sie, ohne SSH abzubrechen

Führen Sie vor jeder Änderung eine Backup des betreffenden Files durch und stellen Sie sicher, dass Sie über eine Sicherungskonsole verfügen. Nehmen Sie jeweils nur eine Änderung vor: Korrigieren Sie das Ziel der Sitzung, den VPN-Pfad oder die spezifische Regel, die die Tests in Frage gestellt haben. Wenn Sie keine unabhängige Konsole haben, stoppen Sie die Änderungen aus der Ferne und übermitteln Sie die Ergebnisse an den Administrator.

Ändern Sie nicht die Schlüssel, Passwörter, PermitRootLogin oder SSH-Algorithmen, um ein netzwerkloses Schweigen vor der Authentifizierung zu beheben. Wenn Sie die SSH-Konfiguration ändern, lassen Sie zunächst sshd -t erfolgreich sein, und verwenden Sie dann das von der Einheit und Verteilung unterstützte Nachladen, nachdem Sie deren Funktion überprüft haben. Ein Neustart oder Reboot ist kein erster Test, und ein Nachladen behebt nicht unbedingt eine systemd-Socket, die schlecht freigegeben ist.

Führen Sie niemals ufw disable, nft flush ruleset oder iptables -F aus. Stoppen Sie nicht blind Fail2ban, öffnen Sie SSH nicht für alle Quellen und schließen Sie nicht die alte Sitzung, bevor Sie die Funktionalität validiert haben.

Nach einer Korrektur lassen Sie die Konsole und die alte Sitzung geöffnet. Testen Sie in einem neuen PuTTY-Fenster denselben Host, denselben Port und denselben Pfad. Überprüfen Sie den SSH-Fingerabdruck über einen zuverlässigen Kanal, fahren Sie bis zur Authentifizierung fort und bestätigen Sie, dass eine Sitzung funktioniert. Wenn die Meldung Connection refused wird, kehren Sie wieder zu diesem Bereich zurück, anstatt die Timeout-Diagnose fortzusetzen.

Um Hilfe zu bitten, übermitteln Sie die Zeit, den Host und den Port, die aufgelösten Adressen und die Quelladresse, den VPN-/Proxy-Pfad, die TCP-Ergebnisse und die Beobachtungen auf der Serverseite sowie die verdächtige Regel. Entfernen Sie sensible Adressen und Informationen. Präsentieren Sie keine nicht ausgeführte Befehlsausgabe als Ergebnis.