Des erreurs « Connexion refusée » ou « Délai de connexion expiré » s'affichent lorsque je tente de me connecter à mon instance EC2 via SSH. Comment corriger ces erreurs ?

Lecture de 10 minute(s)
0

Des erreurs « Connexion refusée » ou « Délai de connexion expiré » s'affichent 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. L'erreur 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é). Les causes courantes de cette erreur sont les suivantes :

  • 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. Les causes courantes de cette erreur sont les suivantes :

  • L'hôte a atteint l'instance, mais aucun service n'écoutait sur le port SSH.
  • Un pare-feu a causé un blocage, or il a été configuré pour rejeter le package et non le supprimer.

Résolution

Erreur « Délai de connexion expiré »

Pour l'erreur « Délai de connexion expiré », vérifiez les points suivants :

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 »

Pour l'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 mode exécution et écoute sur le port 22.

Remarque : Les deux étapes de vérification exigent d'accéder à l'instance au niveau du système d'exploitation.

Si l'instance réussit les deux surveillances de l'état, utilisez l'une des quatre méthodes répertoriées ci-dessous avec votre configuration

  • Méthode 1 : Utiliser l'EC2 Serial Console pour Linux.
  • Méthode 2 : Utiliser le Gestionnaire de session d'AWS Systems Manager.
  • Méthode 3 : Exécuter le runbook d'automatisation AWSSupport-TroubleshootSSH.
  • Méthode 4 : Utiliser un script de données utilisateur.

Méthode 1 : Utiliser l'EC2 Serial Console pour Linux

Si elle 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 à l'aide de la console Amazon EC2 ou de l'interface de la ligne de commande AWS (AWS CLI).

Avant d’utiliser la console de série, autorisez-lui l'accès au niveau du compte pour pouvoir l'utiliser. 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, reportez-vous à 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 section Gestion des autorisations du compte sudo ssm-user sous Linux et macOS.

Après la configuration, connectez-vous à l'instance EC2 via la EC2 Serial console via un utilisateur Linux configuré par mot de passe.

Ensuite, exécutez 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 l'emballage TCP. Les commandes vérifient également que le service sshd est en cours d'exécution et écoute sur le port 22.

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

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

Étant donné qu'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 ACCEPTER, pour que le fait de vider la règle iptables n'affecte pas la connexion réseau de l'instance. 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 : Dès que vous avez de nouveau accès à votre instance, vérifiez la configuration de votre pare-feu (UFW, firewalld, iptables).

2.Vérifiez que le SSH est en cours d'exécution et que le port TCP SSH (22) est en état d'é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.Assurez-vous que l'emballage TCP 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.Ensuite, connectez-vous à l'instance via SSH.

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

Méthode 2 : Utilisez le 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 l'emballage TCP et que le service sshd est en mode exécution et écoute sur le port 22 :

1.Ouvrez AWS Systems Manager.

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

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

4.Fermez la session du gestionnaire de session si elle n'est plus requise.

Méthode 3 : Exécutez le runbook AWSSupport-TroubleshootSSH

Le runbook d'automatisation AWSSupport-TroubleshootSSH installe l'outil Amazon EC2Rescue pour Linux sur l'instance. Cet outil vérifie et tente de résoudre les problèmes qui empêchent 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 : Utiliser 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 de l'emballage TCP, 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 sont supprimées après l'arrêt de l'instance.
  • Si l'instance fait partie d'un groupe Amazon EC2 Auto Scaling, la fermeture de l'instance peut également arrêter les instances du groupe Auto Scaling.
  • Si l'instance est lancée par des services qui utilisent AWS Auto Scaling, la fermeture de l'instance peut également arrêter les instances du groupe Auto Scaling.
  • La fermeture 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 de l'instance modifient l'adresse IP publique de l'instance. Il est recommandé d'utiliser une adresse IP Elastic au lieu d'une adresse IP publique lors 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 la précision de la configuration du pare-feu (par exemple, UFW, firewalld, iptables).

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

1.Effectuez les étapes 1 à 4 de la section Méthode 4 : Utilisez 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.

Informations connexes

Erreur lors de la connexion à votre instance : Délai de connexion expiré

Comment corriger les erreurs d'expiration du délai de connexion d'instance Amazon EC2 depuis Internet ?

Comment résoudre les problèmes de connexion à mon instance Linux Amazon EC2 à l'aide de SSH ?

Pourquoi mon instance Linux EC2 est-elle inaccessible et échoue-t-elle à l'un de ses contrôles de l'état ou aux deux ?

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an