SSH: Connection Refused oder Timed Out?

Was „Connection refused“ und „Connection timed out“ bei SSH bedeuten

Eine verweigerte SSH-Verbindung und eine abgelaufene SSH-Verbindung sind gegensätzliche Fehler. Die Lösung für den einen Fehler behebt daher nie den anderen. „Refused“ bedeutet, dass Ihr Paket den Server erreicht hat und der Kernel des Servers mit „hier lauscht nichts“ geantwortet hat. „Timed out“ bedeutet, dass Ihr Paket niemanden erreicht hat, der antworten konnte. Ihr Client hat gewartet und den Versuch anschließend abgebrochen. „Refused“ ist ein Dienstproblem auf dem Server. „Timed out“ ist ein Pfadproblem vor dem Server.

Lesen Sie die genaue Zeile, die Ihr Client ausgibt. Ihre Formulierung liefert die vollständige Diagnose.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

Der zeitliche Ablauf ist der zweite Hinweis. „Refused“ wird sofort zurückgegeben, ungefähr innerhalb der Zeit für einen Roundtrip. Bei „Timed out“ vergeht viel Zeit, bevor die Meldung ausgegeben wird, weil der Client das Paket vor dem Abbruch wiederholt sendet. macOS gibt für denselben Zustand Operation timed out aus. Wenn das Protokoll für Sie neu ist, finden Sie unter wie SSH funktioniert und was sshd tut die Hintergrundinformationen, die dieser Leitfaden voraussetzt.

Warum „Connection refused“ eine gute Nachricht ist

„Refused“ ist ein TCP-Reset (Transmission Control Protocol). Ihr Client sendet ein SYN-Paket an Port 22. Es durchquert das Internet und erreicht den Netzwerk-Stack des Servers. Der Kernel findet an diesem Port keinen lauschenden Socket und antwortet daher mit einem RST- (Reset-)Paket. Ihr SSH-Client wandelt dieses RST in die Meldung Connection refused um.

Dieses eine zurückgesendete Paket belegt bereits viel. Die Adresse ist korrekt. Der Host ist eingeschaltet und über das Routing erreichbar. Auf dem Übertragungsweg verwirft nichts den Datenverkehr zu diesem Port still, weil vom entfernten Ende eine Antwort zurückgekommen ist. Alle verbleibenden Ursachen liegen daher auf dem Server selbst.

• sshd läuft nicht, weil der Start fehlgeschlagen ist oder der Dienst nie aktiviert wurde.
• sshd lauscht an einem anderen Port, meist nach einer Änderung an der Härtung.
• sshd ist an eine einzelne Adresse gebunden, beispielsweise ListenAddress 127.0.0.1. Daher kann nur der Server selbst diese Adresse erreichen.
• Eine Firewall ist so konfiguriert, dass sie Verbindungen zurückweist statt sie zu verwerfen. Daher sendet die Firewall im Namen des Hosts das RST. Sowohl die ufw-Aktion reject als auch eine nftables-Regel, die mit reject with tcp reset endet, bewirken dies.

Ein weiterer Fall sieht ähnlich aus, ist aber keiner: Sie haben eine Adresse eingegeben, die zu einem anderen aktiven Host gehört. Dieser Host antwortet auf Ihr SYN, hat keinen SSH-Dienst an Port 22 und weist die Verbindung ordnungsgemäß zurück. Bestätigen Sie die Adresse, bevor Sie eine Stunde am falschen Server verbringen. Wenn Sie wissen, was ein lauschender Port unter Linux tatsächlich ist, lässt sich der Rest dieses Abschnitts schneller erfassen.

Verbindung mit „Connection refused“ beheben

Dieses Problem können Sie nicht über SSH beheben, weil SSH selbst nicht funktioniert. Öffnen Sie die Webkonsole oder die serielle Konsole Ihres Anbieters, melden Sie sich dort an und arbeiten Sie anschließend diese Befehle der Reihe nach ab.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

systemctl status ssh verwendet unter Ubuntu und Debian den Namen der Unit. Unter RHEL und darauf basierenden Distributionen wie AlmaLinux lautet die Unit sshd. ss -tlnp listet alle TCP-Sockets im Status „listening“ zusammen mit dem Prozess auf, dem sie gehören. Die Ausgabe ist maßgeblich: Wenn keine Zeile sshd nennt, lauscht nichts, unabhängig davon, was die Konfigurationsdatei angibt. sshd -T gibt die effektive Konfiguration aus, nachdem jede Include-Datei zusammengeführt wurde. Dort wird ein vergessener Port in /etc/ssh/sshd_config.d/ sichtbar.

Prüfen Sie die Adressspalte sorgfältig. 0.0.0.0:22 bedeutet, dass alle IPv4-Adressen des Systems verwendet werden. [::]:22 bedeutet, dass alle IPv6-Adressen verwendet werden. 127.0.0.1:22 bedeutet, dass nur die Loopback-Adresse verwendet wird. Jede entfernte Verbindung wird dann abgewiesen, während eine lokale Verbindung mit ssh localhost problemlos funktioniert.

Wenn nichts lauscht, starten Sie den Dienst und lesen Sie die Fehlermeldung, falls er nicht startet.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

sshd -t prüft die Konfiguration und gibt bei einer fehlerhaften Direktive die Datei und die Zeilennummer aus, ohne den laufenden Dienst zu verändern. Führen Sie den Befehl vor jedem Neustart aus. Wird eine Konfiguration abgelehnt, beendet sich sshd beim Start, und Ihre nächste Verbindung wird abgewiesen.

Die Falle bei der Socket-Aktivierung unter Ubuntu

Ubuntu 24.04 enthält eine systemd-Socket-Unit für OpenSSH. Wenn diese Unit aktiviert ist, übernimmt systemd den Listening-Port und startet sshd pro Verbindung. Daher ändert Port 2222 in sshd_config nichts, und der Server antwortet weiterhin am alten Port. Prüfen Sie vor Änderungen, welcher Modus auf Ihrem System aktiv ist.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

Wenn der Socket aktiviert ist, setzen Sie den Port in der Socket-Unit statt in sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

Die leere Zeile ListenStream= ist erforderlich, weil systemd-Listeneinstellungen zu bereits vorhandenen Einstellungen hinzugefügt werden. Lassen Sie sie weg, lauscht der Server an beiden Ports. Wenden Sie die Änderung mit sudo systemctl daemon-reload und sudo systemctl restart ssh.socket an. Prüfen Sie anschließend mit sudo ss -tlnp, ob der neue Port verwendet wird. Die Änderung des Ports ist ein üblicher Schritt beim Härten von SSH auf einem VPS. Dabei sperren sich Benutzer am häufigsten aus dem System aus.

Warum „Connection timed out“ bedeutet, dass niemand geantwortet hat

Ein Timeout bedeutet, dass keine Antwort eingegangen ist. Ihr Client hat ein SYN gesendet und es über einen Zeitraum von ein bis zwei Minuten mehrmals erneut übertragen. Er hat kein einziges Paket zurückerhalten. Über den Server lässt sich daraus nichts ableiten, weil vom Server nie eine Antwort eingegangen ist.

Genau diese Stille erzeugt eine DROP-Regel. Das Verwerfen ist beabsichtigt. Eine Ablehnung zeigt jedem Scanner, dass der Host vorhanden ist. Deshalb verwerfen ufw und die Netzwerk-Firewall jedes Cloud-Anbieters unerwünschte Pakete und senden nichts zurück. Ihr Timeout wird meistens durch eine Firewall verursacht, die einen Port blockiert, den Sie öffnen wollten.

• Die Adresse ist falsch: Ein DNS-Eintrag verweist noch auf einen Server, den Sie neu aufgebaut haben, oder ein Tippfehler führt zu einer Adresse, die niemand verwendet.
• Der Host ist nicht aktiv: Er ist ausgeschaltet oder befindet sich mitten in einem Reboot. Eine Sperrung durch den Anbieter wegen einer offenen Rechnung sieht von außen identisch aus.
• Die Host-Firewall verwirft Pakete für Port 22. Meistens geschieht das, weil ufw enable ausgeführt wurde, bevor eine Allow-Regel vorhanden war.
• Eine vorgeschaltete Provider-Firewall verwirft das Paket. Das Betriebssystem sieht es dann überhaupt nicht.
• Ihr eigenes Netzwerk blockiert ausgehende Verbindungen zu Port 22. Das kommt in Büro- und Hotelnetzwerken häufig vor.

Führen Sie den Test von der richtigen Seite der Verbindung aus

Dies ist der Fehler, der am meisten Zeit kostet. Ein verworfenes Paket lässt sich nicht innerhalb des Systems diagnostizieren, das die Pakete nicht erreichen. Wenn Sie sich anmelden könnten, um den Befehl auszuführen, hätten Sie das Problem nicht. Jeder Befehl in diesem Abschnitt wird auf Ihrem eigenen Rechner ausgeführt.

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

getent hosts zeigt die Adresse, die Ihr Rechner tatsächlich verwendet. Dadurch lässt sich ein veralteter DNS-Eintrag innerhalb weniger Sekunden erkennen. ssh -G gibt die Einstellungen aus, die Ihr Client nach dem Einlesen von ~/.ssh/config verwendet. Damit lässt sich ein veralteter Host-Block erkennen, der den Hostnamen, den Port oder den Benutzer unbemerkt ersetzt. ssh -vvv zeigt, wie weit der Verbindungsversuch gekommen ist: Eine letzte Zeile über die Verbindung zur Adresse, gefolgt von einer langen Pause, bedeutet einen Timeout. Eine Zeile mit der Version des entfernten OpenSSH bedeutet dagegen, dass TCP bereits erfolgreich war und das eigentliche Problem bei der Authentifizierung liegt. Unter Windows ersetzt Test-NetConnection 203.0.113.10 -Port 22 in PowerShell den Befehl nc.

Testen Sie den Port, nicht den Host. Ein fehlgeschlagenes ping beweist nichts, da viele Anbieter ICMP (Internet Control Message Protocol) am Netzwerkrand filtern. Auch ein erfolgreicher Ping beweist nichts, da er keine Aussage über Port 22 trifft.

Ändern Sie anschließend die eine Variable, die kein Befehl für Sie ändern kann: Ihr Netzwerk. Wiederholen Sie den Versuch über den Hotspot eines Mobiltelefons. Wenn die Verbindung über den Hotspot funktioniert, über Ihr Büroarbeitsplatz jedoch nicht, liegt die Sperre auf Ihrer Seite des Internets oder Ihre Büroadresse wurde auf dem Server gesperrt.

Die vom Server aus nicht sichtbare Provider-Firewall

Die meisten VPS-Panels bieten eine Netzwerk-Firewall an, die manchmal als Security Group oder Cloud-Firewall bezeichnet wird. Sie läuft dem Server vorgeschaltet und verwaltet eine eigene Regelliste. ufw status auf dem Server kann diese Firewall nicht sehen. Deshalb hört man so häufig: „Aber Port 22 ist doch bereits freigegeben.“ Öffnen Sie das Panel und prüfen Sie diese Liste, bevor Sie auch nur eine Regel auf dem Server ändern.

Ein Befehl klärt die Frage. Dafür benötigen Sie Konsolenzugriff. Starten Sie ihn auf dem Server und versuchen Sie anschließend, von Ihrem Laptop aus eine Verbindung herzustellen, während der Befehl läuft.

sudo tcpdump -ni any tcp port 22

Wenn während des Verbindungsversuchs nichts angezeigt wird, werden die Pakete verworfen, bevor sie das Betriebssystem erreichen. Die Ursache liegt dann in der Provider-Firewall oder in der Route zum Host. Wenn SYN-Pakete eintreffen und keine Antwort gesendet wird, erfolgt der Verwurf lokal und wird durch ufw oder nftables verursacht. Dieser einzelne Test teilt die Timeout-Ursachensuche in zwei Hälften. Deshalb lohnt sich der Zugriff auf die Konsole.

ufw-Reihenfolge, IPv6 und eine selbst verhängte Sperre

Der Fehler bei der ufw-Reihenfolge sperrt mehr Benutzer aus als alles andere in diesem Abschnitt. sudo ufw enable setzt die Standardrichtlinie für eingehende Verbindungen sofort auf deny. Ohne vorhandene SSH-Regel bleibt die aktuelle Sitzung dank des Zustands für bestehende Verbindungen bestehen, während jede neue Verbindung in einen Timeout läuft. Erlauben Sie die Verbindung zuerst und aktivieren Sie ufw anschließend.

sudo ufw allow OpenSSH
sudo ufw status verbose

Das OpenSSH-Anwendungsprofil deckt nur Port 22 ab. Wenn Sie SSH auf 2222 verschieben möchten, benötigen Sie die Regel sudo ufw allow 2222/tcp. Fügen Sie sie vor der Portänderung hinzu, nicht danach. Das umfassendere Regelwerk wird in ufw-Firewall-Grundlagen für einen VPS behandelt. Die sichere Reihenfolge ist Bestandteil von den ersten zehn Minuten auf einem neuen VPS.

IPv6 kann einen Timeout verursachen, der zunächst unerklärlich wirkt. Wenn der Hostname einen AAAA-Eintrag besitzt, versucht Ihr Client zuerst IPv6. Fehlen auf dem Server die IPv6-Regeln, wartet die Verbindung, während ein direkter Versuch über IPv4 funktioniert. Trennen Sie beide Fälle manuell.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

Wenn -4 eine Verbindung herstellt und -6 nicht, liegt die Ursache in den IPv6-Regeln des Servers. Den gleichen Port für IPv6 in ufw öffnen beschreibt die erforderlichen Schritte.

Möglicherweise haben Sie sich auch selbst gesperrt. fail2ban überwacht das Authentifizierungs-Log und fügt für Adressen mit wiederholten Fehlversuchen eine Firewall-Regel ein. Dadurch kann beispielsweise ein falscher Schlüssel oder ein im Hintergrund wiederholtes Skript eine gesamte Büro-Adresse sperren. Eine Sperre, die Pakete verwirft, sieht wie ein Timeout aus. Eine Sperre, die die Verbindung ablehnt, gibt stattdessen No route to host zurück. Führen Sie den Befehl an der Konsole aus:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

Das Hinzufügen Ihrer eigenen Adresse zu ignoreip ist Bestandteil von einer funktionierenden fail2ban-Konfiguration unter Ubuntu 24.04.

Fehler, die weder abgelehnt werden noch in einen Timeout laufen

No route to host bedeutet, dass eine ICMP-Unreachable-Nachricht zurückgekommen ist. Entweder hat Ihr eigenes System keine Route zu diesem Netzwerk, oder ein System auf dem Pfad hat mit einer administrativen Ablehnung geantwortet. Genau das sendet eine iptables-REJECT-Regel.

Network is unreachable stammt von Ihrem eigenen System. Für diese Adressfamilie ist überhaupt keine Route vorhanden. Dies ist die übliche Antwort, wenn ein Hostname bei einer reinen IPv4-Verbindung nur in eine IPv6-Adresse aufgelöst wird.

kex_exchange_identification: Connection closed by remote host bedeutet, dass die TCP-Verbindung hergestellt wurde und der Server die Verbindung anschließend beendet hat, bevor der Schlüsselaustausch abgeschlossen war. Der Port ist offen und sshd läuft. Prüfen Sie daher die Serverauslastung, MaxStartups oder eine Sperre, die während des Verbindungsaufbaus aktiv wurde.

Permission denied (publickey) bedeutet, dass Sie die Authentifizierung erreicht haben und dort fehlgeschlagen sind. Netzwerk und Firewall funktionieren. Nichts in dieser Anleitung trifft daher zu. Fahren Sie stattdessen mit Permission denied (publickey) bei SSH beheben fort.

So stellen Sie den Zugriff wieder her und vermeiden eine erneute Sperrung

Jeder seriöse VPS-Anbieter stellt eine Konsole bereit, die nicht vom Netzwerk des Gastsystems abhängt: eine serielle Konsole oder einen browserbasierten VNC-Bildschirm. Diese Konsole ist für beide Varianten dieses Leitfadens der Wiederherstellungsweg. Sie funktioniert weiterhin, wenn sshd gestoppt wurde oder eine Firewall-Regel sämtlichen Datenverkehr verwirft. Öffnen Sie die Konsole im Panel, melden Sie sich als root oder als Ihr normaler Benutzer an und führen Sie anschließend die oben genannten Prüfungen aus. Wenn Sie nie ein root-Passwort gesetzt haben, können die meisten Panels ein solches für Sie zurücksetzen.

Wenn keine Konsole verfügbar ist, verwenden Sie den Rescue-Modus des Anbieters. Er startet ein kleines Wiederherstellungssystem und bindet Ihre Festplatte ein. Dadurch können Sie /etc/ssh/sshd_config bearbeiten oder eine Firewall-Regel offline löschen und anschließend neu booten.

Zwei Gewohnheiten verhindern die nächste Sperrung. Lassen Sie eine zweite SSH-Sitzung geöffnet, wenn Sie sshd oder die Firewall bearbeiten. Diese Sitzung bleibt aufgrund des bestehenden Verbindungsstatus aktiv, während Sie eine neue Sitzung testen. Richten Sie außerdem vor einer riskanten Firewall-Änderung eine automatische Rücknahme ein.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

Die erste Zeile plant, dass ufw sich nach zehn Minuten selbst deaktiviert. Wenden Sie Ihre neuen Regeln an, öffnen Sie eine neue SSH-Sitzung und prüfen Sie damit, ob sie funktionieren. Führen Sie anschließend die zweite Zeile aus, um die Rücknahme abzubrechen. Wenn Sie sich stattdessen aussperren, warten Sie zehn Minuten. Die Firewall wird dann automatisch deaktiviert. Der Server bleibt dadurch ungefiltert, bis Sie ufw wieder aktivieren. Verwenden Sie diese Methode daher nur, wenn Sie direkt an der Tastatur sitzen, und nicht als dauerhafte Konfiguration.

Die Reihenfolge der Prüfung

1. Lesen Sie den Fehlertext und achten Sie darauf, wie lange die Ausgabe gedauert hat.
2. „Refused“: Wechseln Sie zur Konsole und prüfen Sie mit sudo ss -tlnp, ob ein Socket auf Verbindungen wartet, welchen Port er verwendet und an welche Adresse er gebunden ist.
3. „Timed out“: Bestätigen Sie von Ihrem eigenen Rechner aus die Adresse. Prüfen Sie anschließend die Firewall des Providers im Panel und danach die Host-Firewall auf dem Server.
4. Keine dieser Zeichenfolgen: Es besteht bereits eine TCP-Verbindung. Behandeln Sie das Problem daher als Authentifizierungs- oder Serverlastproblem, nicht als Netzwerkproblem.

FAQ

Warum meldet SSH „Connection refused“, obwohl sshd läuft?

Eine Ablehnung kommt vom Socket, nicht vom Dienst. Ein laufendes sshd kann Verbindungen trotzdem ablehnen. Öffnen Sie die Provider-Konsole und führen Sie sudo ss -tlnp aus. Ein Socket auf 127.0.0.1:22 lehnt jeden Remote-Client ab, weil er nur an das Loopback-Interface gebunden ist. Ein Socket auf einem anderen Port lehnt weiterhin alle Verbindungen ab, die Port 22 verwenden. Wenn die Socket-Aktivierung durch systemd verwendet wird, stammt der Port aus ssh.socket und nicht aus sshd_config. Prüfen Sie daher auch systemctl is-enabled ssh.socket. Eine ufw-Regel reject kann im Namen des Hosts ebenfalls eine Ablehnung zurückgeben. Lesen Sie daher sudo ufw status verbose, bevor Sie eine Schlussfolgerung ziehen.

Warum läuft bei ufw-Freigabe für Port 22 die SSH-Verbindung in einen Timeout?

Ein Timeout bedeutet, dass keine Antwort zurückgekommen ist. ufw ist nicht die einzige Firewall auf dem Übertragungsweg. Die meisten VPS-Panels betreiben vor der Instanz eine Netzwerk-Firewall. Was diese Firewall verwirft, erreicht das Betriebssystem nicht. Führen Sie in der Konsole sudo tcpdump -ni any tcp port 22 aus und versuchen Sie gleichzeitig, von Ihrem Laptop aus eine Verbindung herzustellen. Wenn keine Pakete eintreffen, erfolgt die Filterung vorgelagert im Panel. Wenn Pakete eintreffen, aber keine Antwort gesendet wird, erfolgt die Filterung lokal durch ufw oder nftables.

Bedeutet ein fehlgeschlagener Ping, dass mein VPS nicht erreichbar ist?

Nein. Viele Provider filtern ICMP am Netzwerkrand. Ein Server kann daher den gesamten eingehenden Ping-Verkehr ignorieren und trotzdem den normalen Netzwerkverkehr bedienen. Ein erfolgreicher Ping ist in die andere Richtung genauso wenig aussagekräftig. Er sagt nichts darüber aus, ob Port 22 geöffnet ist. Prüfen Sie den Port selbst mit nc -vz -w 5 203.0.113.10 22 von Ihrem eigenen Rechner aus oder mit Test-NetConnection 203.0.113.10 -Port 22 in PowerShell unter Windows.

Ich habe den SSH-Port geändert, und jetzt kann keine Verbindung mehr hergestellt werden. Was ist schiefgelaufen?

Zwei Reihenfolgen können dieses Problem verursachen. Wenn für den neuen Port keine Firewall-Regel eingerichtet wurde, laufen Verbindungsversuche zum neuen Port in einen Timeout, während Port 22 die Verbindung ablehnt. Daher muss sudo ufw allow 2222/tcp vor der Portänderung und nicht danach ausgeführt werden. Wenn der Server für SSH die Socket-Aktivierung durch systemd verwendet, wird Port 2222 in sshd_config ignoriert. systemd hält dann weiterhin den alten Port geöffnet. Das können Sie mit systemctl is-enabled ssh.socket bestätigen. Stellen Sie über die Provider-Konsole den Zugriff wieder her und beheben Sie die zutreffende Ursache. Verbinden Sie sich anschließend mit ssh -p 2222 user@203.0.113.10, sobald sudo ss -tlnp den neuen Socket anzeigt.