"ssh: connect to host port 22: No route to host"

Ihr Rechner oder ein Router auf dem Weg hat eine eindeutige Antwort bekommen, dass die Adresse nicht erreichbar ist. Meist ist die Maschine aus oder hat eine andere IP-Adresse, eine Firewall darauf weist Port 22 mit einer host-prohibited-Antwort ab, oder die VPN-Verbindung oder Route in dieses Netz fehlt. SSH hat nie mit dem Server gesprochen, Schlüssel und Passwörter sind also nicht das Problem. Beginnen Sie mit ping und ip route get.

Sie müssen ein privates Netz erreichen, das nur ein anderer Server sieht? Wardterm geht für Sie über diesen Server, einmal pro Server oder Gruppe eingestellt. Zeigen

Aktualisiert am . Die Meldung wurde auf Debian 13 mit OpenSSH 10.0 nachgestellt, einmal mit einer Adresse, die im Subnetz nicht existierte, und einmal mit einer iptables-Regel, die verwandten Meldungen mit anderen iptables-Regeln.

Was die Meldung Ihnen sagt

ssh: connect to host 203.0.113.10 port 22: No route to host

Ähnliche Meldungen bedeuten Verschiedenes, prüfen Sie also, ob es wirklich diese ist. Jede Zeile unten wurde mit einer echten Regel oder einem echten Aufbau erzeugt:

MeldungWas passiert ist
No route to hostIm lokalen Netz hat unter dieser Adresse keine Maschine geantwortet, oder eine Firewall antwortete mit host-prohibited
Network is unreachableIhr Rechner hat gar keine Route, oft kein Standard-Gateway
Connection refusedDie Maschine hat geantwortet, aber auf diesem Port nimmt nichts Verbindungen an, oder eine Firewall hat mit port-unreachable abgewiesen. Siehe Connection refused
Connection timed outEs kam keine Antwort zurück, oft eine Firewall, die Pakete verwirft. Siehe Connection timed out

Erster Test

ping -c 3 203.0.113.10
nc -vz -w 10 203.0.113.10 22

Manche Server ignorieren Ping, ein fehlgeschlagener Ping allein beweist also wenig. Ein Ping, der funktioniert, während Port 22 No route to host liefert, weist direkt auf eine Firewall auf dem Server hin, das ist Ursache 2.

Ursache 1: Die Maschine ist aus, oder die Adresse ist falsch

Im selben lokalen Netz fragt Ihr Rechner, wer die Adresse hat. Antwortet niemand, erhalten Sie diesen Fehler nach wenigen Sekunden. Unter Linux sehen Sie die fehlgeschlagene Abfrage:

ip neigh show to 203.0.113.10
203.0.113.10 dev eth0 FAILED

Unter macOS nehmen Sie arp -n 203.0.113.10, das incomplete oder keinen Eintrag zeigt.

Prüfen Sie, ob die Maschine eingeschaltet und verbunden ist, und prüfen Sie ihre aktuelle Adresse an ihrer eigenen Konsole oder in der Geräteliste Ihres Routers. Heimrouter vergeben nach einem Neustart oft eine neue Adresse. Ein Cloud-Server kann nach Stoppen und Starten eine neue IP-Adresse haben.

Ursache 2: Eine Firewall auf dem Server weist Sie ab

Diese Regel erzeugt auf dem Client genau dieselbe Meldung, obwohl die Maschine läuft und sshd aktiv ist:

iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with icmp-host-prohibited

Die Standard-Abweisung von firewalld auf Red-Hat-Systemen liefert dasselbe Ergebnis. Sehen Sie von einer Konsole auf dem Server nach, was dort steht:

sudo firewall-cmd --list-all
sudo iptables -S INPUT
sudo nft list ruleset

So erlauben Sie SSH unter firewalld:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Unter ufw siehe SSH mit ufw erlauben. In einem Cloud-Konto prüfen Sie zusätzlich die Security Group oder die Netzwerk-Firewall des Anbieters.

Ursache 3: eine fehlende Route oder ein ausgeschaltetes VPN

Fragen Sie Ihr System, wohin es das Paket schicken würde. Diese beiden Befehle lesen nur die Routing-Tabelle:

ip route get 203.0.113.10
route -n get 203.0.113.10

Der erste gilt für Linux, der zweite für macOS. Sehen Sie sich die Schnittstelle und das Gateway an:

  • Eine private Adresse wie 10.x geht über Ihr normales WLAN statt über das VPN hinaus: Das VPN ist aus oder deckt dieses Subnetz nicht ab.
  • Zwei Netze nutzen denselben Bereich, etwa ein Heimnetz und ein VPN beide auf 192.168.1.x: Das falsche gewinnt. Ändern Sie eines davon.
  • Ein falsches Gateway auf dem Server selbst: Er kann Ihre Pakete empfangen und nicht antworten. Prüfen Sie ip route an seiner Konsole.

Ist dieses Netz nur über einen anderen Server erreichbar, gehen Sie mit einem Jump-Host und ProxyJump darüber.

Ursache 4: WLAN-Isolation

Gastnetze und viele Büro- oder Hotelnetze hindern Geräte daran, miteinander zu sprechen. Funktioniert derselbe Befehl aus einem anderen Netz oder über eine Kabelverbindung, ist das der Grund. Wechseln Sie ins Hauptnetz oder erreichen Sie die Maschine über ein VPN.

Ursache 5: macOS oder iOS blockiert die App im lokalen Netz

Seit macOS 15 brauchen Programme die Berechtigung Local Network, um Maschinen in Ihrem LAN zu erreichen. Laut Apple werden Kommandozeilenwerkzeuge, die aus dem Terminal gestartet werden, automatisch zugelassen, andere Programme sind blockiert, bis Sie die Berechtigung erteilen. Scheitert ssh zu einer LAN-Adresse also in einer anderen Terminal-App oder einem Editor, funktioniert aber im Terminal, öffnen Sie Systemeinstellungen, dann Datenschutz & Sicherheit, dann Lokales Netzwerk, und schalten Sie diese App ein. Auf iPhone und iPad braucht jede SSH-App dieselbe Berechtigung: Einstellungen, dann Datenschutz & Sicherheit, dann Lokales Netzwerk. Adressen im öffentlichen Internet betrifft sie nicht.

Fragen

Liegt No route to host an meinem SSH-Schlüssel?

Nein. Die Verbindung ist gescheitert, bevor SSH überhaupt begonnen hat. Schlüssel, Passwörter und Benutzername spielen keine Rolle. Prüfen Sie das Netz: die Adresse, eine Firewall oder eine Route.

Warum funktioniert ping, aber SSH meldet No route to host?

Die Maschine läuft, und eine Firewall darauf weist Port 22 mit einer host-prohibited-Antwort ab. Prüfen Sie iptables, nftables oder firewalld auf dem Server sowie die Sicherheitsgruppe des Anbieters.

Was unterscheidet No route to host von Connection timed out?

No route to host ist eine eindeutige Antwort: Die Adresse ist nicht erreichbar. Ein Timeout heißt, dass gar keine Antwort kam, meist wegen einer Firewall, die Pakete stillschweigend verwirft.

Quellen

Mehr zu Fehlermeldungen

Alle Anleitungen