Le message d’erreur « Connexion refusée » ou « Délai de connexion expiré » s’affiche lorsque je tente de me connecter à mon instance EC2 via SSH. Comment corriger ces erreurs ?

Lecture de 10 minute(s)

Le message d’erreur « Connexion refusée » ou « Délai de connexion expiré » s’affiche lorsque je tente de me connecter à mon instance Amazon Elastic Compute Cloud (Amazon EC2) via SSH.

Brève description

Message d’erreur : « ssh: connect to host ec2-X-X-X-X.compute-1.amazonaws.com port 22: Délai de connexion expiré. » Ce message d’erreur provient du client SSH. Il indique que le serveur n’a pas répondu au client et qu’il y a eu un abandon du programme client (délai expiré). Voici quelques causes courantes à l’origine de cette erreur :

Le groupe de sécurité ou l’ACL réseau n’autorise pas l’accès.
Un pare-feu est installé sur le système d’exploitation de l’instance.
Il existe un pare-feu entre le client et le serveur.
L’hôte n’existe pas.

Message d’erreur : « ssh: connect to host ec2-X-X-X-X.compute-1.amazonaws.com port 22: Connexion refusée. » Ce message a été émis à distance par un hôte. Voici quelques causes courantes à l’origine de cette erreur :

L’hôte a atteint l’instance, mais aucun service n’écoutait sur le port SSH.
Un pare-feu a causé un blocage et a été configuré pour rejeter le package au lieu de le supprimer.

Résolution

Erreur « Délai de connexion expiré »

En cas d’erreur « Délai de connexion expiré », vérifiez les points suivants :

L’adresse IP ou le nom d’hôte de l’instance est correct.
Les surveillances de l’état ne signalent pas de problème sur l’instance.
Le groupe de sécurité de l’instance autorise le trafic entrant sur le port TCP 22.
Les ACL réseau du sous-réseau de l’instance autorisent le trafic entrant sur le port TCP 22 et autorisent le port éphémère pour le trafic sortant.
La table de routage du sous-réseau de l’instance est configurée correctement pour connecter l’instance EC2 et le client SSH.
Aucun pare-feu ne bloque la connexion entre le client SSH et l’instance EC2.
Le SSH n’est pas bloqué par les TCP Wrappers de l’instance (voir le site Web de Red Hat).

Remarque : les deux dernières étapes de vérification nécessitent d’avoir accès à l’instance au niveau du système d’exploitation.

Erreur « Connexion refusée »

En cas d’erreur « Connexion refusée », vérifiez les points suivants :

Il n’existe aucun pare-feu sur l’instance qui rejette la connexion SSH.
Le démon SSH (sshd) est en cours d’exécution et à l’écoute sur le port 22.

Remarque : ces deux étapes de vérification nécessitent d’avoir accès à l’instance au niveau du système d’exploitation.

Si ces deux surveillances de l’état ne signalent pas de problème sur l’instance, utilisez l’une des quatre méthodes suivantes avec votre configuration

Méthode 1 : utilisation de l’EC2 Serial Console pour Linux.
Méthode 2 : utilisation du Gestionnaire de session d’AWS Systems Manager.
Méthode 3 : exécution du runbook d’automatisation AWSSupport-TroubleshootSSH.
Méthode 4 : utilisation d’un script de données utilisateur.

Méthode 1 : utilisation de l’EC2 Serial Console pour Linux

Si cette console est configurée, vous pouvez utiliser l’EC2 Serial Console pour Linux pour résoudre les problèmes liés au système d’exploitation sur les types d’instances Nitro pris en charge. La console de série permet de résoudre les problèmes de démarrage, de configuration réseau et de configuration SSH. L’accès à la console de série se fait via la console Amazon EC2 ou via l’interface de la ligne de commande AWS (AWS CLI).

Avant d’utiliser la console de série, vous devez lui accorder un accès au niveau du compte. Créez ensuite des politiques de gestion des identités et des accès AWS (AWS IAM) accordant l’accès à vos utilisateurs IAM.

Remarque : chaque instance qui utilise la console de série doit inclure au moins un utilisateur Linux avec mot de passe disposant d’un accès sudo.

Pour en savoir plus sur la configuration de l’EC2 Serial Console pour Linux, consultez la page Configurer l’accès à l’EC2 Serial Console. S’il n’existe aucun compte Linux avec un mot de passe de connexion configuré, vous devez exécuter ssm-user pour réinitialiser le mot de passe d’un compte disposant d’un accès sudo. Pour en savoir plus sur l’exécution des commandes ssm-user, consultez la page Gestion des autorisations de compte sudo ssm-user sous Linux et macOS.

Une fois la configuration effectuée, connectez-vous à l’instance EC2 via l’EC2 Serial console avec un utilisateur Linux configuré par mot de passe.

Exécutez ensuite la commande suivante. Ces commandes vérifient que les connexions SSH ne sont pas bloquées par le pare-feu du système d’exploitation ou par le TCP wrapper. Elles vérifient également que le service sshd est en cours d’exécution et à l’écoute sur le port 22.

1. Si vous avez configuré des règles iptables, exécutez la commande suivante pour ajouter une règle dans iptables acceptant les connexions SSH sur le port 22 par défaut :

$ sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

Dans la mesure où il est préférable d’utiliser des groupes de sécurité plutôt qu’un pare-feu basé sur le système d’exploitation, le pare-feu peut être complètement désactivé. Pour désactiver le pare-feu basé sur le système d’exploitation, utilisez l’une des commandes suivantes, en fonction de votre système d’exploitation :

Important : les commandes suivantes éliminent toutes les règles iptables principales. Elles ajoutent également une règle autorisant les connexions SSH entrantes. En outre, elles remplacent la politique par défaut de la chaîne principale par ACCEPT, afin que la connexion réseau à distance ne soit pas affectée lorsque la règle iptables est vidée. Dans la mesure où ces commandes vident les iptables principaux, elles vident également les règles existantes.

Distributions qui utilisent UFW (Ubuntu, Debian)

$ sudo iptables -F
$ sudo iptables -P INPUT ACCEPT
$ sudo ufw disable

Distributions qui utilisent firewalld (Red Hat, CentOS)

$ sudo iptables -F
$ sudo iptables -P INPUT ACCEPT
$ sudo systemctl disable firewalld

Remarque : une fois que l’accès à votre instance a été rétabli, vérifiez la configuration de votre pare-feu (UFW, firewalld et iptables).

2. Vérifiez que le SSH est en cours d’exécution et que le port TCP SSH (22) est à l’écoute :

$ sudo systemctl restart sshd
$ sudo ss -tpln | grep -iE '22|ssh'
LISTEN 0 128 *:22 *:* users:(("sshd",pid=1901,fd=3))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1901,fd=4))

Remarque : si votre système ne dispose pas de la commande ss, vous pouvez utiliser l’ancienne commande netstat avec la syntaxe présentée dans l’exemple précédent.

3. Vérifiez que le TCP wrapper ne bloque pas une connexion SSH :

$ if [[ $( cat /etc/hosts.[ad]* | grep -vE '^#' | awk 'NF' | wc -l) -ne 0 ]];\
then sudo sed -i '1i sshd2 sshd : ALL: allow' /etc/hosts.allow; fi

4. Connectez-vous ensuite à l’instance via SSH.

5. Déconnectez la session EC2 Serial Console si elle n’est plus requise.

Méthode 2 : utilisation du Gestionnaire de session d’AWS Systems Manager

Remarque : pour utiliser cette méthode, l’instance doit être une instance gérée par SSM et son agent SSM doit présenter l’état ping En ligne. Pour en savoir plus sur le Gestionnaire de session et obtenir une liste complète des prérequis, consultez la page Configuration du Gestionnaire de session.

Pour vérifier que les connexions SSH ne sont pas bloquées par le pare-feu ou le TCP wrapper et que le service sshd est en mode exécution et à l’écoute sur le port 22 :

1. Ouvrez AWS Systems Manager.

2. Démarrez une session pour l’instance à l’aide du Gestionnaire de session.

3. Suivez les étapes 1 à 4 de la méthode 1 : utilisation de l’EC2 Serial Console pour Linux.

4. Fermez la session du Gestionnaire de session si elle n’est plus requise.

Méthode 3 : exécution du runbook AWSSupport-TroubleshootSSH

Le runbook d’automatisation AWSSupport-TroubleshootSSH installe l’outil Amazon EC2Rescue pour Linux sur l’instance. Cet outil détecte et tente de résoudre tout problème empêchant la connexion distante à un hôte Linux via SSH.

Pour exécuter le runbook AWSSupport-TroubleshootSSH :

1. Ouvrez la page AWSSupport-TroubleshootSSH.

2. Sélectionnez Exécuter cette automatisation (console).

Pour en savoir plus, consultez la page Je reçois des messages d’erreur lorsque j’essaie de me connecter à mon instance EC2 via SSH. Comment utiliser le flux de travail d’automatisation AWSSupport-TroubleshootSSH pour résoudre les problèmes de connexion SSH ?

Méthode 4 : utilisation d’un script de données utilisateur

Si aucune des méthodes décrites ne convient à votre environnement, utilisez un script de données utilisateur EC2. Le script de données utilisateur EC2 désactive le pare-feu au niveau du système d’exploitation et du TCP wrapper, puis redémarre le service sshd.

Important :

cette procédure nécessite l’arrêt et le démarrage de l’instance EC2. Si des données de l’instance sont stockées sur des volumes de stockage d’instance, celles-ci seront supprimées après l’arrêt de l’instance.
Si l’instance fait partie d’un groupe Amazon EC2 Auto Scaling, la résiliation de l’instance peut également entraîner l’arrêt des instances du groupe Auto Scaling.
Si l’instance est lancée par des services qui utilisent AWS Auto Scaling, la résiliation de l’instance peut également entraîner l’arrêt des instances du groupe Auto Scaling.
La résiliation d’une instance dépend des paramètres de protection intégrée de l’instance pour le groupe Auto Scaling. Si votre instance fait partie d’un groupe Auto Scaling, supprimez-la temporairement du groupe Auto Scaling avant de commencer les étapes de résolution.
L’arrêt et le démarrage d’une instance entraînent la modification de son adresse IP publique. Il est recommandé d’utiliser une adresse IP Elastic au lieu d’une adresse IP publique dans le cadre du routage du trafic externe vers l’instance.

Pour configurer les données utilisateur de l’instance, procédez comme suit :

1. Ouvrez la console Amazon EC2.

2. Choisissez Instances dans le volet de navigation, puis sélectionnez l’instance à laquelle vous souhaitez vous connecter.

3. Arrêtez l’instance.

4. Choisissez Actions, Paramètres de l’instance, Modifier les données utilisateur.

5. Copiez le script de données utilisateur suivant dans la boîte de dialogue Modifier les données utilisateur, puis choisissez Enregistrer.

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--//
Content-Type:
    text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash
iptables -P INPUT ACCEPT
iptables -F
systemctl restart sshd.service || service sshd restart
if [[ $( cat /etc/hosts.[ad]* | grep -vE '^#' | awk 'NF' | wc -l) -ne 0 ]];\
then sudo sed -i '1i sshd2 sshd : ALL: allow' /etc/hosts.allow; fi
--//

6. Connectez-vous à l’instance via SSH.

7. Le script de données utilisateur précédent est configuré pour s’exécuter à chaque redémarrage de l’instance. Une fois l’accès à l’instance rétabli, supprimez le script de données utilisateur.

Remarque : la commande précédente efface les règles iptables principales. Une fois l’accès à l’instance rétabli, vérifiez l’exactitude de la configuration du pare-feu (par exemple, UFW, firewalld et iptables).

Pour supprimer les données utilisateur, procédez comme suit :

1. Suivez les étapes 1 à 4 de la section Méthode 4 : utilisation d’un script de données utilisateur.

2. Supprimez le script de données utilisateur dans la boîte de dialogue Modifier les données utilisateur.