termalLes messages d’erreur de SSH sont laconiques à dessein — le protocole ne dira pas à un inconnu pourquoi il l’a éconduit. C’est de la bonne sécurité et de la mauvaise ergonomie : le message que vous voyez est souvent à deux pas du vrai problème. Voici un guide de terrain sur les treize erreurs que vous rencontrerez vraiment, ce que chacune signifie réellement, et le chemin le plus rapide vers un correctif.
Un outil avant de commencer : ssh -v user@host (ajoutez jusqu’à -vvv — lire cette sortie (en anglais)). Presque chaque mystère ci-dessous cesse d’en être un dès que vous voyez à quelle étape de la poignée de main il meurt.
Les erreurs en un coup d’œil
| Erreur | Ce que ça signifie | Premier geste |
|---|---|---|
Connection refused | L’hôte a répondu ; rien n’écoute sur ce port | Vérifiez que sshd tourne et sur le port composé |
Connection timed out | Les paquets se sont évanouis en chemin | Vérifiez le pare-feu cloud / le security group |
Permission denied (publickey) | Aucune clé proposée n’a été acceptée | Vérifiez l’utilisateur, puis la clé, puis authorized_keys |
Permission denied (sans invite) | L’auth par mot de passe est désactivée ; il faut une clé | Utilisez une clé, ou entrez via la console du fournisseur |
Host key verification failed | La clé du serveur a changé depuis que vous l’aviez acceptée | Vérifiez par un autre canal, puis ssh-keygen -R |
Too many authentication failures | L’agent a proposé trop de clés | -o IdentitiesOnly=yes avec -i |
UNPROTECTED PRIVATE KEY FILE | Le fichier de clé est lisible par d’autres | chmod 600 sur la clé privée |
Broken pipe | Une connexion inactive a été coupée | Ajoutez ServerAliveInterval |
no matching key exchange method | Serveur ancien, client moderne | Réactivez un algorithme pour cet hôte seulement |
Connection reset by peer | TCP coupé net avant le bonjour SSH | Vérifiez fail2ban / MaxStartups |
Bad configuration option | Votre client est trop ancien pour une ligne de config | Mettez ssh à jour, ou protégez la ligne |
did not receive identification string | Quelque chose s’est connecté sans envoyer de bannière | En général un scanner ; ignorez-le côté serveur |
Unspecified GSS failure | Une tentative Kerberos a échoué, puis repli | Ignorez-la si la connexion aboutit quand même |
1. Connection refused
La machine est joignable, mais rien n’écoute sur le port auquel vous avez frappé. Celle-ci ne vient presque jamais de vous :
- sshd ne tourne pas —
systemctl status sshddepuis une console (les fournisseurs de VPS ont une console web pour exactement ce moment) ; - il écoute sur un port non standard — essayez
ssh -p 2222, ou cherchezPortdans/etc/ssh/sshd_config; - un pare-feu rejette activement le port (plutôt que de le laisser tomber en silence).
Si vous venez de reconstruire le serveur, c’est le pare-feu. Si ça marchait hier, sshd a planté ou le port a changé.
Correctif complet : connection refused vs timed out, décodé.
2. Connection timed out
Différent de refused : vos paquets s’évanouissent. L’hôte est éteint, l’IP est fausse, ou — le plus souvent sur les machines cloud — un security group / une ACL réseau laisse tomber le port 22 en silence. Vérifiez d’abord les règles de pare-feu du fournisseur, puis si vous êtes sur un réseau qui bloque le port 22 sortant (les Wi-Fi invités des hôtels et des bureaux adorent ça ; essayez un accès basé sur le port 443 ou un autre réseau pour confirmer).
Correctif complet : le même guide refused vs timed out détaille la branche timed-out pas à pas.
3. Permission denied (publickey)
Le champion toutes catégories. Le serveur n’accepte que l’auth par clé, et il n’a accepté aucune des clés que vous avez proposées. Par ordre de probabilité :
- Mauvais utilisateur.
ubuntusur les images Ubuntu,ec2-usersur Amazon Linux,rootsur la plupart des VPS nus. La même clé avec le mauvais nom d’utilisateur produit exactement cette erreur — chaque image cloud choisit son propre utilisateur de connexion, ce qui représente la moitié de la première connexion EC2/VPS (en anglais). - Votre clé n’a pas été proposée.
ssh -vmontre chaque clé essayée. Si votre clé n’est pas dans la liste, désignez-la explicitement :ssh -i ~/.ssh/id_ed25519 user@host. - La clé n’est pas sur le serveur. Sa moitié publique doit figurer sur une ligne de
~user/.ssh/authorized_keys— pour cet utilisateur-là, pas celui de root. - Permissions côté serveur. sshd refuse d’honorer
authorized_keyssi le répertoire personnel,~/.ssh(700) ou le fichier lui-même (600) est inscriptible par le groupe. C’est le classique « j’ai copié la clé et ça ne marche toujours pas ».
Correctif complet : Permission denied (publickey), un correctif rapide et méthodique (en anglais) passe en revue chaque coupable dans l’ordre.
4. Permission denied alors que vous attendiez une invite de mot de passe
Si vous vouliez l’auth par mot de passe et qu’on ne vous l’a jamais demandé, le serveur a PasswordAuthentication no — la plupart des images cloud arrivent ainsi, et c’est le bon réglage par défaut. Entrez via la console du fournisseur ou votre clé existante, puis ajoutez proprement la nouvelle clé plutôt que de réactiver les mots de passe.
5. Host key verification failed / REMOTE HOST IDENTIFICATION HAS CHANGED
La bannière effrayante, avec son air de tête de mort en ASCII. Le serveur a présenté une clé différente de celle que vous aviez acceptée auparavant. Deux explications : la machine a été légitimement reconstruite/réinstallée (le cas de très loin le plus courant), ou quelque chose entre vous et le serveur se fait passer pour lui (le cas pour lequel l’avertissement existe).
Si — et seulement si — vous savez que le serveur a été reconstruit : ssh-keygen -R hostname supprime l’entrée périmée, et la connexion suivante refait confiance. Ne scriptez pas cette suppression à l’aveugle dans votre flux de travail ; la seule fois où l’avertissement est réel, c’est le seul avertissement que vous aurez.
Correctif complet : Host key verification failed, et la bonne manière de le corriger (en anglais).
6. Too many authentication failures
Votre agent a proposé six clés avec enthousiasme, et le MaxAuthTries du serveur a dit stop. Dites au client de ne proposer que la clé voulue :
ssh -o IdentitiesOnly=yes -i ~/.ssh/the_right_key user@host…ou rendez-le permanent dans ~/.ssh/config, par hôte. Si vous trimballez beaucoup de clés, IdentitiesOnly yes sous Host * vous épargnera cette erreur pour toujours.
7. WARNING: UNPROTECTED PRIVATE KEY FILE
Votre clé privée est lisible par d’autres, et le client refuse de l’utiliser. chmod 600 ~/.ssh/id_ed25519. Sous Windows, cela apparaît après avoir copié des clés entre machines ou depuis un disque cloud — corrigez via les propriétés de Sécurité du fichier, ou gardez carrément vos clés hors des dossiers synchronisés.
8. client_loop: send disconnect: Broken pipe (la session qui meurt quand vous regardez ailleurs)
Des connexions inactives coupées par un routeur NAT ou un pare-feu agressif entre vous et le serveur. Les keepalives corrigent ça côté client :
Host *
ServerAliveInterval 30
ServerAliveCountMax 4Deux minutes de silence tolérées, des paquets toutes les 30 secondes pour que la table NAT ne vous oublie jamais. Si les sessions meurent sous charge plutôt qu’au repos, c’est une autre bête — regardez du côté du MTU (les VPN surtout) plutôt que des keepalives.
9. no matching key exchange method found / no matching cipher
Vous parlez à quelque chose d’ancien — un routeur, un switch, un boîtier coincé sur de la crypto héritée. OpenSSH moderne a retiré ces algorithmes pour de bonnes raisons. Réactivez-les pour cet unique hôte seulement, jamais globalement :
Host ancient-switch
KexAlgorithms +diffie-hellman-group14-sha1
Ciphers +aes256-cbcLe message d’erreur nomme les algorithmes proposés par le serveur ; ajoutez le moins mauvais de ceux qu’il liste.
10. ssh_exchange_identification: read: Connection reset by peer
La connexion TCP s’est ouverte puis a été claquée immédiatement, avant même que SSH ne dise bonjour. Les suspects habituels : fail2ban ou DenyHosts a banni votre IP (vérifiez /etc/hosts.deny et la jail de fail2ban depuis une console), sshd est surchargé (MaxStartups épuisé par un scanner qui martèle le port), ou le health check d’un répartiteur de charge mange les connexions. Si c’est fail2ban et que c’est votre propre serveur, le correctif est une connexion console et fail2ban-client unban <your-ip> — puis sortez SSH du radar des scanners ou resserrez la jail pour ne pas être le dommage collatéral de la semaine prochaine.
11. Bad configuration option: pubkeyacceptedalgorithms
Pas un problème de serveur — votre ssh local est trop ancien pour votre fichier de config. PubkeyAcceptedAlgorithms est arrivé dans OpenSSH 8.5 (il a remplacé PubkeyAcceptedKeyTypes) ; donnez cette ligne à un client plus ancien — le ssh macOS d’origine d’un certain âge, une vieille distribution, une image de conteneur minimale — et il refuse carrément d’analyser le fichier. Trois issues : mettez le client à jour (ssh -V vous dit où vous en êtes) ; utilisez l’ancienne orthographe PubkeyAcceptedKeyTypes, que les versions récentes acceptent encore comme alias ; ou protégez la ligne pour que seuls les clients capables la lisent :
Match all
# only OpenSSH >= 8.5 gets here via Include ordering— en pratique, la protection la plus simple consiste à garder les options sensibles à la version dans un fichier séparé tiré par Include, afin qu’un vieux client sur les mêmes dotfiles le saute tout simplement. La même forme d’erreur (Bad configuration option: <something>) signifie toujours la même chose : ce mot est inconnu de ce binaire — vérifiez d’abord l’orthographe de l’option, ensuite la version du binaire.
12. did not receive identification string / invalid ssh identification string
Toutes deux vivent à la toute première étape de SSH — l’échange de bannière, avant toute crypto. did not receive identification string from <ip> est journalisé côté serveur par sshd quand quelque chose a ouvert une connexion TCP vers le port 22 mais n’a jamais envoyé la ligne SSH-2.0-... : un scanner de ports, le health check d’un répartiteur de charge, une sonde de surveillance, ou un client qui a abandonné. Dans vos journaux serveur, c’est presque toujours du bruit de fond, pas une panne — sauf si c’est votre client qui n’arrive pas à se connecter, auquel cas quelque chose sur le trajet (un proxy, un TCP wrapper, un IDS) mange la bannière.
kex_exchange_identification: ... invalid ssh identification string est l’image miroir : quelque chose a bien répondu, mais avec des données non-SSH. Causes habituelles, dans l’ordre : vous avez pointé ssh sur le mauvais port — un serveur HTTP, une base de données, un portail captif qui renvoie du HTML ; un middlebox sur le trajet intercepte la connexion et répond à la place du serveur ; ou une mauvaise configuration de ProxyCommand/ProxyJump fait passer au client quelque chose qui n’est pas un flux SSH — la page d’erreur d’un proxy arrivant là où une bannière devrait être. Vérifiez que vous parlez bien à un sshd : nc <host> 22 devrait afficher une bannière SSH-2.0-OpenSSH... immédiatement. S’il affiche du HTML ou rien, c’est le port (ou l’hôte, ou le saut proxy) qui est faux, pas votre clé.
13. Unspecified GSS failure / debug1: unspecified GSS failure. Minor code may provide more information
Du bruit Kerberos. OpenSSH tente l’auth GSSAPI (Kerberos) avant votre clé par défaut, et si vous n’êtes pas sur un domaine Kerberos — ce qui est le cas de la plupart des gens — elle échoue et journalise ceci au niveau debug, puis se rabat sur l’auth par clé et se connecte sans souci. Si la connexion finit par aboutir, cette ligne est inoffensive ; ignorez-la. Elle ne compte que si vous vous appuyez réellement sur le SSO Kerberos et que l’auth échoue, auquel cas c’est un vrai problème de ticket/domaine (vérifiez klist, le décalage d’horloge et le SPN de l’hôte dans le DNS). Pour couper le bruit sur une configuration sans Kerberos, ajoutez GSSAPIAuthentication no à votre config.
Faites tenir les correctifs
La moitié de ces correctifs sont ponctuels ; l’autre moitié mérite une ligne dans ~/.ssh/config pour qu’ils ne reviennent jamais — keepalives, IdentitiesOnly, ports et identités par hôte. La config bat la mémoire.
L’autre chose qui bat la mémoire, c’est un client qui garde l’état pour vous. Termalin stocke les réglages par hôte — port, utilisateur, clé, keepalives — avec l’hôte lui-même, vérifie les serveurs à la première connexion et avertit haut et fort quand une empreinte change, et sa barre de statistiques montre les constantes de la machine en direct, si bien que « la machine est-elle seulement allumée ? » cesse d’être une étape de diagnostic. Le forfait Free n’a aucune limite d’hôtes — récupérez-le et mettez quelques-unes de ces erreurs à la retraite pour de bon.