Pourquoi ne puis-je pas me connecter à mon instance Amazon EC2 Linux une fois les vérifications d’état d’intégrité réussies ?

Résolution

Remarque : Il est recommandé de conserver des sauvegardes de vos instances et de vos données. Avant de résoudre les problèmes ou d'apporter des modifications, créez une AMI ou créez des instantanés de vos volumes EBS.

Erreur « Connection timeout »

Pour résoudre l’erreur « ssh: connect to host <hostname> port 22: ssh: connect to post », vérifiez les problèmes suivants :

Mauvaise configuration du groupe de sécurité, du routage ou de l’ACL réseau
Vérifiez si la règle entrante du groupe de sécurité autorise le port 22 depuis votre serveur source. Vérifiez que la règle du groupe de sécurité sortant autorise le trafic vers 0.0.0.0/0. Pour plus d'informations sur les règles du groupe de sécurité, consultez la section Règles de connexion aux instances à partir de votre ordinateur.

Pour vous connecter depuis un client sur site à une instance privée, vérifiez qu'il existe une connexion VPN entre votre réseau local et le cloud privé virtuel (VPC) Amazon. Vous pouvez également vous connecter à l'instance depuis un autre serveur de saut au sein du même VPC ou sous-réseau.

Si vous pouvez vous connecter, le problème est peut-être lié à votre client sur site et à la connexion VPN site à site AWS.

Si vous avez configuré une liste de contrôle d'accès réseau (ACL réseau) stricte,vérifiez que la règle d'entrée autorise le port 22. Vérifiez que la règle de sortie autorise tout le trafic vers 0.0.0.0/0.

Paramètres de pare-feu local
Recherchez un pare-feu au niveau du système d'exploitation tel que iptables ou firewalld. Pour résoudre les problèmes liés à une connexion bloquée, vérifiez la configuration de votre pare-feu.

Problèmes OOM liés à SSH
Vérifiez si votre instance présente un problème OOM. En cas d'erreur OOM, cela signifie que le système d'exploitation (OS) ne répond pas ou est gravement dégradé et les requêtes réseau arrivent à expiration. Pour résoudre les problèmes OOM liés à SSH, consultez les journaux système et l'utilisation des ressources.

Vérifier les journaux système :

Accédez aux journaux système via AWS Systems Manager ou EC2 Serial Console (si SSH n'est pas disponible).

Pour vérifier les messages OOM, exécutez la commande suivante :

dmesg | grep -i oom

Pour consulter le journal système Amazon Linux, RHEL ou CentOS, exécutez la commande suivante :

sudo less /var/log/messages

Pour consulter le journal système Ubuntu ou Debian, exécutez la commande suivante :

sudo less /var/log/syslog

Vous pouvez recevoir une sortie similaire à l'exemple suivant :

Aug 17 10:00:01 ip-172-31-1-1 kernel: [123456.789012] Out of memory: Kill process 1234 (myprocess) score 950 or sacrifice child
Aug 17 10:00:01 ip-172-31-1-1 kernel: [123456.789013] Killed process 1234 (myprocess) total-vm:500000kB, anon-rss:200000kB, file-rss:50000kB
Aug 17 10:00:01 ip-172-31-1-1 kernel: [123456.789014] oom_reaper: reaped process 1234 (myprocess), now anon-rss:0kB, file-rss:0kB
Aug 17 10:00:01 ip-172-31-1-1 kernel: [123456.789015] OOM killer disabled.

Surveiller l'utilisation des ressources :
Pour surveiller l'utilisation des ressources de votre système, choisissez l'une des commandes suivantes :

Pour vérifier l'utilisation de la mémoire, exécutez la commande suivante :

 free -m

Pour vérifier les processus, exécutez la commande suivante :

 top

Puis, notez les processus qui consomment la plupart des ressources système, telles que la mémoire ou le processeur.

Pour vérifier l'utilisation des échanges, exécutez la commande suivante :

 sudo swapon --show

Vérifiez l'historique d'utilisation des ressources à l'aide de la commande sar.
Si le package sysstat n'est pas installé, exécutez d'abord la commande suivante pour l'installer :

 sudo yum install sysstat

Pour consulter l'historique de l'utilisation de la mémoire, exécutez la commande suivante :

 sar -r

Pour consulter l'historique de l'utilisation du processeur, exécutez la commande suivante :

 sar -u

Pour identifier les processus qui consomment de la mémoire, exécutez la commande suivante :

ps -eo pmem,pid,user,args | sort -k 1 -r | head -10

Pour vérifier les processus qui consomment le plus de processeurs, exécutez la commande suivante :

ps -eo pid,user,ppid,cmd,%mem,%cpu --sort=-%cpu | head

Vérifiez si le volume racine utilisé est de 100 % :

df -Th

Si vous vous attendiez à une utilisation plus importante des ressources qui ne se confirme pas, mettez à niveau votre type d'instance. Pour plus d'informations, consultez la section Surveiller les performances à l'aide du System Activity Reporter (SAR) ou Configurer les outils de surveillance.

Si la console série n'est pas configurée pour l'instance, consultez la section Accès à EC2 Serial Console pour l'activer.

Si vous ne pouvez pas utiliser la console série, utilisez une instance de secours pour examiner les journaux système. Reportez-vous aux étapes 1 à 8 pour résoudre les problèmes au niveau du système d'exploitation, puis vérifiez /var/log/messages ou /varlog/syslog.

Erreur « Connection refused »

Si l’erreur « Connection refused » s'affiche, connectez-vous à l'instance via la console série pour résoudre le problème.

Erreur « Host key verification failed »

Si l'erreur « Host key verification failed » s'affiche, cela signifie que le client SSH a détecté une incompatibilité entre la clé d'hôte du serveur et la clé précédemment stockée. Cette situation se produit lorsque la clé d'hôte du serveur est modifiée en raison d'une réinstallation du serveur ou d'un problème de sécurité.

Supprimer l'ancienne clé d'hôte
Pour corriger l'erreur de vérification, supprimez la clé d'hôte obsolète ou incorrecte de votre fichier known_hosts.
Le fichier se trouve dans ~/.ssh/known_hosts sur les systèmes UNIX (Linux, macOS) ou C:\Users\YourUsername\.ssh\known_hosts sous Windows.

Pour supprimer l'ancienne entrée de clé d'hôte associée au nom d'hôte ou à l'adresse IP spécifié dans le fichier known_hosts, exécutez la commande suivante :

 ssh-keygen -R your hostname or IP address

Remarque : Remplacez YourUsername par votre nom d'utilisateur. Remplacez votre nom d'hôte ou adresse IP par l'adresse du serveur auquel vous souhaitez vous connecter.

Se reconnecter au serveur
Après avoir supprimé l'ancienne clé d'hôte, utilisez SSH pour vous reconnecter au serveur. Vérifiez la nouvelle empreinte digitale de la clé hôte. Acceptez la nouvelle clé d'hôte pour l'ajouter à votre fichier known_hosts.

Erreur « Permission Denied (publickey) »

Si l'erreur « Permission denied (publickey) » s'affiche, cela signifie que le client SSH ne peut pas utiliser les informations d'identification fournies pour s'authentifier auprès du serveur. Pour résoudre l'erreur, assurez-vous que la clé privée et le nom d'utilisateur sont corrects pour l'instance.

Automatisation du Gestionnaire de sessions pour vérifier les problèmes SSH courants

Si le Gestionnaire de sessions est configuré pour l'instance, exécutez le dossier d’exploitation d’automatisation AWSSupport-TroubleshootSSH. Le dossier d’exploitation installe l'outil Amazon EC2Rescue pour Linux. Le dossier d’exploitation utilise ensuite l'outil pour vérifier ou résoudre les problèmes courants qui empêchent une connexion à distance à la machine Linux via SSH.

Informations connexes

Comment puis-je résoudre un problème d'instance Linux EC2 qui a échoué à la vérification de l'état de l'instance en raison de problèmes liés au système d'exploitation ?

Pourquoi mon instance Linux EC2 est-elle injoignable et ses vérifications de statut échouent-elles?

Pourquoi ne puis-je pas utiliser le Gestionnaire de sessions pour me connecter à mon instance Amazon EC2 ?