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 serverlit 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 mDNSResponderet sous Linux avec systemd avecresolvectl 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.