« ssh: Could not resolve hostname » : causes et solutions

SSH n'a pas pu transformer le nom saisi en adresse IP : aucune connexion n'a donc été tentée et le serveur n'y est pour rien. Les raisons habituelles sont une faute de frappe, un alias absent de ~/.ssh/config, un port écrit sous la forme host:22, ou un problème de DNS. Lancez ssh -G name | grep '^hostname ' pour voir quel nom SSH cherche, puis testez ce nom avec le résolveur de votre système.

Mis à jour le . Messages reproduits avec OpenSSH 10.3 sur macOS et OpenSSH 10.0 sous Debian 13, y compris dans un conteneur sans réseau.

Le message selon le système

La première partie vient de SSH. La partie après les deux-points vient du résolveur de votre système.

ssh: Could not resolve hostname server: nodename nor servname provided, or not known

C'est macOS. Sous Linux, le même échec s'écrit :

ssh: Could not resolve hostname server: Name or service not known

Linux a aussi une troisième forme, fréquente quand le réseau ou le serveur DNS est hors service :

ssh: Could not resolve hostname server: Temporary failure in name resolution

Le mot entre hostname et les deux-points est exactement ce que SSH a essayé de résoudre. Lisez-le en premier, car il révèle souvent l'erreur.

Cause 1 : une faute de frappe, ou un alias que SSH ne voit pas

ssh -G server | grep -E '^(hostname|port|user) '

Cela affiche ce que SSH utiliserait, sans se connecter. Si vous attendiez un alias de votre configuration et que hostname ne fait que répéter ce que vous avez tapé, aucun bloc Host ne correspond. Vérifiez ceci :

  • L'alias est écrit de la même façon dans ~/.ssh/config.
  • Le bloc a une ligne HostName, sans faute de frappe. Une mauvaise valeur à cet endroit apparaît dans l'erreur à la place de l'alias.
  • Vous êtes bien le même utilisateur. sudo ssh server lit la configuration de root, pas la vôtre.

La correspondance des alias et des blocs Host est expliquée dans les exemples de fichier ssh config.

Cause 2 : le port ou une URL fait partie du nom

SSH ne lit ni host:port ni une adresse web. Ces deux commandes échouent avec la même erreur, et l'erreur montre toute la chaîne comme nom :

ssh user@example.com:22
ssh https://example.com
ssh: Could not resolve hostname example.com:22: nodename nor servname provided, or not known

Utilisez l'une de ces formes :

ssh -p 2222 user@example.com
ssh ssh://user@example.com:2222

Une espace parasite donne un autre message, hostname contains invalid characters. Vérifiez qu'il n'y a pas d'espaces ou de sauts de ligne collés.

Cause 3 : le DNS

Vérifiez le nom en dehors de SSH, avec le résolveur que SSH utilise.

Sur macOS :

dscacheutil -q host -a name example.com

Sur Linux :

getent hosts example.com

Une sortie vide signifie que cette machine ne sait pas résoudre le nom. Interrogez alors directement un résolveur public :

dig +short example.com @1.1.1.1
  • Une réponse du résolveur public mais pas de votre système : votre configuration DNS locale ou son cache est en cause. Videz-le, sur macOS avec sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder et sous Linux avec systemd avec resolvectl flush-caches, ou changez de serveur DNS.
  • Aucune réponse nulle part : l'enregistrement n'existe pas. Ce peut être un enregistrement récent pas encore propagé, un enregistrement supprimé, ou une faute de frappe dans la zone.

Pour un nom que vous êtes seul à utiliser, comme une machine chez vous, vous pouvez vous passer du DNS : ajoutez une ligne à /etc/hosts, ou mettez l'adresse dans la ligne HostName de votre ~/.ssh/config.

Pour travailler pendant que vous réglez le DNS, connectez-vous par l'adresse. Gardez en tête que la clé d'hôte est enregistrée par nom : SSH peut donc vous demander de la confirmer de nouveau :

ssh user@203.0.113.10

Cause 4 : un nom qui n'existe que sur un réseau privé

Les noms d'entreprise, les noms en .internal et les noms MagicDNS de Tailscale ne se résolvent que lorsque vous êtes sur ce réseau. Si cela fonctionnait hier, vérifiez que le VPN est activé et qu'il a bien défini son serveur DNS.

Les noms se terminant par .local dépendent de mDNS. macOS les gère d'office. Sous Linux, ils demandent généralement Avahi et mdns4_minimal dans /etc/nsswitch.conf. Les réseaux Wi-Fi invités bloquent souvent le mDNS entre appareils.

Cause 5 : pas de réseau

Temporary failure in name resolution signifie généralement que le système n'a pas pu joindre de serveur DNS du tout. Vérifiez avec une adresse qui n'a pas besoin de nom :

ping -c 1 1.1.1.1

Sur un serveur ou un conteneur Linux, regardez aussi /etc/resolv.conf.

Questions

Que veut dire "nodename nor servname provided, or not known" ?

C'est la formulation de macOS pour un nom qui n'a pas pu être résolu. SSH n'a trouvé aucune adresse IP pour ce nom : vérifiez l'orthographe, l'alias dans ~/.ssh/config et votre DNS.

Peut-on écrire le port après deux-points dans ssh ?

Non. ssh lit host:22 comme une partie du nom. Utilisez ssh -p 22 user@host, ou la forme ssh://user@host:22.

Pourquoi l'erreur n'apparaît-elle qu'avec sudo ?

sudo ssh lit le ~/.ssh/config de root, pas le vôtre : vos alias y sont inconnus. Lancez ssh sans sudo.

Sources

Autres guides : Messages d'erreur

Tous les guides