termalConnection refused et Connection timed out ont l’air de jumeaux — SSH ne s’est pas connecté dans les deux cas — mais ce sont des constats opposés, qui pointent vers des moitiés différentes de la pile. Savoir laquelle vous avez sous les yeux divise par deux la liste des suspects avant que vous ne tapiez la moindre commande de diagnostic. Voici la routine de deux minutes : ce que chaque erreur prouve, l’unique sonde qui les sépare de tout le reste, et une liste de contrôle pour chaque branche. (Pour les erreurs qui surviennent après la réussite de la connexion TCP — échecs d’auth, avertissements de clé d’hôte, sessions qui meurent — voyez le décodeur.)
| Erreur | Ce qu’elle prouve | Cause probable | Première commande |
|---|---|---|---|
Connection refused | L’hôte est allumé et a activement dit non (un RST est revenu) | Rien n’écoute sur ce port, ou une règle de pare-feu REJECT | ss -tlnp | grep sshd depuis la console |
Connection timed out | Rien n’est revenu du tout — silence sur le trajet | Mauvaise IP, hôte éteint, ou un DROP silencieux (security group / pare-feu cloud) | nc -vz host 22, puis vérifiez le pare-feu cloud |
Ce que chaque erreur prouve réellement
Connection refused signifie que la machine vous a répondu. Votre SYN TCP a atteint un hôte vivant, et l’hôte a activement dit non — un paquet RST ou un ICMP port-unreachable est revenu. C’est une quantité surprenante de bonnes nouvelles : l’IP est bonne, la route fonctionne, l’hôte est allumé, et rien sur le trajet ne mange vos paquets. Le problème est étroit : rien n’écoute sur ce port, ou une règle de pare-feu le rejette (sans le laisser tomber en silence).
Connection timed out signifie le silence. Vos paquets sont partis et rien n’est jamais revenu. Cela ne prouve presque rien sur le serveur — il peut être éteint, l’IP peut être fausse, ou (le plus souvent) quelque chose entre vous et lui laisse tomber les paquets en silence : un security group cloud, un pare-feu avec une politique DROP, un trou noir NAT ou VPN.
Un moyen mnémotechnique : refused = la machine vous a parlé ; timed out = elle ne l’a jamais fait. Refused est un problème d’hôte. Timed out est généralement un problème de trajet.
Étape 1 : sondez le port, pas l’hôte
Laissez ping de côté comme premier geste — il teste la mauvaise chose dans les deux sens. Un hôte qui répond au ping peut tout de même laisser tomber le port 22 (les pare-feu cloud filtrent par port), et un hôte qui ignore le ping peut servir le SSH très bien (l’ICMP est bloqué un peu partout). Le ping ne prouve rien dont vous avez besoin.
Sondez le port réel :
nc -vz example.com 22(Pas de netcat ? telnet example.com 22 fonctionne — toute sortie commençant par SSH-2.0-... signifie que sshd a répondu.) Trois issues :
Connection refused— prenez la branche refused ci-dessous.- Se bloque, puis expire — prenez la branche timed-out.
- Réussit — le TCP va bien et votre problème est à l’intérieur de SSH lui-même : mauvais utilisateur ou mauvaise clé (
Permission denied (publickey)a son propre guide (en anglais)), une clé d’hôte qui ne correspond pas, ou quelque chose quessh -vnommera franchement.
La branche refused : trouver ce qui (n’)écoute (pas)
Vous aurez besoin d’un autre moyen d’accéder à la machine — la console web du fournisseur existe pour exactement ce moment.
sshd tourne-t-il ?
systemctl status sshd # the unit is "ssh" on Debian/UbuntuS’il est mort, ne le redémarrez pas bêtement — cherchez pourquoi : journalctl -u sshd (ou -u ssh) montre comment il s’est arrêté. Une cause fréquente est une modification de config qui ne s’analyse pas ; sshd -t valide le fichier et nomme la mauvaise ligne avant que vous ne redémarriez vers le même échec.
Écoute-t-il là où vous le croyez ?
sudo ss -tlnp | grep sshdDeux pièges se cachent dans cette sortie. Le port : quelqu’un a déplacé SSH vers 2222 et vous frappez sur 22 — connectez-vous avec ssh -p 2222, puis épinglez-le par hôte dans ~/.ssh/config (en anglais) pour ne jamais le redéduire. L’adresse : une ligne ListenAddress peut lier sshd à une seule interface, de sorte qu’il répond sur l’IP privée et refuse sur la publique.
Le pare-feu local rejette-t-il ? sudo ufw status, sudo iptables -L -n, ou nft list ruleset — cherchez des règles REJECT couvrant votre port. Une règle REJECT produit exactement cette erreur : l’hôte est allumé, sshd écoute peut-être même, et le pare-feu répond à sa place.
Avez-vous été banni ? L’action par défaut de fail2ban rejette, donc un bannissement ressemble à Connection refused — depuis votre seule IP. L’indice : ça marche depuis un partage de connexion de téléphone mais pas depuis votre réseau. Depuis la console : fail2ban-client status sshd, puis fail2ban-client unban <your-ip> — et corrigez ce qui a réessayé un mauvais identifiant assez souvent pour mériter le bannissement.
La branche timed-out : trouver où meurent les paquets
Confirmez l’adresse d’abord. C’est gênant exactement une fois. ssh -v affiche l’IP qu’il compose vraiment — comparez-la au tableau de bord du fournisseur. Un DNS périmé après une migration, et l’IP élastique qui n’a pas survécu à l’arrêt d’une instance, sont deux classiques.
Vérifiez ensuite le pare-feu cloud, car c’est la réponse la plupart du temps. Les security groups (AWS), les NSG (Azure) et les règles de pare-feu VPC (GCP) laissent tomber le trafic entrant par défaut — en silence, ce qui est précisément un timeout. Cherchez une règle entrante autorisant TCP 22 depuis votre adresse. La variante sournoise : une règle verrouillée sur « My IP » il y a des mois, et votre IP a changé depuis. Les ACL réseau au niveau du sous-réseau sont une seconde couche, moins fréquentée, à regarder quand le security group semble correct.
Tracez le trajet quand les règles cloud sont correctes :
traceroute example.com # mtr example.com for a live view
sudo traceroute -T -p 22 example.com # TCP to the actual port — closest to the truthLe traceroute simple utilise UDP ou ICMP, que les pare-feu traitent différemment de TCP 22 — la forme -T -p 22 teste ce que SSH vit vraiment. L’endroit où les sauts cessent de répondre est à peu près là où meurent vos paquets.
Soupçonnez votre propre côté. Les réseaux invités d’hôtels, de cafés et de bureaux bloquent couramment le port 22 sortant, et les VPN d’entreprise le réacheminent ou le laissent tomber. Le test d’isolement, c’est le partage de connexion du téléphone : si le SSH marche là, votre serveur va bien et c’est le réseau sur lequel vous étiez qui pose problème.
Un pare-feu avec une politique DROP sur l’hôte lui-même ressemble de l’extérieur exactement à un drop côté cloud — si vous avez un accès console, vérifiez aussi iptables/nftables sur la machine.
L’exotique : le port knocking. Un serveur qui fait tourner knockd laisse tout tomber jusqu’à voir une séquence secrète de tentatives de connexion sur d’autres ports. Si un prédécesseur a monté la machine et que chaque port expire de partout, renseignez-vous avant de brûler un après-midi sur des théories de routage.
Gardez la version de deux minutes
Toute la routine se compresse bien : sondez le port avec nc -vz. Refused → connectez-vous en console, vérifiez sshd, le port d’écoute, les règles REJECT, fail2ban. Timed out → confirmez l’IP, vérifiez le security group cloud, puis traceroute et votre propre réseau. Le ping n’y apparaît nulle part.
Les faits récurrents — quel port, quel utilisateur, quel hôte a besoin de keepalives — ont leur place dans ~/.ssh/config (en anglais), pas dans votre mémoire. Et une partie du diagnostic peut être un état acquis plutôt qu’une course en plein incident : Termalin stocke le port, l’utilisateur, la clé et les réglages de keepalive avec chaque hôte enregistré et affiche le statut en direct par hôte — si bien que « la machine est-elle seulement allumée ? » et « c’était quel port, déjà ? » trouvent réponse avant que vous ne vous connectiez, et le serveur qui n’écoute que sur 2222 cesse d’être une chose que vous redécouvrez chaque trimestre.
Termalin est un client SSH gratuit et multiplateforme qui garde les ports, utilisateurs, clés et keepalives par hôte avec l’hôte et affiche le statut des hôtes en direct — téléchargez-le, ou parcourez la liste complète des fonctionnalités.