Ce que vous dit le message
ssh: connect to host 203.0.113.10 port 22: No route to hostDes messages voisins ont des significations différentes : vérifiez donc que vous avez bien celui-ci. Chaque ligne ci-dessous a été produite avec une vraie règle ou une vraie configuration :
| Message | Ce qui s'est passé |
|---|---|
No route to host | Aucune machine n'a répondu à cette adresse sur le réseau local, ou un pare-feu a répondu host-prohibited |
Network is unreachable | Votre machine n'a aucune route, souvent faute de passerelle par défaut |
Connection refused | La machine a répondu, mais rien n'accepte de connexions sur ce port, ou un pare-feu l'a rejeté avec port-unreachable. Voir Connection refused |
Connection timed out | Aucune réponse n'est revenue, souvent un pare-feu qui abandonne les paquets. Voir Connection timed out |
Premier test
ping -c 3 203.0.113.10
nc -vz -w 10 203.0.113.10 22Certains serveurs ignorent le ping : un ping qui échoue ne prouve donc pas grand-chose à lui seul. Un ping qui fonctionne alors que le port 22 donne No route to host pointe directement vers un pare-feu sur le serveur, c'est-à-dire la cause 2.
Cause 1 : la machine est éteinte, ou l'adresse est fausse
Sur le même réseau local, votre machine demande qui possède l'adresse. Si personne ne répond, vous obtenez cette erreur en quelques secondes. Sous Linux, vous pouvez voir la recherche échouée :
ip neigh show to 203.0.113.10203.0.113.10 dev eth0 FAILEDSous macOS, utilisez arp -n 203.0.113.10, qui affiche incomplete ou aucune entrée.
Vérifiez que la machine est allumée et connectée, et contrôlez son adresse actuelle depuis sa propre console ou la liste des appareils de votre routeur. Les box domestiques attribuent souvent une nouvelle adresse après un redémarrage. Un serveur cloud peut avoir une nouvelle adresse IP après avoir été arrêté puis redémarré.
Cause 2 : un pare-feu sur le serveur vous rejette
Cette règle produit exactement le même message côté client, alors que la machine fonctionne et que sshd tourne :
iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with icmp-host-prohibitedLe rejet par défaut de firewalld sur les systèmes de type Red Hat donne le même résultat. Depuis une console sur le serveur, regardez ce qui s'y trouve :
sudo firewall-cmd --list-all
sudo iptables -S INPUT
sudo nft list rulesetPour autoriser SSH avec firewalld :
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadAvec ufw, voir comment autoriser SSH avec ufw. Dans un compte cloud, regardez aussi le groupe de sécurité ou le pare-feu réseau du fournisseur.
Cause 3 : une route manquante ou un VPN éteint
Demandez à votre système par où il enverrait le paquet. Ces deux commandes ne font que lire la table de routage :
ip route get 203.0.113.10route -n get 203.0.113.10La première est pour Linux et la seconde pour macOS. Regardez l'interface et la passerelle :
- Une adresse privée comme 10.x qui sort par votre Wi-Fi habituel au lieu du VPN : le VPN est éteint, ou ne couvre pas ce sous-réseau.
- Deux réseaux qui utilisent la même plage, comme un réseau domestique et un VPN tous deux en 192.168.1.x : le mauvais l'emporte. Changez l'un des deux.
- Une mauvaise passerelle sur le serveur lui-même : il peut recevoir vos paquets sans pouvoir répondre. Vérifiez
ip routedepuis sa console.
Si ce réseau n'est accessible que depuis un autre serveur, passez par lui avec un hôte de rebond et ProxyJump.
Cause 4 : isolation du Wi-Fi
Les réseaux invités et de nombreux réseaux de bureau ou d'hôtel empêchent les appareils de communiquer entre eux. Si la même commande fonctionne depuis un autre réseau, ou depuis une connexion filaire, c'est la raison. Passez sur le réseau principal, ou joignez la machine par un VPN.
Cause 5 : macOS ou iOS bloque l'application sur le réseau local
Depuis macOS 15, les programmes ont besoin du droit Réseau local pour joindre des machines de votre LAN. Apple indique que les outils en ligne de commande lancés depuis Terminal sont autorisés automatiquement, et que les autres programmes sont bloqués tant que vous n'accordez pas ce droit. Si ssh vers une adresse du LAN échoue dans une autre application de terminal ou un éditeur mais fonctionne dans Terminal, ouvrez Réglages Système, puis Confidentialité et sécurité, puis Réseau local, et activez cette application. Sur iPhone et iPad, toute application SSH a besoin du même droit : Réglages, puis Confidentialité et sécurité, puis Réseau local. Il n'a pas d'effet sur les adresses de l'Internet public.
Questions
No route to host vient-il de ma clé SSH ?
Non. La connexion a échoué avant le démarrage de SSH : clés, mots de passe et nom d'utilisateur n'y sont pour rien. Regardez le réseau : l'adresse, un pare-feu ou une route.
Pourquoi ping fonctionne alors que SSH affiche No route to host ?
La machine est allumée, et un pare-feu sur elle rejette le port 22 avec une réponse host-prohibited. Vérifiez iptables, nftables ou firewalld sur le serveur, ainsi que le groupe de sécurité de l'hébergeur.
Quelle différence entre No route to host et Connection timed out ?
No route to host est une réponse nette : l'adresse est injoignable. Un timeout signifie qu'aucune réponse n'est revenue, en général à cause d'un pare-feu qui ignore les paquets sans rien dire.
Sources
- TN3179 : comprendre la confidentialité du réseau local, Apple
- Manuel de firewall-cmd, firewalld
- iptables-extensions(8), cible REJECT