Aller au contenu

AWS Mis à jour le 2026-07-04

SSH vers EC2 : « connection timed out » — les cinq causes en ordre de probabilité

Une erreur « connection timed out » en SSH vers EC2 signifie que vos paquets sont abandonnés avant d'atteindre sshd. Voici les cinq causes classées par probabilité, et comment tester chacune en quelques minutes.

ssh: connect to host ... port 22: Operation timed out signifie que vos paquets n’ont jamais reçu de réponse — ils ont été abandonnés silencieusement quelque part entre votre portable et l’instance. C’est une panne différente de Connection refused (l’instance a répondu, mais rien n’écoute) ou de Permission denied (sshd a répondu et a refusé votre clé). Un délai d’attente est presque toujours un problème de chemin réseau, et sur EC2 ce chemin casse à exactement cinq endroits. En ordre de probabilité : le groupe de sécurité, une IP publique ou une route manquante, un ACL réseau, le pare-feu du système d’exploitation sur l’instance, et un blocage sortant de votre côté.

Ce qui se passe

Une connexion SSH vers une instance EC2 traverse plusieurs filtres en séquence : les règles de sortie de votre réseau local, Internet, la table de routage du VPC et la passerelle Internet, l’ACL réseau du sous-réseau, le groupe de sécurité de l’instance, puis le pare-feu du système d’exploitation (iptables, nftables, ufw, firewalld) avant d’atteindre sshd. Les groupes de sécurité et les NACL n’envoient pas de réinitialisation TCP quand ils bloquent le trafic — ils abandonnent le paquet sans rien dire, ce qui est exactement ce que le client perçoit comme un délai d’attente.

Le classement par probabilité découle du comportement par défaut de ces couches. Les groupes de sécurité refusent tout trafic entrant sauf règle explicite, et la source autorisée est habituellement une IP précise — donc le déclencheur le plus fréquent, c’est que votre IP publique a changé (nouveau bureau, VPN activé, réassignation du fournisseur) et que l’ancienne règle en /32 ne correspond plus. Les IP publiques manquantes viennent ensuite : les instances lancées dans un sous-réseau privé, ou dans un sous-réseau où l’assignation automatique d’IP publique est désactivée, n’ont aucune route de retour vers vous. Les NACL sont moins fréquents parce que le NACL par défaut autorise tout, mais quelqu’un qui les resserre en oubliant les ports éphémères de retour casse SSH d’une façon qui mystifie le monde pendant des heures. Les pare-feu du système d’exploitation et les blocages de sortie corporatifs complètent la liste.

Quoi vérifier en premier

  • L’instance roule-t-elle vraiment, avec les deux vérifications d’état réussies? Une instance arrêtée ou dégradée donne aussi un délai d’attente. EC2 > Instances > Vérifications de statut.
  • Quelle est votre IP publique actuelle, et le groupe de sécurité l’autorise-t-il? Vérifiez https://checkip.amazonaws.com et comparez avec la règle entrante pour le port 22.
  • L’instance a-t-elle une IPv4 publique (ou espérez-vous joindre une IP privée via VPN ou appairage)? Pas d’IP publique et pas de chemin privé : aucune connexion possible, point final.
  • Utilisez-vous la bonne adresse? Après un arrêt/redémarrage, une IP publique non élastique change. Se connecter à l’IP d’hier expire contre l’instance de quelqu’un d’autre, ou contre rien du tout.
  • EC2 Instance Connect fonctionne-t-il depuis la console? Si la connexion par navigateur fonctionne, l’instance et sshd sont corrects et le problème se trouve sur le chemin réseau entre vous et AWS.

Comment vérifier

Confirmez ce que vous composez et ce qu’AWS pense que l’instance possède :

# IP publique, état, sous-réseau et groupes de sécurité de l'instance
aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].[State.Name,PublicIpAddress,PrivateIpAddress,SubnetId,SecurityGroups]' \
  --output json

# Que permet réellement le groupe de sécurité en entrée sur le 22?
aws ec2 describe-security-group-rules \
  --filters Name=group-id,Values=sg-0123456789abcdef0 \
  --query 'SecurityGroupRules[?IsEgress==`false`]'

Vérifiez la table de routage du sous-réseau pour une route vers la passerelle Internet, puis le NACL :

# Table de routage du sous-réseau — cherchez 0.0.0.0/0 -> igw-...
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0123456789abcdef0 \
  --query 'RouteTables[].Routes'

# Entrées NACL du sous-réseau
aws ec2 describe-network-acls \
  --filters Name=association.subnet-id,Values=subnet-0123456789abcdef0 \
  --query 'NetworkAcls[].Entries'

Si vous voulez qu’AWS trace tout le chemin pour vous, VPC Reachability Analyzer (VPC > Reachability Analyzer) prend votre source, l’instance et le port 22, et vous dit exactement quel saut bloque. Il y a des frais modestes par analyse, mais ça met fin aux devinettes. La liste de vérification complète de connectivité se trouve dans la documentation EC2 à https://docs.aws.amazon.com/ec2/.

Le correctif

  1. Le groupe de sécurité n’autorise pas votre IP actuelle — la cause la plus fréquente, et de loin. Ajoutez ou mettez à jour la règle entrante : port 22, source = votre IP publique actuelle en /32. Ne « réglez » pas ça avec 0.0.0.0/0 — ça transforme le délai d’attente en cible de force brute. Si les IP de votre équipe changent souvent, remplacez le SSH public par AWS Systems Manager Session Manager ou un point de terminaison EC2 Instance Connect plutôt que d’élargir la règle.
  2. Pas d’IP publique, ou pas de route vers une passerelle Internet — si PublicIpAddress est vide, associez une IP élastique, ou acceptez que c’est une instance privée et joignez-la par le chemin prévu : Session Manager, un bastion, un VPN, ou un point de terminaison EC2 Instance Connect. Si la table de routage du sous-réseau n’a pas de route 0.0.0.0/0 -> igw-, c’est un sous-réseau privé et une IP publique seule ne servira à rien.
  3. Un ACL réseau bloque la connexion ou le chemin de retour — les NACL sont sans état, donc il faut autoriser le port 22 entrant et les ports éphémères sortants 1024-65535. Si quelqu’un a personnalisé le NACL, vérifiez les deux directions. Les détails sur la distinction avec/sans état sont dans groupes de sécurité vs NACL.
  4. Le pare-feu du système d’exploitation sur l’instance — ufw, firewalld ou des règles iptables brutes peuvent abandonner le port 22 même quand chaque couche AWS l’autorise. Utilisez la console série EC2 ou Session Manager pour entrer sans SSH et vérifiez sudo iptables -L -n ou sudo ufw status.
  5. Votre côté bloque le 22 sortant — les réseaux d’hôtel et d’entreprise bloquent couramment le SSH sortant. Testez depuis un point d’accès cellulaire ou un autre réseau. Si ça se connecte, l’instance n’a jamais été le problème.

Quand c’est la mauvaise approche

Si l’erreur réelle est Connection refused ou Permission denied, arrêtez — cette liste vous fera perdre votre temps, parce que les paquets atteignent déjà l’instance. Refused veut dire que sshd est arrêté ou sur un autre port; permission denied, que c’est une affaire de clés ou de noms d’utilisateur. Et si vous vous surprenez à ouvrir le port 22 au monde entier juste pour faire disparaître un délai d’attente, la meilleure décision est de retirer complètement le SSH public : Session Manager donne un accès shell avec authentification IAM, journalisation, et zéro règle entrante.

Erreurs courantes

  • Ouvrir 0.0.0.0/0 sur le port 22 « temporairement » et l’oublier — tous les scanneurs d’Internet le trouvent en quelques minutes.
  • Chasser le problème sur l’instance pendant une heure alors que le vrai changement était votre propre adresse IP après un VPN ou un changement de réseau.
  • Modifier le mauvais groupe de sécurité — une instance peut en avoir plusieurs, et la règle ajoutée peut se trouver sur un groupe que l’instance n’utilise pas.
  • Oublier qu’un arrêt/redémarrage change une IP publique non élastique, puis déboguer un délai d’attente contre l’ancienne adresse.

Prévention

  • Remplacez le SSH public par Session Manager ou un point de terminaison EC2 Instance Connect — aucune règle entrante, aucune liste d’IP à entretenir.
  • Si vous devez garder le port 22 ouvert, restreignez-le à une plage corporative stable ou à l’IP de sortie du VPN, et documentez-le.
  • Utilisez des IP élastiques (ou des noms DNS) pour tout ce que vous joignez par adresse, pour qu’un arrêt/redémarrage ne déplace pas la cible en silence.
  • Laissez le NACL par défaut tranquille sauf besoin concret; appliquez la politique dans les groupes de sécurité, où le suivi d’état travaille pour vous.
  • Mettez une alarme sur StatusCheckFailed pour qu’une instance dégradée ne se déguise pas en problème réseau.

La plupart des délais d’attente SSH se règlent en cinq minutes une fois qu’on teste les couches dans l’ordre plutôt qu’au hasard. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.