J'ai apporté des modifications au fichier sshd_config de mon instance EC2 et maintenant je ne peux pas accéder à mon instance en utilisant SSH. Comment puis-je résoudre ce problème?

Date de la dernière mise à jour : 18/11/2020

J'ai apporté des modifications au fichier sshd_config de mon instance Amazon Elastic Compute Cloud (Amazon EC2), et maintenant je ne peux pas accéder à mon instance en utilisant SSH. Comment puis-je résoudre ce problème ?

Brève description

La modification du fichier sshd_config d'une instance peut provoquer une erreur connexion refusée lors de la connexion via SSH.

Pour confirmer que vous ne pouvez pas accéder à l'instance en raison d'une erreur connexion refusée, accédez à l'instance via SSH avec une messagerie détaillée sur :

$ ssh -i "myawskey.pem" ec2-user@ec2-11-22-33-44.eu-west-1.compute.amazonaws.com -vvv

L'exemple précédent utilise myawskey.pem pour le fichier comportant la clé privée et ec2-user@ec2.11.22.33.44 comme nom d'utilisateur. Remplacez votre fichier de clé et votre nom d'utilisateur par ceux donnés dans l’exemple. Assurez-vous d'utiliser la région où se trouve votre instance.

L'exemple de sortie suivant montre le message d'erreur connexion refusée :

OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22.
ssh: connect to host ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22: Connection refused

Pour résoudre ce problème :

1.   Créez une instance de récupération et montez le volume racine de l'instance affectée sur l'instance de récupération.

2.    Corrigez ou copiez le fichier sshd_config.

3.    Attachez à nouveau le volume à l'instance d'origine et testez la connexion.

Résolution

Remarque : si vous utilisez une instance Nitro, les noms d’appareils diffèrent des exemples donnés dans les étapes suivantes. Par exemple, au lieu de /dev/xvda ou /dev/sda1, le nom d’appareil sur une instance Nitro est /dev/nvme. Pour plus d’informations, consultez Noms d'appareils pour les instances Linux.

Créer une instance de récupération et monter le volume racine de l'instance affectée sur l'instance de récupération

1.    Lancez une nouvelle instance EC2 dans votre Virtual Private Cloud (VPC). Utilisez la même Amazon Machine Image (AMI) dans la même zone de disponibilité que l'instance affectée. Cette nouvelle instance devient votre instance de récupération.

2.    Arrêtez l'instance affectée.

Remarque : si vous utilisez une instance basée sur le stockage ou si vous avez des volumes de stockage d'instance contenant des données, les données sont perdues lorsque vous arrêtez l'instance. Pour plus d'informations, consultez Détermination du type d’appareil racine de votre instance.

3.    Détachez le volume racine Amazon Elastic Block Store (Amazon EBS) (/dev/xvda ou /dev/sda1) de votre instance affectée.

4.    Attachez le volume EBS en tant qu’appareil secondaire (/dev/sdf) à l'instance de récupération.

5.    Connectez-vous à l'instance de secours en utilisant SSH.

6.    Exécutez la commande lsblk pour afficher les appareils :

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
 └─xvdf1 202:81   0   8G  0 part

7.    Créez un répertoire de points de montage (/recovery) pour le nouveau volume que vous avez attaché à l'instance de récupération à l'étape 4 :

$ sudo mkdir /mnt/recovery

8.    Montez le volume sur le répertoire que vous avez créé à l'étape 7 :

$ sudo mount -t xfs -o nouuid /dev/xvdf1 /mnt/recovery/

9.    Exécutez à nouveau la commande lsblk pour vérifier que le volume a été monté sur le répertoire :

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
└─xvdf1 202:81   0   8G  0 part /mnt/recovery

Corriger ou copier le fichier sshd_config

Vous pouvez rechercher le fichier sshd_config sur votre instance affectée et annuler vos modifications. Utilisez la sortie de messagerie détaillée SSH pour vous guider vers l'emplacement de l'erreur dans le fichier.

$ sudo vi /mnt/recovery/etc/ssh/sshd_config

Vous pouvez également copier le fichier sshd_config de l'instance de récupération vers votre instance affectée à l'aide de la commande suivante. Cette commande remplace le contenu du fichier sshd_config sur votre instance d'origine.

$ sudo cp /etc/ssh/sshd_config /mnt/recovery/etc/ssh/sshd_config

Attacher à nouveau le volume à l'instance d'origine et tester la connexion

1.    Exécutez la commande umount pour démonter le volume :

$ sudo umount /mnt/recovery/

2.    Détachez le volume secondaire de l'instance de récupération, puis attachez le volume à l'instance d'origine en tant que /dev/xvda (volume racine).

3.    Démarrez l'instance.

4.    Connectez-vous à l'instance à l'aide de SSH pour vérifier que vous pouvez atteindre l'instance.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?