Comment résoudre les erreurs « Connexion refusée » ou « Délai de connexion expiré » lorsque j'utilise SSH pour me connecter à mon instance EC2 ?
Le message d’erreur « Connexion refusée » ou « Délai de connexion expiré » s’affiche lorsque j’utilise SSH pour me connecter à mon instance Amazon Elastic Compute Cloud (Amazon EC2).
Brève description
Si votre connexion expire, le message d'erreur suivant s'affiche à partir du client SSH :
« ssh: connect to host ec2-X-X-X-X.compute-1.amazonaws.com port 22: Connection timed out » (ssh : connexion à l’hôte ec2-X-X-X-X.compute-1.amazonaws.com sur le 22 : délai de connexion expiré)
L'erreur La connexion a expiré se produit lorsque le serveur ne répond pas au client et que le programme client abandonne (expiration du délai).
Si un hôte refuse votre connexion à distance, le message d'erreur suivant s'affiche :
« ssh: connect to host ec2-X-X-X-X.compute-1.amazonaws.com port 22: Connection refused » (ssh : connexion à l’hôte ec2-X-X-X-X.compute-1.amazonaws.com sur le 22 : connexion refusée)
Résolution
Erreur « Délai de connexion expiré »
Si le message d'erreur Délai de connexion expiré s'affiche, vérifiez les configurations suivantes :
- L’adresse IP ou le nom d’hôte de l’instance est correct.
- L'instance réussit ses surveillances d’état.
- Vérifiez que le groupe de sécurité de l’instance autorise le trafic entrant sur le port TCP 22.
- Les listes de contrôle d'accès au réseau (ACL réseau) du sous-réseau d'instance autorisent le trafic entrant sur le port TCP 22 et le trafic sortant sur les ports éphémères.
- La table de routage du sous-réseau d'instance assure la connectivité entre l'instance et le client SSH.
- Aucun pare-feu ne bloque la connexion entre le client SSH et l'instance.
- Les encapsuleurs TCP de l'instance ne bloquent pas SSH. Pour en savoir plus, consultez la page 2.6.2. Fichiers de configuration des encapsuleurs TCP sur le site Web de Red Hat.
Remarque : Pour vérifier l'existence de problèmes liés au pare-feu ou aux encapsuleurs TCP, vous devez disposer d'un accès au système d'exploitation (OS) à l'instance.
Erreur « Connexion refusée »
Si le message d’erreur Connexion refusée s'affiche, vérifiez les configurations suivantes :
- Aucun pare-feu ne bloque la connexion SSH sur l'instance.
- Le démon SSH (sshd) est en cours d’exécution et à l’écoute sur le port 22.
Remarque : Pour vérifier les configurations précédentes, vous devez disposer d'un accès à l'instance au niveau du système d'exploitation.
Résoudre les problèmes liés aux instances qui réussissent les deux surveillances d’état
Pour résoudre les problèmes liés aux instances qui réussissent leurs surveillances d’état, appliquez l'une des méthodes de dépannage suivantes.
Exécuter le dossier d’exploitation AWSSupport-TroubleshootSSH
Il est recommandé d'exécuter le dossier d'exploitation d'automatisation AWSSupport-TroubleshootSSH. Le dossier d'exploitation installe l'outil Amazon EC2Rescue sur votre instance afin d'identifier et de résoudre les problèmes qui bloquent une connexion SSH distante à un hôte Linux.
Utiliser l’EC2 Serial Console pour Linux
Utilisez l’EC2 Serial Console pour Linux afin de résoudre les problèmes au niveau du système d'exploitation tels que les problèmes de démarrage, les problèmes de configuration réseau et les problèmes de configuration SSH sur les types d'instances pris en charge.
Prérequis :
- Accordez l'accès à la console au niveau du compte AWS.
- Créez des politiques de gestion des identités et des accès AWS (AWS IAM) qui accordent l'accès à la console pour vos utilisateurs IAM.
Remarque : Chaque instance qui utilise l’EC2 Serial Console doit compter au moins un utilisateur Linux basé sur un mot de passe avec un accès sudo.
Pour plus d’informations, consultez la section 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 vérifier que votre configuration ne bloque pas l'accès SSH, procédez comme suit :
-
Utilisez l’EC2 Serial Console pour vous connecter à l'instance EC2 en tant qu'utilisateur Linux configuré par mot de passe.
-
Si vous avez configuré des règles iptables, exécutez la commande suivante pour ajouter une règle dans iptables qui accepte toutes les connexions SSH sur le port 22 :
sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT -
Si vous utilisez un pare-feu basé sur le système d'exploitation, désactivez-le. Il est recommandé d'utiliser des groupes de sécurité plutôt qu’un pare-feu. Pour désactiver votre pare-feu basé sur le système d'exploitation, exécutez les commandes suivantes en fonction de votre système d'exploitation.
Important : Les commandes suivantes effacent toutes les règles iptables principales et suppriment les règles existantes. Les commandes ajoutent également une règle qui autorise les connexions SSH entrantes et modifient la politique par défaut de la chaîne principale en ACCEPTER. Cette configuration garantit que vous n'affectez pas la connectivité réseau de l'instance lorsque vous effacez la règle iptables.
Distributions utilisant UFW telles que Ubuntu et Debian :sudo iptables -F$ sudo iptables -P INPUT ACCEPT sudo ufw disableDistributions utilisant Firewalld, telles que Red Hat Enterprise Linux (RHEL) et CentOS :
sudo iptables -F $ sudo iptables -P INPUT ACCEPT sudo systemctl disable firewalldRemarque : Une fois l'accès à nouveau rétabli à votre instance, vérifiez la configuration de votre pare-feu.
-
Pour vérifier que SSH est en cours d'exécution et que le port TCP SSH 22 est à l’état d'écoute, exécutez la commande suivante :
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, remplacez ss par la commande netstat héritée. Veillez à utiliser la même syntaxe que la commande précédente.
-
Pour vous assurer que l’encapsuleur TCP ne bloque pas une connexion SSH, exécutez la commande suivante :
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
Utiliser Systems Manager
Prérequis : Pour utiliser Session Manager, une fonctionnalité d'AWS Systems Manager, votre instance doit être un nœud géré. Le statut ping d'AWS Systems Manager Agent (SSM Agent) de l'instance doit être En ligne et le rôle IAM associé doit disposer des autorisations AmazonSSMManagedInstanceCore. Assurez-vous de respecter tous les prérequis de Session Manager.
Utilisez Session Manager pour démarrer une session afin d'accéder à l'instance.
Utiliser un script de données utilisateur
Si vous ne pouvez pas utiliser les méthodes de dépannage précédentes, utilisez un script de données utilisateur pour désactiver le pare-feu au niveau du système d'exploitation et l’encapsuleur TCP. Puiis, redémarrez le service sshd.
Important : Avant d'arrêter et de démarrer votre instance, effectuez les actions suivantes :
- Créez une sauvegarde de votre volume Amazon Elastic Block Store (Amazon EBS).
Remarque : Si votre instance est sauvegardée par un stockage d'instances ou si ses volumes de stockage d'instances contiennent des données, Amazon EC2 supprime les données lorsque vous arrêtez l'instance. - Supprimez temporairement l'instance de son groupe Amazon EC2 Auto Scaling lorsque vous avez terminé les étapes de résolution.
Remarque : Si vous arrêtez une instance qui se trouve dans un groupe EC2 Auto Scaling, vous pouvez résilier l'instance en fonction de vos paramètres de protection de la mise à l'échelle horizontale descendante Les instances que vous lancez avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk peuvent faire partie d'un groupe Auto Scaling. - Définissez le comportement d'arrêt de l'instance** sur **Arrêter pour vous assurer que les instances ne se résilient pas lorsque vous les arrêtez.
Remarque : Lorsque vous arrêtez et démarrez une instance, son adresse IP publique change. Une bonne pratique consiste à utiliser une adresse IP Elastic pour acheminer le trafic externe vers votre instance au lieu d'une adresse IP publique.
Pour configurer les données utilisateur de l'instance, procédez comme suit :
- Ouvrez la console Amazon EC2.
- Dans le volet de navigation, sélectionnez Instances, puis votre instance.
- Arrêtez l’instance.
- Sélectionnez Actions, puis Paramètres de l’instance.
- Choisissez Modifier les données utilisateur, puis entrez le script de données utilisateur suivant :
Remarque : Le script de données utilisateur précédent est configuré pour s’exécuter à chaque redémarrage de l’instance. Cette méthode supprime toutes les règles iptables principales.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 --// - Sélectionnez Enregistrer.
- Utilisez le protocole SSH pour vous connecter à l'instance.
- Une fois l'accès à l'instance rétabli, supprimez le script de données utilisateur, puis vérifiez que la configuration de votre pare-feu est correcte.
Informations connexes
Erreur de connexion à votre instance : Délai de connexion expiré
Comment puis-je résoudre les problèmes de connexion à mon instance Linux Amazon EC2 via SSH ?
Pourquoi mon instance Linux EC2 est-elle injoignable et ses vérifications de statut échouent-elles?
- Langue
- Français
Vidéos associées


Contenus pertinents
- demandé il y a 9 mois
- demandé il y a un an
- demandé il y a un an
- demandé il y a 2 ans
AWS OFFICIELA mis à jour il y a 6 mois