EC2 SSH Connexion Timeout : Quelles Règles de Sécurité Vérifier

Vous venez de lancer une nouvelle instance EC2, vous tapez ssh ec2-user@<ip-publique> et le terminal reste figé pendant 20 secondes avant d'afficher 'Connection timed out' — c'est l'un des problèmes les plus fréquents sur EC2, et il est presque toujours lié à une règle entrante manquante dans le Security Group ou à un problème de routage réseau sous-jacent.

TL;DR — Résumé Rapide

Couche à vérifier	Problème typique	Action corrective
Security Group (SG)	Port 22 TCP absent en entrée	Ajouter une règle inbound TCP/22
Network ACL (NACL)	Règle DENY sur port 22 ou ports éphémères bloqués	Vérifier les règles NACL entrantes ET sortantes
Table de routage	Pas d'Internet Gateway associée au sous-réseau public	Associer une IGW et vérifier la route 0.0.0.0/0
IP publique	Instance sans IP publique ou Elastic IP	Allouer et associer une Elastic IP
Pare-feu OS	iptables ou firewalld bloquant le port 22	Vérifier les règles locales via console série

Comment Fonctionne le Filtrage Réseau sur EC2

Avant de modifier quoi que ce soit, il faut comprendre les deux couches de filtrage qui s'appliquent au trafic entrant vers une instance EC2 dans un VPC. Ces couches sont indépendantes et s'appliquent dans un ordre précis — rater l'une d'elles, et votre connexion SSH ne passera jamais, même si l'autre est correctement configurée.

graph LR Internet(["Internet"]) IGW["Internet Gateway"] NACL["Network ACL
(stateless, sous-réseau)"] SG["Security Group
(stateful, instance)"] OS["Pare-feu OS
(iptables/firewalld)"] EC2["Instance EC2"] Internet -->|"Paquet entrant"| IGW IGW -->|"Route 0.0.0.0/0"| NACL NACL -->|"Règle ALLOW TCP/22"| SG SG -->|"Règle inbound TCP/22"| OS OS -->|"Port 22 ouvert"| EC2 NACL -->|"Règle DENY"| BlockNACL["Paquet bloqué"] SG -->|"Pas de règle"| BlockSG["Paquet bloqué"] style BlockNACL fill:#ff6b6b,color:#fff style BlockSG fill:#ff6b6b,color:#fff style EC2 fill:#2ecc71,color:#fff style IGW fill:#3498db,color:#fff style NACL fill:#e67e22,color:#fff style SG fill:#9b59b6,color:#fff

1. Internet Gateway (IGW) — point d'entrée du trafic public dans le VPC. Sans IGW attachée et sans route 0.0.0.0/0 pointant vers elle, les paquets n'atteignent jamais le sous-réseau.
2. Network ACL (NACL) — filtre stateless au niveau du sous-réseau. Il évalue les règles dans l'ordre numérique croissant. Une règle DENY explicite à priorité haute bloque le trafic avant même que le Security Group ne soit consulté.
3. Security Group — filtre stateful au niveau de l'instance. Si une connexion entrante est autorisée, la réponse sortante est automatiquement permise, sans règle sortante explicite.
4. Instance EC2 — le pare-feu du système d'exploitation (iptables, firewalld) constitue une troisième couche, entièrement gérée dans l'OS.

Le Security Group est stateful : autoriser le port 22 en entrée suffit pour que la session SSH fonctionne dans les deux sens. Le NACL est stateless : il faut explicitement autoriser les ports éphémères en sortie (1024-65535) pour que les réponses TCP reviennent au client.

Étape 1 : Vérifier la Règle Inbound SSH dans le Security Group EC2

C'est la cause numéro un du timeout SSH. Le Security Group associé à l'instance doit contenir une règle autorisant le trafic TCP entrant sur le port 22. Par défaut, un nouveau Security Group n'autorise aucun trafic entrant — tout est implicitement refusé.

Commencez par identifier le Security Group attaché à l'instance, puis listez ses règles entrantes :

# Récupérer l'ID du Security Group associé à l'instance
aws ec2 describe-instances \
  --instance-ids i-0abcdef1234567890 \
  --query 'Reservations[*].Instances[*].SecurityGroups' \
  --output table \
  --region us-east-1

# Lister les règles inbound du Security Group
aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[*].IpPermissions' \
  --output table \
  --region us-east-1

Si aucune règle TCP/22 n'apparaît, ajoutez-la. Remplacez 203.0.113.0/32 par votre adresse IP publique réelle — ouvrir le port 22 à 0.0.0.0/0 expose l'instance à des tentatives de brute-force en continu.

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 22 \
  --cidr 203.0.113.0/32 \
  --region us-east-1

La règle est effective immédiatement — pas besoin de redémarrer l'instance. Si le timeout persiste après cette modification, la cause est ailleurs dans la pile réseau.

Étape 2 : Vérifier les Network ACLs du Sous-réseau

Les Security Groups reçoivent toute l'attention, mais les Network ACLs bloquent silencieusement le trafic en amont. Contrairement aux Security Groups, les NACLs sont stateless — une règle DENY sur les ports éphémères en sortie casse la session TCP même si le port 22 entrant est autorisé. C'est le cas classique où le SYN arrive, mais l'ACK ne revient jamais.

# Trouver le sous-réseau de l'instance
aws ec2 describe-instances \
  --instance-ids i-0abcdef1234567890 \
  --query 'Reservations[*].Instances[*].SubnetId' \
  --output text \
  --region us-east-1

# Trouver le NACL associé au sous-réseau
aws ec2 describe-network-acls \
  --filters Name=association.subnet-id,Values=subnet-0abc123456789def0 \
  --query 'NetworkAcls[*].{ID:NetworkAclId,Entries:Entries}' \
  --output table \
  --region us-east-1

Dans la sortie, vérifiez deux choses :

• Règles INBOUND : une règle ALLOW sur le port 22 TCP doit exister avec un numéro de règle inférieur à toute règle DENY couvrant le même port.
• Règles OUTBOUND : les ports éphémères (1024-65535) doivent être autorisés en sortie pour que les réponses TCP atteignent le client SSH.

Étape 3 : Vérifier la Table de Routage et l'Internet Gateway

Un Security Group parfaitement configuré ne sert à rien si les paquets n'ont pas de chemin vers Internet. Pour qu'une instance dans un sous-réseau public soit joignable depuis l'extérieur, deux conditions doivent être réunies simultanément : une Internet Gateway attachée au VPC, et une route 0.0.0.0/0 pointant vers cette IGW dans la table de routage du sous-réseau.

# Vérifier que le VPC a une Internet Gateway attachée
aws ec2 describe-internet-gateways \
  --filters Name=attachment.vpc-id,Values=vpc-0abc123456789def0 \
  --query 'InternetGateways[*].{ID:InternetGatewayId,State:Attachments[0].State}' \
  --output table \
  --region us-east-1

# Vérifier la table de routage du sous-réseau
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0abc123456789def0 \
  --query 'RouteTables[*].Routes' \
  --output table \
  --region us-east-1

Si la route 0.0.0.0/0 est absente ou pointe vers un NAT Gateway au lieu d'une IGW, l'instance n'est pas directement accessible depuis Internet — c'est un sous-réseau privé, pas public, quelle que soit son appellation dans la console.

Étape 4 : Confirmer que l'Instance a une IP Publique

Même avec un routage correct, si l'instance n'a pas d'adresse IP publique ou d'Elastic IP, il n'y a tout simplement rien à atteindre depuis l'extérieur. Vérifiez l'état de l'adressage public :

aws ec2 describe-instances \
  --instance-ids i-0abcdef1234567890 \
  --query 'Reservations[*].Instances[*].{PublicIP:PublicIpAddress,PublicDNS:PublicDnsName,State:State.Name}' \
  --output table \
  --region us-east-1

Si PublicIP est null, l'instance a été lancée dans un sous-réseau où l'attribution automatique d'IP publique est désactivée. Allouez et associez une Elastic IP :

# Allouer une Elastic IP
aws ec2 allocate-address \
  --domain vpc \
  --region us-east-1

# Associer l'Elastic IP à l'instance (remplacer eipalloc-xxxxx par l'AllocationId retourné)
aws ec2 associate-address \
  --instance-id i-0abcdef1234567890 \
  --allocation-id eipalloc-0abc123456789def0 \
  --region us-east-1

Diagnostic Complet : Flux de Décision SSH EC2

flowchart TD A(["Tentative SSH vers EC2"]) --> B{"Instance a
une IP publique ?"} B -->|Non| B1["Allouer une Elastic IP
et l'associer"] B -->|Oui| C{"IGW attachée au VPC
et route 0.0.0.0/0 ?"} C -->|Non| C1["Attacher une IGW
et créer la route"] C -->|Oui| D{"NACL autorise
TCP/22 entrant ?"} D -->|Non| D1["Ajouter règle NACL
INBOUND ALLOW TCP/22"] D -->|Oui| E{"NACL autorise
ports éphémères sortants ?"} E -->|Non| E1["Ajouter règle NACL
OUTBOUND ALLOW 1024-65535"] E -->|Oui| F{"Security Group
autorise TCP/22 entrant ?"} F -->|Non| F1["Ajouter règle SG
inbound TCP/22"] F -->|Oui| G{"Pare-feu OS
bloque port 22 ?"} G -->|Oui| G1["Vérifier via SSM
Session Manager"] G -->|Non| H(["Connexion SSH réussie"]) style H fill:#2ecc71,color:#fff style B1 fill:#e74c3c,color:#fff style C1 fill:#e74c3c,color:#fff style D1 fill:#e74c3c,color:#fff style E1 fill:#e74c3c,color:#fff style F1 fill:#e74c3c,color:#fff style G1 fill:#e67e22,color:#fff

1. IP publique présente ? — Sans adresse publique, aucun paquet entrant ne peut être routé vers l'instance depuis Internet.
2. IGW attachée et route 0.0.0.0/0 ? — Le VPC doit avoir une passerelle Internet et le sous-réseau une route par défaut vers cette passerelle.
3. NACL autorise TCP/22 entrant et ports éphémères sortants ? — Les deux directions sont nécessaires car les NACLs sont stateless.
4. Security Group autorise TCP/22 entrant ? — Règle inbound explicite requise ; le SG est stateful donc pas besoin de règle sortante pour SSH.
5. Pare-feu OS bloque le port 22 ? — Vérifiable uniquement via la console série EC2 ou AWS Systems Manager Session Manager si SSH est inaccessible.

Cas Réel : Le Security Group Était Correct, Mais le Timeout Persistait

Sur un déploiement récent, la règle TCP/22 était bien présente dans le Security Group, l'IGW était attachée, l'instance avait une IP publique — et pourtant, le timeout persistait. Diagnostic initial : problème de clé SSH ou de configuration sshd. Mauvaise piste.

En inspectant les NACLs, la règle OUTBOUND par défaut avait été remplacée par une règle ALLOW uniquement sur les ports 80 et 443. Les ports éphémères (1024-65535) étaient implicitement refusés en sortie. Le client SSH envoyait le SYN, l'instance répondait avec SYN-ACK, mais la réponse était bloquée au niveau NACL avant d'atteindre le client. Résultat observable : timeout côté client, aucune erreur dans les logs sshd, aucune trace dans les Security Group flow logs.

La correction : ajouter une règle NACL OUTBOUND ALLOW sur les ports 1024-65535 TCP. Connexion SSH établie immédiatement après.

Un Security Group stateful masque les problèmes NACL stateless — c'est précisément pourquoi les NACLs sont diagnostiquées en dernier alors qu'elles devraient être vérifiées en deuxième.

Utiliser AWS Systems Manager Session Manager comme Alternative SSH

Si le débogage réseau prend du temps et que vous devez accéder à l'instance immédiatement, AWS Systems Manager Session Manager permet d'ouvrir un shell sans port 22 ouvert, sans IP publique, et sans clé SSH — à condition que l'agent SSM soit installé et que le rôle IAM de l'instance inclue la politique AmazonSSMManagedInstanceCore.

aws ssm start-session \
  --target i-0abcdef1234567890 \
  --region us-east-1

C'est utile pour diagnostiquer un pare-feu OS ou vérifier la configuration sshd sans toucher aux règles réseau.

IAM Minimal pour les Opérations de Diagnostic

Les commandes de diagnostic ci-dessus nécessitent des permissions en lecture sur EC2. Voici la politique minimale requise :

🔽 Politique IAM de diagnostic EC2 (cliquer pour développer)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeNetworkAcls",
        "ec2:DescribeRouteTables",
        "ec2:DescribeInternetGateways",
        "ec2:DescribeAddresses"
      ],
      "Resource": "*"
    }
  ]
}

Les actions Describe* sur EC2 requièrent "Resource": "*" — elles ne supportent pas les restrictions par ARN de ressource individuelle selon la référence d'autorisation de service AWS.

Résolution EC2 SSH Timeout : Prochaines Étapes

Le timeout SSH sur EC2 suit presque toujours le même chemin de diagnostic : Security Group → NACL → routage → IP publique → OS. Vérifiez ces couches dans l'ordre et vous identifierez la cause en moins de dix minutes. Pour aller plus loin :

• Consultez la documentation officielle AWS sur les Security Groups pour les comportements stateful détaillés.
• Lisez la documentation sur les Network ACLs pour comprendre l'évaluation des règles stateless.
• Activez VPC Flow Logs sur le sous-réseau pour capturer les paquets ACCEPT/REJECT et confirmer à quelle couche le trafic est bloqué.

Glossaire

Terme	Définition
Security Group	Pare-feu virtuel stateful au niveau de l'instance EC2. Les connexions autorisées en entrée permettent automatiquement les réponses sortantes.
Network ACL (NACL)	Filtre stateless au niveau du sous-réseau VPC. Les règles entrantes et sortantes sont évaluées indépendamment, dans l'ordre numérique croissant.
Internet Gateway (IGW)	Composant VPC permettant la communication entre les instances du VPC et Internet. Doit être attachée au VPC et référencée dans la table de routage.
Elastic IP	Adresse IPv4 publique statique allouée à un compte AWS et associable à une instance EC2 ou une interface réseau.
Ports éphémères	Plage de ports temporaires (1024-65535 selon RFC) utilisée par le système d'exploitation client pour les connexions TCP sortantes. Doit être autorisée en sortie dans les NACLs.