Pourquoi le message d’erreur « Le serveur a refusé notre clé » s’affiche-t-il lorsque j’essaie de me connecter à mon instance EC2 via SSH ?

Brève description

Un serveur SSH (sshd) refuse une clé SSH privée pour plusieurs raisons. Voici quelques raisons courantes pour lesquelles vous pouvez obtenir cette erreur :

• Vous utilisez un nom d’utilisateur incorrect pour votre AMI lorsque vous vous connectez à votre instance EC2. Les noms d’utilisateur habituels sont ec2-user, ubuntu, centos, root ou admin.
• L’utilisateur qui tentait d’accéder à l’instance a été supprimé du serveur ou le compte a été verrouillé.
• Il y a des problèmes d’autorisations sur l'instance ou il vous manque un répertoire.
• Vous utilisez le fichier de clé privée incorrect lorsque vous vous connectez à votre instance EC2. Pour plus d’informations, consultez la section Vérifier que la clé privée est correcte dans Pourquoi est-ce que je reçois des erreurs « imported-openssh-key » ou « Erreur fatale de Putty » lorsque je me connecte à mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2) ?
• Les paramètres du serveur SSH dans /etc/ssh/sshd_config ont été modifiés. Pour plus d’informations, consultez Comment puis-je utiliser SSH pour accéder à mon instance EC2 après avoir modifié le fichier sshd_config de l’instance ?
• Le système d’exploitation n’a pas pu monter les répertoires personnels (/etc/fstab). Pour plus d’informations, consultez la section Erreurs liées à l’échec de la dépendance dans Pourquoi mon instance Linux EC2 ne démarre-t-elle pas et passe-t-elle en mode d’urgence ?

Résolution

Vous utilisez un nom d’utilisateur incorrect pour votre AMI lorsque vous vous connectez à votre instance EC2

Pour obtenir la liste des noms d’utilisateur valides, consultez Erreur : le serveur a refusé notre clé ou aucune méthode d’authentification prise en charge n’est disponible.

L’utilisateur qui essayait d’accéder à l’instance a été supprimé du serveur ou le compte a été verrouillé

Si l’utilisateur qui tentait d’accéder à l’instance a été supprimé du serveur, ajoutez-le en tant que nouvel utilisateur. Pour plus d’informations, consultez la section Comment ajouter de nouveaux comptes utilisateurs avec un accès SSH à mon instance Linux Amazon EC2 ?

Il y a des problèmes d’autorisations sur l’instance ou il vous manque un répertoire

Il existe quatre méthodes pour vérifier les autorisations et les répertoires sur l’instance :

Méthode 1 : Utiliser la EC2 Serial Console

Si vous avez activé la EC2 Serial Console pour Linux, vous pouvez utiliser la console série 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. Elle se connecte à votre instance sans nécessiter de connexion réseau fonctionnelle. Vous pouvez accéder à la console série à l’aide de la console Amazon EC2 ou de l’interface de la ligne de commande AWS (AWS CLI).

Avant d’utiliser la console série, vous devez autoriser l’accès à celle-ci au niveau du compte. Vous devez ensuite créer des politiques AWS Identity and Access Management (IAM) accordant l’accès à vos utilisateurs IAM. De plus, chaque instance utilisant la console série doit inclure au moins un utilisateur utilisant 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 méthode 2, 3 ou 4. Pour plus d’informations sur la configuration de la EC2 Serial Console pour Linux, consultez la section Configurer l’accès à la EC2 Serial Console.

Méthode 2 : Utiliser le gestionnaire de session d’AWS Systems Manager pour vous connecter à l’instance et vérifier les autorisations

Remarque : L’installation de l’agent SSM est requise pour utiliser cette méthode. Pour plus d’informations sur le gestionnaire de session et une liste complète des prérequis, consultez la section Configuration du gestionnaire de session.

1.    Ouvrez la console AWS Systems Manager.

2.    Démarrez une session.

3.    Utilisez la commande stat pour vous assurer que les autorisations des fichiers situés dans le répertoire personnel sont correctes. Voici la liste des autorisations correctes :

• Le répertoire personnel de Linux, /home, par exemple, doit être (0755/drwxr-xr-x).
• Le répertoire personnel de l’utilisateur, /home/ec2-user/, par exemple, doit être (0700/drwx------).
• L’autorisation du répertoire /home/ec2-user/.ssh, par exemple, doit être (0700/drwx------).
• l’autorisation du fichier « authorized_keys », /home/ec2-user/.ssh/authorized_keys, par exemple, doit être (0600/-rw-------).

Voici un exemple de la commande stat et de la sortie qui en résulte. Dans cet exemple, ec2-user est le nom d’utilisateur. Modifiez le nom d’utilisateur en fonction de votre AMI spécifique :

$ stat /home/ec2-user/
  File: '/home/ec2-user/'
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 10301h/66305d	Inode: 18322       Links: 3
Access: (0700/drwx------)  Uid: (  500/ec2-user)   Gid: (  500/ec2-user)

4.    Si les autorisations ne correspondent pas aux valeurs précédentes, exécutez les commandes suivantes :

$ sudo chown root:root /home
$ sudo chmod 755 /home
$ sudo chown ec2-user:ec2-user /home/ec2-user -R
$ sudo chmod 700 /home/ec2-user /home/ec2-user/.ssh
$ sudo chmod 600 /home/ec2-user/.ssh/authorized_keys

5.    Mettez fin à la session.

6.    Connectez-vous via SSH à votre instance.

Méthode 3 : Corriger automatiquement les problèmes à l’origine de l’erreur en exécutant le document AWSSupport-TroubleshootSSH

Le document d’automatisation AWSSupport-TroubleshootSSH installe l’outil Amazon EC2Rescue sur l’instance, puis vérifie et corrige certains problèmes à l’origine d’erreurs de connexion à distance lors de la connexion à une machine Linux via SSH. Pour plus d’informations, consultez la section Je reçois des erreurs lorsque j’essaie de me connecter à mon instance EC2 via SSH. Comment puis-je utiliser le flux de travail d’automatisation AWSSupport-TroubleshootSSH pour résoudre les problèmes de connexion SSH ?

Méthode 4 : Utiliser les données utilisateur pour corriger les autorisations sur l’instance

Important :

• Cette procédure de restauration nécessite que vous arrêtiez puis redémarriez votre instance. Dans ce cas, les données des volumes de stockage d’instance se perdent. Pour plus d’informations, consultez la section Déterminer le type de périphérique racine de votre instance.
• Si votre instance fait partie d’un groupe Amazon EC2 Auto Scaling, elle peut être mise hors service lorsqu’elle est arrêtée. Cela peut également se produire sur des instances lancées par des services qui utilisent AWS Auto Scaling, tels qu’Amazon EMR, AWS CloudFormation, AWS Elastic Beanstalk, etc. Dans ce scénario, la mise hors service d’une instance dépend des paramètres de protection évolutive de l’instance de 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 redémarrage de l’instance modifient son adresse IP publique. Il est recommandé d’utiliser une adresse IP Elastic au lieu d’une adresse IP publique lors du routage du trafic externe vers votre instance.
• Vous ne pouvez pas modifier la clé SSH à l’aide des données utilisateur si le périphérique racine de votre instance est un volume de stockage d’instance. Pour plus d’informations, consultez la section Déterminer le type de périphérique racine de votre instance.
• La mise à jour des données utilisateur de votre instance s’applique à toutes les distributions qui prennent en charge les directives cloud-init. Cloud-init doit être installé et configuré pour que ces instructions soient efficaces. Pour plus d’informations sur le module SSH de cloud-init, consultez la section SSH - Configurer SSH et les clés SSH dans la documentation de Cloud-init.

1.    Ouvrez la console Amazon EC2, puis sélectionnez votre instance.

2.    Choisissez État de l’instance, puis sélectionnez Arrêter l’instance.

**Remarque :**Si Arrêt n’est pas disponible, soit l’instance est déjà arrêtée, soit son périphérique racine est un volume de stockage d’instance.

3.    Choisissez Actions, choisissez Paramètres de l’instance, puis sélectionnez Modifier les données utilisateur.

4.    Copiez le script suivant dans le champ Données utilisateur, puis sélectionnez Enregistrer. Veillez à copier l’intégralité du script et à ne pas ajouter d’espaces supplémentaires.

Remarque : Le script suivant utilise le nom d’utilisateur ec2-user. Remplacez ec2-user par le nom d’utilisateur de votre AMI.

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash
chown root:root /home
chmod 755 /home
chown ec2-user:ec2-user /home/ec2-user -R
chmod 700 /home/ec2-user /home/ec2-user/.ssh
chmod 600 /home/ec2-user/.ssh/authorized_keys
--//

5.    Démarrez l’instance, puis entrez dans l’instance via SSH.

Remarque : Par défaut, le script de données utilisateur s’exécute une fois par instance. Cette procédure modifie le comportement par défaut pour ajouter la clé publique à chaque redémarrage, arrêt ou démarrage de l’instance. Pour rétablir le comportement par défaut, supprimez les données utilisateur personnalisées. La meilleure pratique consiste à prendre en compte les implications en matière de sécurité liées à l’autorisation des données utilisateur à s’exécuter après le premier démarrage d’une instance. Vous pouvez modifier les données utilisateur d’une instance à l’aide de la méthode d’API ModifyInstanceAttribute. Pour restreindre l’accès à cette méthode, utilisez les politiques IAM.

Informations connexes

Connexion à votre instance Linux depuis Windows à l’aide de PuTTY

Paires de clés Amazon EC2 et instances Windows

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