Le message d'erreur« Autorisation refusée (publickey) » ou « Échec de l'authentification, autorisation refusée » s'affiche lorsque je tente d'accéder à mon instance EC2. Comment résoudre ce problème ?

Lecture de 8 minute(s)

Je reçois le message d'erreur « Permission denied (publickey) » [Autorisation refusée (publickey)] ou « Authentication failed, permission denied » (Échec de l'authentification, autorisation refusée) lors j'accède à mon instance Amazon Elastic Compute Cloud (Amazon EC2). Comment puis-je résoudre ce problème ?

Brève description

Le message d'erreur« Autorisation refusée (publickey) » ou « Échec de l'authentification, autorisation refusée » peut s'afficher lorsque :

vous tentez de vous connecter à l'aide d'un nom d'utilisateur incorrect pour votre AMI.
Les autorisations de fichier au sein du système d'exploitation sont incorrectes sur l'instance.
Le mauvais fichier de clé publique SSH (.pub) se trouve dans le fichier authorized_keys.

Solution

Vérifiez que le nom d'utilisateur associé à votre AMI est correct

Pour obtenir la liste des noms d'utilisateur valides, voir Erreur : Serveur a refusé notre clé ou Aucune méthode d'authentification prise en charge disponible.

Vérifiez que les autorisations de fichier sont correctes au sein du système d'exploitation et que la bonne clé publique SSH se trouve dans le fichier authorised_keys

Vous pouvez effectuer ces tâches de quatre façons :

Méthode 1 : utiliser EC2 Serial Console

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

Avant d'utiliser la console série, 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 la console série 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 à la console série, suivez les instructions de la méthode 2, 3 ou 4. Pour plus d'informations sur la configuration d'EC2 Serial Console pour Linux, consultez Configurer l'accès à EC2 Serial Console.

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

Méthode 2 : utilisation de la fonctionnalité Session Manager d'AWS Systems Manager pour vous connecter à l'instance et effectuer les modifications

Cette méthode permet de mettre à jour les autorisations et d'ajouter votre clé publique SSH au fichier authorized_keys.

Remarque : l'agent SSM est nécessaire pour utiliser cette méthode. 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 ls -ld pour vous assurer que les autorisations des fichiers se trouvant dans le répertoire de base sont les bonnes. Les autorisations appropriées sont répertoriées ci-dessous :

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

Voici un exemple de la commande ls -ld et le résultat obtenu. Dans cet exemple, ec2-user est le nom d'utilisateur. Modifiez le nom d'utilisateur en fonction de votre AMI spécifique.

$ ls -ld /home/ec2-user/
drwx------ 3 ec2-user ec2-user 4096 Apr  1 08:31 /home/ec2-user/

4. Sur votre ordinateur local, vérifiez la clé publique SSH.

5. Si la signature de la clé publique SSH n'est pas présente dans le résultat, mettez à jour le fichier authorized_keys pour autoriser votre clé SSH. Dans l'exemple suivant, remplacez l'exemple de clé par votre clé publique SSH.

$ echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVogCW5eZogRp+vF6Ut360b0bYyTmqgYaCXOyiW77I916AS5jFL3zsCtONbGn4hnG/UGGWXpLfUV85qpVJb38fskPZNuyZtjGjXM2W7qqbCZ1N9HBb6IPBaL97tmqBi+8rD7mSkoHc40sIV+KxkQSvD6AAFjQruCjxzfGIApnOvuj6IMsVEuFHBx4QhkbCzafxo02D9BZT4+dMy7tmyuC+UiNEQpgfFoszl+4VNFTIPlQQyn6CpUiV/rFXIadXsHqc+UOdVnfEXP+30YL75RHabze/1F5MY6t94AEcmcb05Dq4vwN9IjcxKmwgvxLOXzryytepvHQU+PobBEXAMPLE' >> /home/ec2-user/.ssh/authorized_keys

6. Pour modifier les autorisations, exécutez les commandes suivantes sur votre instance EC2.

$ 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

7. Terminer la session.

8. Connectez-vous à l'instance en utilisant SSH.

Méthode 3 : exécution de la procédureAWSSupport-TroubleshootSSH Automation

La procédure AWSSupport-TroubleshootSSH permet d'installer l'outil Amazon EC2Rescue. Après son installation, ce dernier identifie les problèmes qui provoquent des erreurs lors de la connexion à une machine Linux via SSH, puis y remédie. Pour plus d'informations, consultez la section Comment utiliser le flux de travail d'automatisation AWSSupport-TroubleshootSSH pour résoudre les problèmes de connexion SSH ?

Méthode 4 : utilisation d'un script de données utilisateur pour réparer les autorisations SSH et ajouter la bonne clé publique SSH au fichier authorized_keys

Important

Si votre instance est basée sur le stockage d'instance ou si des volumes de stockage d'instance contiennent des données, les données sont perdues lorsque l'instance est arrêtée. Pour plus d'informations, consultez 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 peut la résilier. Les instances lancées avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk peuvent faire partie d'un groupe AWS Auto Scaling. Dans ce cas, la désactivation dépend des paramètres de protection définis pour votre groupe Auto Scaling. Si votre instance fait partie d'un groupe Auto Scaling, supprimez-la temporairement de ce dernier avant de suivre les étapes de résolution.
L'arrêt et le redémarrage de l'instance entraînent la modification de son adresse IP publique. Lorsque vous acheminez du trafic externe vers votre instance, il est recommandé d'utiliser une adresse IP élastique plutôt qu'une adresse IP publique.

1. Ouvrez la console Amazon EC2.

2. Choisissez Instances dans le panneau de navigation, puis l'instance que vous tentez de lancer.

3. Arrêtez l'instance.

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

5. Copiez le script de données utilisateur suivant dans la boîte de dialogue Modifiez les données utilisateur, puis choisissez Enregistrer.

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
OS_USER=@@@@@@
chown root:root /home 
chmod 755 /home
chown $OS_USER:$OS_USER /home/$OS_USER -R
chmod 700 /home/$OS_USER
chmod 700 /home/$OS_USER/.ssh
chmod 600 /home/$OS_USER/.ssh/authorized_keys
--//

Remarque : Remplacez la valeur de OS_USER par le nom d'utilisateur associé à l'AMI à partir de laquelle vous avez lancé votre instance. Pour plus d'informations, consultez Obtenir le nom d'utilisateur par défaut de l'AMI que vous avez utilisée pour lancer votre instance dans Causes courantes de problèmes de connexion.

6. Sur votre ordinateur local, vérifiez la clé publique SSH.

7. Si la signature de la clé publique SSH n'est pas présente dans la sortie, ajoutez la clé correcte au script de données utilisateur que vous avez créé à l'étape 5. Si la signature correspond, vous pouvez ignorer cette étape. Ajoutez la clé publique SSH au script de données utilisateur, comme illustré dans l'exemple suivant. Remplacez l'exemple de clé par votre clé publique SSH.

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
OS_USER=@@@@@@
chown root:root /home 
chmod 755 /home
chmod 700 /home/$OS_USER
chmod 700 /home/$OS_USER/.ssh
chmod 600 /home/$OS_USER/.ssh/authorized_keys
echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDVogCW5eZogRp+vF6Ut360b0bYyTmqgYaCXOyiW77I916AS5jFL3zsCtONbGn4hnG/UGGWXpLfUV85qpVJb38fskPZNuyZtjGjXM2W7qqbCZ1N9HBb6IPBaL97tmqBi+8rD7mSkoHc40sIV+KxkQSvD6AAFjQruCjxzfGIApnOvuj6IMsVEuFHBx4QhkbCzafxo02D9BZT4+dMy7tmyuC+UiNEQpgfFoszl+4VNFTIPlQQyn6CpUiV/rFXIadXsHqc+UOdVnfEXP+30YL75RHabze/1F5MY6t94AEcmcb05Dq4vwN9IjcxKmwgvxLOXzryytepvHQU+PobBEXAMPLE' >> /home/$OS_USER/.ssh/authorized_keys
chown $OS_USER:$OS_USER /home/$OS_USER -R
--//

8. Démarrez l'instance.

Remarque : le script de données utilisateur précédent s'exécute à chaque redémarrage de l'instance. Après avoir récupéré l'accès à votre instance, supprimez le script de données utilisateur.

Pour supprimer le script de données utilisateur :