Pourquoi le message d'erreur « Server Refused Our Key » (Clé refusée par le serveur) s'affiche-t-il lorsque je tente de me connecter à mon instance EC2 à l'aide d'une clé SSH ?

Date de la dernière mise à jour : 12/03/2021

Je reçois le message d'erreur « Server Refused Our Key » (Clé refusée par le serveur) lorsque je me connecte à mon instance Amazon Elastic Compute Cloud (Amazon EC2) à l'aide d'une clé SSH. Comment puis-je résoudre ce problème ?

Brève description

Il existe plusieurs raisons pour lesquelles un serveur SSH (sshd) refuse une clé SSH privée. Voici quelques-unes des raisons les plus courantes qui peuvent expliquer pourquoi vous recevez cette erreur :

Résolution

Vous employez un nom d'utilisateur incorrect avec votre AMI lorsque vous vous connectez à votre instance EC2

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

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

Des problèmes d'autorisations existent sur l'instance ou un répertoire est manquant

Vous pouvez vérifier les autorisations et les répertoires associés à l'instance de trois façons :

Méthode 1 : utilisez la fonctionnalité Session Manager d'AWS Systems Manager pour vous connecter à l'instance et vérifier les autorisations

Remarque : l'installation de l'agent SSM est requise pour réaliser cette procédure. Pour obtenir des informations supplémentaires sur la fonctionnalité Session Manager et la liste complète des conditions préalables, consultez Configuration de Session Manager.

1.    Ouvrez AWS Systems Manager console.

2.    Démarrez une session.

3.    Utilisez la commande stat pour vous assurer que les autorisations des fichiers se trouvant dans le répertoire de base sont correctes. Les autorisations correctes sont les suivantes :

  • Le répertoire de base Linux (/home, par exemple) doit correspondre à (0755/drwxr-xr-x).
  • Le répertoire de base de l'utilisateur (/home/ec2-user/, par exemple) doit correspondre à (0700/drwx------).
  • L'autorisation de répertoire .ssh, (/home/ec2-user/.ssh, par exemple), doit correspondre à (0700/drwx—).
  • L'autorisation de fichier authorized_keys (/home/ec2-user/.ssh/authorized_keys, par exemple) doit correspondre à (0600/-rw------).

Un exemple de la commande stat et le résultat obtenu sont illustrés ci-dessous. 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.    Terminer la session.

6.    Connectez-vous à votre instance à l'aide d'une clé SSH.

Méthode 2 : Corrigez automatiquement les problèmes provoquant l'erreur en exécutant le document AWSSupport-TroubleshootSSH

Le document d'automatisation AWSSupport-TroubleshootSSH installe l'outil Amazon EC2Rescue sur l'instance, puis recherche et corrige certains problèmes qui provoquent des erreurs de connexion à distance lors de la connexion à une machine Linux via SSH. Pour obtenir des informations supplémentaires, consultez la section Comment puis-je utiliser le flux de travail d'automatisation AWSSupport-TroubleshootSSH pour résoudre les problèmes de connexion SSH ?.

Méthode 3 : utilisez des données utilisateur pour corriger les autorisations sur l'instance

Important !

  • Cette procédure de récupération implique que vous arrêtiez et redémarriez votre instance. Les données se trouvant sur les volumes de stockage d'instance seront donc perdues. Pour plus d'informations, consultez Déterminer le type d'appareil racine de votre instance.
  • Si votre instance fait partie d'un groupe Amazon EC2 Auto Scaling, l'instance peut s'arrêter lorsqu'elle est mise hors service. Cela peut également se produire sur les 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 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 temporairement l'instance du groupe Auto Scaling avant d'entamer 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 de l'acheminement 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 Déterminer le type d'appareil 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 puissent être effectuées correctement. Pour plus d'informations sur le module SSH cloud-init, consultez la section SSH - Configuration de SSH et des clés SSH.

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

2.    Sélectionnez État de l'instance, puis Arrêter l'instance.

Remarque : si l'action Arrêter est désactivée, l'instance est déjà arrêtée ou son périphérique racine est un volume de stockage d'instance.

3.    Choisissez Actions, ensuite Paramètres de l'instance, puis Modifier les données utilisateur.

4.    Copiez le script suivant dans le champ User Data (Données utilisateur), puis sélectionnez Save (Enregistrer). Assurez-vous de copier l'intégralité du script sans ajouter d'espaces supplémentaires.

Remarque : le nom d'utilisateur ec2-user est utilisé dans le script suivant. 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 connectez-vous à l'instance à l'aide d'une clé 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 bonne pratique consiste à prendre en compte les implications en termes de sécurité de l'exécution des données utilisateur 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 ModifyInstanceAttribute API. Pour limiter l'accès à cette méthode, utilisez les stratégies AWS Identity and Access Management (IAM).