J'ai apporté des modifications au fichier sshd_config de mon instance EC2. Je ne peux plus accéder à mon instance en utilisant SSH. Comment 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 le fichier de clé et le nom d'utilisateur de 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

Résolution

Remarque : si vous utilisez une instance Nitro, les noms de périphériques 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'appareil sur les instances Linux.

Méthode 1 : utiliser EC2 Serial Console

Si vous avez activé la EC2 Serial Console pour Linux, vous pouvez l'utiliser pour résoudre les problèmes liés aux types d'instances Nitro pris en charge. La console série permet de résoudre les problèmes de démarrage, ainsi que de configuration réseau et SSH. EC2 Serial Console se connecte à votre instance sans qu'aucune connexion réseau ne soit nécessaire. Vous pouvez accéder à EC2 Serial Console à l'aide de la console Amazon EC2 ou de l'interface de ligne de commande AWS (AWS CLI).

Avant d'utiliser EC2 Serial Console, accordez-lui l'accès au niveau du compte. Créez ensuite des stratégies AWS Identity and Access Management (IAM) accordant l'accès à vos utilisateurs IAM. En outre, chaque instance qui utilise EC2 Serial Console doit inclure au moins un utilisateur avec mot de passe. Si votre instance n'est pas accessible et que vous n'avez pas configuré l'accès à EC2 Serial Console, suivez les instructions de la section suivante, Méthode 2 : utiliser une instance de secours. Pour plus d'informations sur la configuration d'EC2 Serial Console pour Linux, consultez Configurer l'accès à EC2 Serial Console.

Remarque : en cas d'erreurs lors de l'exécution des commandes depuis AWS CLI, assurez-vous d'utiliser la version la plus récente.

Méthode 2 : utiliser une instance de secours

Avertissement : avant d'arrêter et de démarrer votre instance, assurez-vous de bien comprendre les points suivants :

• Les données sont perdues lorsque vous arrêtez l'instance si votre instance est basée sur le stockage d'instances ou dispose de volumes de stockage d'instances contenant des données. Pour plus d'informations, consultez Déterminer le type d'appareil racine de votre instance.
• L'arrêt de l'instance peut entraîner sa résiliation si celle-ci fait partie d'un groupe Amazon EC2 Auto Scaling. Les instances lancées avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk peuvent faire partie d'un groupe Auto Scaling AWS. Dans ce scénario, la résiliation de l'instance dépend des paramètres de protection contre la diminution de la taille d'instance pour votre groupe Auto Scaling. Si votre instance fait partie d'un groupe Auto Scaling, supprimez-la temporairement du groupe avant d'exécuter les étapes de résolution.
• L'arrêt et le redémarrage de l'instance entraînent la modification de son adresse IP publique. Il est recommandé d'utiliser une adresse IP Elastic, et non une adresse IP publique, lors du routage du trafic externe vers votre instance. Si vous utilisez Route 53, vous devrez peut-être mettre à jour les enregistrements DNS Route 53 lorsque l'adresse IP publique change.

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 secours.

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'instances contenant des données, alors les données sont perdues lorsque vous arrêtez l'instance. Pour plus d'informations, consultez Déterminer le 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 secours.

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 point de montage (/rescue) pour le nouveau volume que vous avez attaché à l'instance de secours à l'étape 4 :

$ sudo mkdir /mnt/rescue

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

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

Pour monter des systèmes de fichiers ext3 et ext4, exécutez la commande suivante :

$ sudo mount /dev/xvdf1 /mnt/rescue

Remarque : la syntaxe de la commande de montage précédente peut varier. Pour plus d'informations, exécutez la commande man mount.

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/rescue

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/rescue/etc/ssh/sshd_config

Vous pouvez également copier le fichier sshd_config de l'instance de secours 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/resscue/etc/ssh/sshd_config

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

Remarque : suivez les étapes suivantes si vous avez utilisé la Méthode 2 : utiliser une instance de secours.

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

$ sudo umount /mnt/rescue/

2.    Détachez le volume secondaire de l'instance de secours, 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.

---

Informations connexes

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