SSH connection timed out signifie que le client a envoyé sa requête au port TCP 22 et que rien n'a répondu avant l'expiration du délai d'attente. Les coupables habituels sont un pare-feu qui rejette silencieusement les paquets (ufw ou un security group cloud), un port autre que 22, ou une adresse IP qui a changé. Vous pouvez isoler la cause en quelques minutes avec nc -zv host 22.

SSH connection timed out ou connection refused : ce que chaque erreur vous apprend

Connection refused apparaît lorsque le paquet atteint le serveur et que rien n'écoute sur ce port : l'hôte répond par un rejet immédiat. Connection timed out, c'est le silence : le paquet se perd en route ou un pare-feu l'abandonne sans répondre. Distinguer les deux divise le dépannage par deux.

  • Connection refused : sshd arrêté, à l'écoute sur un autre port, ou un pare-feu configuré pour rejeter (reject) au lieu d'abandonner (drop).
  • Connection timed out : un pare-feu en mode drop, un security group sans règle entrante, une mauvaise IP, une machine éteinte ou un réseau qui bloque le port 22 sortant.
  • No route to host : un problème de routage ou un hôte injoignable sur le réseau local.

5 étapes pour diagnostiquer une erreur SSH connection timed out

Procédez de la vérification la plus rapide à celle qui vous oblige à passer par la console de votre fournisseur :

  1. Confirmez l'adresse. Résolvez le nom avec dig +short host et comparez-le avec l'IP affichée dans le tableau de bord de votre fournisseur.
  2. Testez le port avec nc. nc -zv host 22 vous indique si quelque chose écoute, sans toucher à l'authentification SSH.
  3. Changez de réseau. Si la connexion fonctionne en données mobiles mais pas en wifi, ce réseau bloque le port 22 sortant.
  4. Vérifiez le pare-feu de l'hôte. Depuis la console web du fournisseur, sudo ufw status verbose montre si 22/tcp est autorisé.
  5. Vérifiez le security group. La règle entrante doit accepter TCP 22 depuis votre IP actuelle, pas celle que vous aviez hier.

nc -zv host 22 : tester le port SSH sans s'authentifier

nc avec -z ouvre une connexion TCP vers le port indiqué et la ferme sans envoyer de données ; -v affiche le résultat et -w limite l'attente en secondes. C'est la façon la plus nette de séparer un problème réseau d'un problème SSH.

nc -zv -w 5 server.example.com 22
nc -zv -w 5 203.0.113.10 2222
ssh -v -o ConnectTimeout=10 -p 22 [email protected]

Si nc affiche succeeded ou open (selon la variante installée), le port est joignable et le problème se situe côté SSH : utilisateur, clés ou configuration. S'il reste bloqué jusqu'au délai d'expiration, le blocage est dans le réseau. Avec ssh -v vous verrez la ligne Connecting to ... port 22 ; si Connection established n'apparaît jamais, inutile de vérifier les clés ou les permissions. Les options exactes figurent dans la page de manuel de nc.

OpenSSH écoute par défaut sur le port TCP 22. Si quelqu'un a modifié Port dans sshd_config, une connexion au port 22 renvoie un timeout ou un refus selon ce que fait le pare-feu de ce port ; utilisez -p ou la directive Port dans ~/.ssh/config.

ufw status et security groups : les deux pare-feu qui bloquent SSH

Un serveur cloud se trouve généralement derrière deux filtres : le pare-feu du système d'exploitation, comme ufw sur Ubuntu, et le security group ou pare-feu réseau du fournisseur. Il suffit que l'un des deux abandonne le paquet pour que SSH expire. Vérifiez le premier depuis la console web du fournisseur, et non depuis une autre session SSH qui dépend de la même règle :

sudo ufw status verbose
sudo ufw allow 22/tcp
sudo ufw allow 60000:61000/udp
sudo ss -tlnp | grep sshd

ufw status verbose affiche la politique entrante par défaut et les règles actives ; si incoming est sur deny et qu'il n'existe aucune règle pour 22/tcp, voilà votre timeout. ss -tlnp confirme l'adresse et le port sur lesquels sshd écoute. La règle UDP n'est nécessaire que pour Mosh, qui utilise par défaut les ports 60000-61000.

Dans le security group, passez en revue les règles entrantes : il doit y en avoir une pour TCP 22 dont la source inclut votre IP publique actuelle. Restreindre la source à une seule adresse est une bonne pratique, et c'est aussi la raison la plus fréquente d'un timeout quand vous vous connectez depuis un autre réseau.

IP changée : quand le serveur SSH ou votre téléphone a une nouvelle adresse

Une IP changée produit une erreur connection timed out identique à un blocage par pare-feu, et le changement peut survenir à l'une ou l'autre extrémité.

  • Côté serveur : une instance arrêtée puis redémarrée sans IP statique peut revenir avec une adresse différente. Vérifiez l'enregistrement DNS avec dig +short server.example.com et le HostName dans votre ~/.ssh/config.
  • Côté client : si le security group n'autorise que l'IP du bureau, en données mobiles ou sur le wifi d'un hôtel vous arrivez depuis une autre adresse et le paquet est abandonné.

Pour les machines sans IP publique ni ports exposés, un réseau maillé privé vous évite de courir après les adresses : le serveur est joint via son IP sur le réseau maillé sans ouvrir le port 22 à Internet. Deux options : le réseau maillé privé Prialo et Tailscale.

SSH connection timed out sur iOS et Android : ce qui diffère du poste de travail

Sur un téléphone, le réseau change constamment, si bien que les IP changées et les réseaux qui bloquent le port 22 se présentent bien plus souvent que sur un portable filaire.

Ce que vous vérifiezPoste de travail (Linux/macOS)iOS/Android
Tester le port avec ncnc -zv dans le terminal localnc -zv depuis un autre serveur sur lequel vous êtes connecté
Fréquence des changements d'IPRare : réseau fixe à la maison ou au bureauFréquente : passer du wifi aux données change l'IP publique
Port 22 sortant bloquéRare sur vos propres réseauxCourant sur les wifi invités, d'hôtel et d'aéroport
Session lors d'un changement de réseauSSH se coupe ; tmux conserve votre travailMosh la garde ouverte ; tmux conserve votre travail
Touches Ctrl, Esc et flèchesClavier physiqueDépend de l'app ; termi1 les inclut

Dans termi1, le clavier intégré dispose d'Esc, Ctrl, Tab et des flèches : tuer un nc bloqué avec Ctrl+C ou rappeler la commande précédente ne demande aucune gymnastique. Mosh maintient la session en vie quand vous passez du wifi aux données, mais il lance mosh-server via une connexion SSH initiale : si le port 22 expire, Mosh ne peut pas entrer non plus. L'IA peut saisir une commande comme sudo ufw status verbose dans l'invite à partir d'une phrase dictée, sans appuyer sur Entrée ; sur les connexions marquées comme production, Production Guard retient des modifications comme ufw allow avant qu'elles n'atteignent l'invite. Vous pouvez l'essayer avec le terminal termi1 pour iOS.

Questions fréquentes

Que signifie connection timed out en SSH ?

Connection timed out en SSH signifie que le client a tenté d'ouvrir une connexion TCP vers le serveur et n'a reçu aucune réponse avant l'expiration du délai. Les causes habituelles sont un pare-feu qui abandonne les paquets, un security group sans règle pour le port 22, une mauvaise adresse IP ou un serveur éteint.

Comment vérifier si le port 22 est ouvert sur un serveur ?

Le port 22 d'un serveur se vérifie avec nc -zv -w 5 host 22, qui tente la connexion TCP sans s'authentifier. S'il indique succeeded ou open, le port est joignable et le problème se situe côté SSH ; s'il attend jusqu'à la limite, le réseau ou un pare-feu abandonne le trafic.

Pourquoi SSH fonctionne en données mobiles mais expire en wifi ?

SSH fonctionne en données mobiles mais expire en wifi lorsque ce réseau wifi bloque le port 22 sortant, ce qui est courant sur les réseaux invités et d'entreprise. L'inverse se produit aussi quand le security group n'autorise que l'IP publique du wifi et non l'adresse attribuée par votre opérateur mobile.

Mosh a-t-il besoin d'autres ports ouverts que le 22 ?

Mosh a besoin du port TCP 22 pour la connexion SSH initiale qui lance mosh-server, plus des ports UDP 60000-61000 par défaut. Si le pare-feu ou le security group n'autorise que le port 22, la connexion SSH réussit mais la session Mosh ne parvient jamais à s'établir.