Comment utiliser SSH pour accéder à mon instance EC2 après avoir modifié le fichier sshd_config de l'instance ?

Brève description

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

Pour confirmer que vous ne pouvez pas accéder à l'instance en raison d'une erreur de refus de connexion, accédez à l'instance via SSH avec la messagerie complète activée. Consultez l'exemple suivant :

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

Cet exemple établit une connexion avec le nom DNS et utilise myawskey.pem pour le fichier de clé privée, avec ec2-user comme nom d'utilisateur. Remplacez le fichier clé et le nom d'utilisateur par le fichier clé et le nom d'utilisateur de l'exemple.

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

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 basée sur Nitro, les noms des 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 du périphérique sur une instance Nitro est /dev/nvme. Pour plus d'informations, consultez la rubrique Nom des périphériques sur les instances Linux.

Méthode 1 : Utilisez l’EC2 serial console

Si vous avez activé l’ 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 vous aide à résoudre les problèmes de démarrage, de configuration réseau et de configuration SSH. La console série se connecte à votre instance sans avoir besoin d'une connexion réseau fonctionnelle. Utilisez la console Amazon EC2 ou l'interface de ligne de commande AWS (AWS CLI) pour accéder à la console série.

Avant d'utiliser la console série, accordez l'accès à la console au niveau du compte. Créez ensuite des politiques AWS Identity and Access Management (IAM) qui accordent l'accès à vos utilisateurs IAM. De plus, chaque instance qui utilise la console série doit inclure au moins un utilisateur basé sur un mot de passe. Si votre instance est inaccessible et que vous n'avez pas configuré l'accès à la console série, suivez les instructions de la rubrique Méthode 2 : utiliser une instance de secours. Pour en savoir plus sur la configuration de l’EC2 serial console pour Linux, consultez la rubrique Configurer l'accès à l’EC2 serial console.

**Remarque :**si des erreurs surviennent lors de l'exécution des commandes de l'AWS CLI, vérifiez que vous utilisez la version la plus récente de l'AWS CLI.

Méthode 2 : utiliser une instance de secours

Avertissement :

• si votre instance est sauvegardée par un stockage d'instances ou possède des volumes de stockage d'instance contenant des données, les données sont perdues lorsque vous arrêtez l'instance. Pour en savoir plus, consultez la rubrique Déterminer le type de périphérique racine de votre instance.
• Si votre instance fait partie d'un groupe Amazon EC2 Auto Scaling, l'arrêt de l'instance risque de mettre fin à l'instance. Les instances que vous lancez avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk peuvent faire partie d'un groupe AWS Auto Scaling. Dans ce scénario, la résiliation de l'instance dépend des paramètres de protection de mise à l'échelle de l'instance pour votre groupe Auto Scaling. Si votre instance fait partie d'un groupe Auto Scaling, supprimez-la temporairement du groupe Auto Scaling avant de commencer les étapes de résolution.
• L'arrêt et le démarrage de l'instance modifient l'adresse IP publique de votre instance. Si vous ne souhaitez pas que votre adresse IP publique EC2 change lorsque vous redémarrez ou mettez fin à votre instance, utilisez une adresse IP élastique. Si vous utilisez Amazon Route 53, vous devrez peut-être mettre à jour les enregistrements DNS de Route 53 lorsque l'adresse IP publique change.

1.    Lancez une nouvelle instance EC2 dans votre cloud privé virtuel (VPC). Utilisez la même Amazon Machine Image (AMI) dans la même zone de disponibilité que l'instance endommagée. La nouvelle instance devient votre instance de secours.

2.    Arrêtez l'instance défectueuse.

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

4.    Connectez le volume EBS en tant que périphérique secondaire (/dev/sdf) à l'instance de secours.

5.    Utilisez SSH pour vous connecter à votre instance de secours.

6.    Exécutez la commande commandelsblk 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 (/rescue) pour le nouveau volume que vous avez attaché à l'instance de secours à l'étape 4 :

$ sudo mkdir /mnt/rescue

8.    Montez le volume dans 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 en savoir plus, exécutez la commande man mount.

9.    Exécutez à nouveau la commande lsblk pour vérifier que le volume a monté 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

Corrigez ou copiez le fichier sshd_config

Vous pouvez examiner le fichier sshd_config de votre instance endommagée et, si nécessaire, annuler vos modifications. Utilisez la sortie de messagerie détaillée SSH pour vous indiquer l'emplacement de l'erreur dans le fichier :

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

Vous pouvez également exécuter la commande suivante pour copier le fichier sshd_config de l'instance de secours vers votre instance endommagée. Cette commande remplace le contenu du fichier sshd\config sur votre instance d'origine :

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

Rattachez le volume à l'instance d'origine et testez la connexion

Remarque :si vous avez utilisé la méthode 2 : Utilisez une instance de secours, puis effectuez les étapes suivantes.

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 via SSH pour vérifier que vous pouvez accéder à l'instance.

Informations connexes

Pourquoi ne puis-je pas me connecter à mon instance Linux Amazon EC2 via SSH ?