Guide étape par étape pour résoudre les problèmes - SSH ne peut pas se connecter à EC2

Certains utilisateurs nouveaux sur AWS peuvent rencontrer des problèmes lors de la connexion à une instance EC2 Linux via SSH. Ne vous inquiétez pas, cet article vous aidera à diagnostiquer les raisons courantes !

Raisons pour lesquelles SSH ne peut pas se connecter à EC2

Les raisons courantes pour lesquelles on ne peut pas se connecter à EC2 via SSH se répartissent généralement en deux catégories : timeout de connexion et erreurs de permission.

Dépassement de délai de connexion : Les messages d'erreur contiennent généralement des mots-clés comme "connect", par exemple "Connection Timed Out". Cela est généralement dû à des paramètres réseau incorrects, nécessitant des vérifications sur l'IP, le groupe de sécurité, la liste de contrôle d'accès, la table de routage du sous-réseau et l'environnement réseau de l'utilisateur.

Erreurs de permission : Les messages d'erreur contiennent généralement des mots-clés comme "permission" ou "clé", par exemple "Permission refusée" ou des avertissements concernant des clés non enregistrées ou inexistantes. Cela est généralement dû à une utilisation incorrecte des clés ou des noms d'utilisateur.

Dépassement du délai de connexion

Description du problème

Vous avez créé et démarré une instance Amazon EC2 Linux mais vous ne parvenez pas à vous connecter à l'instance en utilisant SSH ou des outils comme PuTTY. Lors de la connexion à l'instance, vous rencontrez une erreur de délai d'expiration de connexion, comme "Erreur réseau : Connexion expirée" ou "Erreur lors de la connexion à [instance], raison : -> Connexion expirée : connect". Ce problème est généralement causé par des paramètres incorrects des composants réseau tels que les groupes de sécurité, les tables de routage et les listes de contrôle d'accès réseau. Veuillez suivre les étapes de dépannage ci-dessous pour vérifier l'environnement réseau.

Dépannage

1. Vérifier les groupes de sécurité

Dans le groupe de sécurité de l'instance EC2, assurez-vous que le trafic entrant pour le protocole SSH (port par défaut 22) est autorisé.

Si vous êtes dans un LAN de bureau, votre adresse IP peut ne pas être fixe et peut changer chaque fois que vous vous connectez. Dans ce cas, il est recommandé de définir la source sur la plage d'adresses IP de votre réseau de bureau plutôt que sur une seule adresse IP.

Note : Par défaut, l'instance ne peut pas non plus être pingée. Si vous souhaitez pinguer cette instance, vous devez ajouter une règle permettant le protocole ICMP de la même manière.

• Ouvrez la console Amazon EC2.

• Dans le volet de navigation, sélectionnez Instances.

• Trouvez l'instance EC2 à laquelle vous souhaitez vous connecter via SSH.

• Dans l'onglet Description en bas de l'écran, sélectionnez le groupe de sécurité de l'instance EC2 à laquelle vous souhaitez vous connecter.

• Dans l'onglet Inbound du volet en bas de l'écran, assurez-vous qu'une règle est définie pour autoriser l'accès SSH depuis votre adresse IP publique actuelle. Si l'adresse IP utilisée par votre appareil n'est pas dans la liste, sélectionnez Edit, puis sélectionnez Add rule.

• Pour Source, sélectionnez votre adresse IP actuelle. « 0.0.0.0/0 » signifie qu'il est ouvert à toutes les IPs.

• Sélectionnez Save.

2. Vérifier si le sous-réseau est un sous-réseau public

Un sous-réseau public est un sous-réseau qui permet l'accès à Internet. Si votre EC2 se trouve dans un sous-réseau privé, l'Internet externe ne peut pas se connecter activement et SSH échouera.

• Ouvrez la console Amazon VPC.

• Dans le volet de navigation, sélectionnez Route Tables, puis sélectionnez votre table de routage VPC dans la liste.

• Dans l'onglet Routes , vérifiez qu'il existe une route par défaut pointant vers la passerelle Internet.

• Si ce n'est pas le cas, sélectionnez Internet Gateways dans le volet de navigation et copiez l'ID de votre passerelle Internet. Si aucune passerelle Internet n'existe, créez-en une et attachez-la à votre VPC. Assurez-vous de copier l'ID de la nouvelle passerelle Internet.

• Revenir à Route Tables, puis sélectionner l'onglet Routes .

• Modifier et créer une route qui dirige "0.0.0.0/0" vers l'ID de votre passerelle Internet.

• Enregistrer la table de routage.

3. Vérifiez la liste de contrôle d'accès au réseau (ACL) du sous-réseau

La ACL est un pare-feu au niveau du sous-réseau. La liste de contrôle d'accès réseau par défaut autorise tout le trafic entrant et sortant. Si vous n'avez apporté aucun changement à la ACL, passez cette étape.

• Ouvrez la console Amazon VPC.

• Dans le volet de navigation, sélectionnez Subnets, puis sélectionnez votre sous-réseau.

• Dans l'onglet Description, trouvez Network ACL, puis sélectionnez son ID (acl-xxxxxxxx).

• Sélectionnez le réseau ACL. Pour Inbound Rules, vérifiez si les règles autorisent le trafic depuis votre ordinateur. Si ce n'est pas le cas, supprimez ou modifiez les règles qui bloquent le trafic depuis votre ordinateur. Pour Outbound Rules, vérifiez si les règles autorisent le trafic vers votre ordinateur. Si ce n'est pas le cas, supprimez ou modifiez les règles qui bloquent le trafic vers votre ordinateur.

4. Vérifier si l'adresse IP a changé

• Dans le volet de navigation, sélectionnez Instances.

• Trouvez l'instance EC2 à laquelle vous souhaitez vous connecter via SSH.

• Dans l'onglet Description en bas de l'écran, vérifiez si l'Public IP correspond à l'adresse IP que vous utilisez. Si l'adresse IP a changé, utilisez la nouvelle adresse IP.

5. Vérifiez l'AMI

Veuillez vérifier si vous utilisez actuellement une AMI dans Quick Start ou dans Marketplace. Sauf si vous êtes certain de la sécurité d'une AMI particulière, essayez de ne pas utiliser les images communautaires. Les images communautaires sont publiées par des particuliers et AWS ne peut pas les surveiller. Certaines images communautaires peuvent avoir des contrôles de gestion de sécurité spéciaux, empêchant l'accès SSH direct. Dans ce cas, arrêtez le serveur actuel et démarrez un nouveau avec une image officielle ou Marketplace.

6. Vérifiez la charge de l'instance

Le serveur pourrait être surchargé, provoquant un dysfonctionnement du service sshd et l'incapacité d'accepter de nouvelles requêtes SSH. Cela peut être confirmé en observant les métriques CloudWatch. La méthode la plus simple à ce stade est d'essayer de redémarrer l'instance pour voir si le problème est résolu. Si ce n'est pas le cas, utilisez l'outil Session Manager de System Manager pour ouvrir une session et exécuter des commandes pour tuer les ressources inutiles.

7. Autres raisons

Si toutes les étapes ci-dessus ont été vérifiées et qu'il n'y a pas de problème, examinez les raisons suivantes :

• Le port 22 est bloqué : Si vous vous trouvez dans un bureau ou une zone Wi-Fi publique d'un hôtel, essayez un autre réseau pour vérifier si le réseau public a bloqué le port 22.

• Vérifiez si le pare-feu de votre ordinateur bloque le port 22.

Problèmes de permission

Description du problème

Vous avez créé et démarré une instance EC2, mais vous ne pouvez pas vous connecter à l'instance via SSH, avec des messages d'erreur tels que "Host key not found in [directory]", "Permission denied (publickey)" ou "Authentication failed, permission denied". Ce problème est généralement causé par des clés ou des noms d'utilisateur incorrects. Voici des méthodes de dépannage spécifiques.

Dépannage

1. Vérifiez si la paire de clés est correcte

Chaque instance EC2 a une clé lors de son lancement. Cette clé est le seul moyen de se connecter à l'EC2 pour la première fois et ne peut être téléchargée que avant le lancement de l'instance. Tout d'abord, sélectionnez votre instance et vérifiez le nom de la paire de clés sur la page Description pour vous assurer d'utiliser la bonne clé.

Si cet élément est vide, vous ne pouvez pas vous connecter à l'instance via SSH. Veuillez arrêter l'instance, démarrer une nouvelle instance et n'oubliez pas de télécharger la clé.

2. Nom d'utilisateur incorrect

Si vous utilisez une image officielle, les noms d'utilisateur corrects sont les suivants :

Si il s'agit d'une version communautaire de l'AMI, le nom d'utilisateur ne peut pas être garanti. Veuillez contacter le créateur de l'AMI ou passer à un AMI officiel.

3. Vérifiez le format de votre clé

Généralement, la clé nécessaire pour SSH est au format « pem ». Si vous utilisez un ordinateur sous Windows et que vous vous connectez avec PuTTY, vous devez convertir de « pem » à « ppk ».

4. Vérifier les autorisations de la clé

Si vous rencontrez l'erreur "mauvaises permissions : ignorer la clé : my_private_key.pem Permission denied (publickey)".

Cette situation se produit car les permissions de votre fichier de clé privée sont trop élevées, permettant à tout utilisateur de lire et d'écrire. Pour protéger votre fichier de clé privée, SSH ignore votre clé. La solution consiste à modifier les permissions de la clé à l'aide de la commande :

chmod 400 my_private_key.pem

5. Erreurs liées à known_host

Cette situation est généralement observée lors du changement d'EIP, par exemple, un EIP était monté sur la machine A avec la clé A. Lorsque l'EIP est basculé sur la machine B avec la clé B, l'enregistrement known_host pour cette IP ne correspond pas.

La solution consiste à ouvrir le fichier known_hosts (Linux/mac address : ~/.ssh/known_hosts) et à supprimer l'enregistrement correspondant pour cette IP.

Choisissez une solution de sauvegarde EC2 sécurisée

Vinchin Backup & Recovery soutient les sauvegardes AWS EC2, permettant aux utilisateurs d'ajouter des instances avec leur ID de clé d'accès AWS et de configurer des sauvegardes complètes, incrémentielles ou différentielles. Elle offre des options de récupération flexibles, y compris des instances entières, des volumes individuels et des fichiers spécifiques, avec une récupération directe sur d'autres plates-formes de virtualisation. En s'intégrant avec Amazon S3 pour une archivage sécurisé, elle permet également les migrations V2V vers des plates-formes comme VMware, Hyper-V et Proxmox. L'interface conviviale simplifie la gestion et la configuration des sauvegardes.

Pour sauvegarder une instance EC2 avec Vinchin Backup & Recovery, suivez ces étapes :

1. Sélectionnez l'instance EC2 à sauvegarder.

2. Sélectionnez la destination de la sauvegarde.

3. Sélectionnez les stratégies de sauvegarde.

4. Examiner et soumettre le travail.

Démarrez votre essai gratuit de 60 jours de Vinchin Backup & Recovery pour découvrir ses solutions de sauvegarde sécurisées et économiques en ressources. Ou, contactez-nous pour un plan personnalisé adapté à vos besoins informatiques.

Conclusion

En abordant les problèmes potentiels avec les étapes ci-dessus, vous pouvez résoudre rapidement le problème et retrouver l'accès à votre instance. N'oubliez pas de toujours adopter de bonnes pratiques de sécurité, comme la restriction de l'accès aux adresses IP de confiance et la vérification régulière de votre groupe de sécurité et de vos paramètres de réseau.