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:
| Meldung | Was passiert ist |
|---|---|
No route to host | Im lokalen Netz hat unter dieser Adresse keine Maschine geantwortet, oder eine Firewall antwortete mit host-prohibited |
Network is unreachable | Ihr Rechner hat gar keine Route, oft kein Standard-Gateway |
Connection refused | Die Maschine hat geantwortet, aber auf diesem Port nimmt nichts Verbindungen an, oder eine Firewall hat mit port-unreachable abgewiesen. Siehe Connection refused |
Connection timed out | Es 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 routean 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
- TN3179: Understanding local network privacy, Apple
- firewall-cmd-Handbuch, firewalld
- iptables-extensions(8), REJECT-Target