Résolution des problèmes de « Permission refusée (clé publique) » SSH

Dépannage des problèmes SSH "Permission Denied (publickey)"

Lorsque vous tentez de vous connecter à un serveur distant via SSH, rencontrer l'erreur "Permission Denied (publickey)" (Accès refusé (clé publique)) peut être un obstacle frustrant. Cette erreur indique spécifiquement que le serveur a rejeté votre connexion car il n'a pas pu vous authentifier à l'aide de votre clé publique. Contrairement à l'authentification par mot de passe, la cryptographie à clé publique repose sur une paire de clés : une clé privée conservée secrète sur votre machine locale et une clé publique placée sur le serveur. Ce guide vous expliquera les causes courantes de cette erreur et vous fournira des étapes détaillées pour les diagnostiquer et les résoudre, garantissant ainsi un accès SSH sécurisé et fluide.

Comprendre le processus d'authentification par clé publique SSH est crucial pour un dépannage efficace. Lorsque vous essayez de vous connecter, votre client SSH présente votre clé publique au serveur. Le serveur vérifie ensuite si cette clé publique est autorisée pour votre compte utilisateur. Si c'est le cas, le serveur chiffre un défi avec votre clé publique et le renvoie. Votre client, possédant la clé privée correspondante, déchiffre le défi et renvoie la réponse au serveur. Si la réponse est correcte, l'authentification réussit. Une erreur "Permission Denied (publickey)" signifie que cet échange a échoué à un moment donné.

Causes courantes de "Permission Denied (publickey)"

L'erreur "Permission Denied (publickey)" peut provenir de plusieurs problèmes de configuration. Identifier la cause première implique souvent de vérifier systématiquement les composants suivants :

Permissions de fichiers incorrectes : SSH est très sensible aux permissions des fichiers et des répertoires pour des raisons de sécurité. Des autorisations incorrectes sur votre répertoire local ~/.ssh, le fichier de clé privée, ou sur le répertoire ~/.ssh et le fichier authorized_keys côté serveur peuvent empêcher l'authentification.
Entrée manquante ou incorrecte dans authorized_keys : Le fichier authorized_keys du serveur doit contenir la clé publique correcte pour l'utilisateur sous lequel vous essayez de vous connecter. Si la clé est manquante, mal formatée ou associée au mauvais utilisateur, l'authentification échouera.
Association de paire de clés incorrecte : Votre client SSH propose peut-être la mauvaise clé privée, ou le serveur n'a peut-être pas la clé publique correspondante listée dans le fichier authorized_keys.
Problèmes d'agent SSH : Si vous utilisez un agent SSH, il se peut qu'il n'ait pas chargé correctement votre clé privée, ou qu'il soit mal configuré.
Configuration SSH côté serveur : Bien que moins courant pour cette erreur spécifique, la configuration du démon SSH du serveur (sshd_config) peut comporter des restrictions spécifiques sur l'authentification par clé publique.

Guide de dépannage étape par étape

Plongeons dans les étapes pratiques pour diagnostiquer et corriger ces problèmes.

1. Vérifier la clé privée locale et les permissions

Votre configuration SSH locale est le premier endroit à vérifier. Assurez-vous que votre clé privée est accessible et possède les permissions correctes.

Vérification de l'existence de la clé privée

Votre clé privée se situe généralement dans ~/.ssh/id_rsa (ou id_ed25519, id_dsa, etc.).

Vérification des permissions de fichiers locales

Le répertoire ~/.ssh et votre fichier de clé privée doivent avoir des permissions restrictives pour empêcher tout accès non autorisé.

Répertoire ~/.ssh : Doit être 700 (drwx------).
Fichier de clé privée (ex. id_rsa) : Doit être 600 (-rw-------).

Utilisez la commande chmod pour définir les permissions correctes :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

Astuce : Si vous utilisez un nom de clé différent, remplacez id_rsa par le nom de fichier de votre clé privée réelle.

2. Vérifier la configuration `authorized_keys` côté serveur

C'est souvent le coupable le plus fréquent. Le serveur doit avoir votre clé publique correctement listée pour l'utilisateur que vous tentez d'utiliser pour vous authentifier.

Accéder au serveur (si possible)

Si vous pouvez toujours accéder au serveur par une autre méthode (par exemple, authentification par mot de passe, un autre compte utilisateur ou une console), connectez-vous pour vérifier le fichier authorized_keys.

Vérification de l'emplacement du fichier `authorized_keys`

Le fichier authorized_keys se situe généralement à l'emplacement ~/.ssh/authorized_keys dans le répertoire personnel de l'utilisateur sous lequel vous essayez de vous connecter.

Vérification des permissions de fichiers côté serveur

Similaire au côté client, les permissions côté serveur sont critiques :

Répertoire ~/.ssh sur le serveur : Doit être 700 (drwx------).
Fichier authorized_keys sur le serveur : Doit être 600 (-rw-------).

Assurez-vous que ces permissions sont correctement définies sur le serveur :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Vérification du contenu de `authorized_keys`

Ouvrez le fichier ~/.ssh/authorized_keys à l'aide d'un éditeur de texte (par exemple, nano, vim). Chaque clé publique doit se trouver sur une seule ligne. Assurez-vous que la clé publique que vous prévoyez d'utiliser est présente et correctement formatée. Elle doit commencer par ssh-rsa, ssh-ed25519, ou similaire, suivi d'une longue chaîne de caractères, et éventuellement d'un commentaire.

Exemple d'entrée authorized_keys :

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... votre_chaine_de_cle_publique utilisateur@nom_hote

Important : N'ajoutez pas votre clé privée à authorized_keys. Seule la clé publique doit s'y trouver.

3. S'assurer que la bonne clé publique a été ajoutée

Il est possible que la mauvaise clé publique ait été copiée ou que la clé publique sur le serveur ne corresponde pas à votre clé privée locale.

Récupération de votre clé publique locale

Votre clé publique est le pendant de votre clé privée. Vous pouvez la visualiser à l'aide de la commande ssh-keygen :

cat ~/.ssh/id_rsa.pub

Cette commande affichera votre clé publique. Comparez attentivement ce résultat avec l'entrée dans le fichier ~/.ssh/authorized_keys du serveur. Même une seule faute de frappe ou un caractère manquant provoquera l'échec de l'authentification.

Astuce : Un moyen rapide d'ajouter votre clé publique si vous avez un accès par mot de passe au serveur est d'utiliser ssh-copy-id.

ssh-copy-id utilisateur@votre_ip_serveur

Cette commande ajoute automatiquement votre clé publique par défaut (~/.ssh/id_rsa.pub) au fichier ~/.ssh/authorized_keys sur le serveur distant et définit les permissions correctes.

4. Spécifier la clé privée correcte (si elle n'est pas par défaut)

Si vous utilisez une clé privée non standard (par exemple, ~/.ssh/ma_cle_autre), vous devez indiquer à votre client SSH quelle clé utiliser.

Utilisation de l'option `-i`

Vous pouvez spécifier le fichier d'identité (clé privée) avec l'option -i :

ssh -i ~/.ssh/ma_cle_autre utilisateur@votre_ip_serveur

Configuration de `~/.ssh/config`

Pour plus de commodité, vous pouvez configurer votre client SSH pour qu'il utilise toujours une clé spécifique pour un hôte donné :

Créez ou modifiez le fichier ~/.ssh/config sur votre machine locale et ajoutez une entrée comme celle-ci :

Hôte alias_votre_serveur
  HoteName votre_ip_ou_domaine_serveur
  Utilisateur votre_nom_utilisateur
  FichierIdentite ~/.ssh/ma_cle_autre

Ensuite, vous pouvez vous connecter simplement en utilisant :

ssh alias_votre_serveur

5. Vérifier l'état de l'agent SSH

Si vous comptez sur un agent SSH pour gérer vos clés, assurez-vous qu'il est en cours d'exécution et que votre clé y est chargée.

Vérification de l'exécution de l'agent

echo "$SSH_AUTH_SOCK"

Si cela affiche un chemin, l'agent est probablement en cours d'exécution. S'il est vide, vous devrez peut-être en démarrer un.

Ajout de la clé à l'agent

Si votre clé n'est pas chargée, ajoutez-la :

ssh-add ~/.ssh/id_rsa

Si vous êtes invité à entrer une phrase de passe, entrez-la. Vous pouvez vérifier quelles clés sont ajoutées avec ssh-add -l.

6. Débogage avec le mode verbeux

SSH dispose d'un mode verbeux (-v, -vv, ou -vvv pour des niveaux de détail croissants) qui peut fournir des indices précieux sur l'endroit où le processus d'authentification échoue.

ssh -vvv utilisateur@votre_ip_serveur

Examinez la sortie pour trouver des messages liés à l'authentification par clé, à l'offre de clés et aux réponses du serveur. Cela indique souvent directement le problème.

Extrait de sortie verbeuse indiquant un échec de publickey :

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: read PEM private key file /home/user/.ssh/id_rsa
debug1: failed to use sshkey: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

Cette sortie pourrait indiquer que le client a tenté d'utiliser id_rsa mais a échoué, puis est passé à d'autres méthodes.

7. Revue de `sshd_config` côté serveur (Avancé)

Bien que moins courant pour les erreurs spécifiques à publickey (généralement d'autres erreurs apparaîtraient), il est utile de noter le fichier de configuration du démon SSH du serveur (/etc/ssh/sshd_config). Assurez-vous que PubkeyAuthentication yes n'est pas commenté et est réglé sur yes. Après avoir effectué des modifications, le service SSH doit être rechargé ou redémarré (par exemple, sudo systemctl reload sshd ou sudo systemctl restart sshd).

Résumé et Bonnes Pratiques

Le dépannage des erreurs SSH "Permission Denied (publickey)" implique une vérification méthodique des configurations du client et du serveur. Les causes les plus fréquentes sont liées aux permissions de fichiers incorrectes sur les fichiers ~/.ssh et authorized_keys, et aux décalages entre la clé publique sur le serveur et la clé privée sur le client.

Points Clés à Retenir :

Les permissions sont primordiales : Assurez-vous toujours que ~/.ssh est 700 et que les clés privées/authorized_keys sont 600 sur le client et le serveur.
Précision de la clé publique : Vérifiez que la clé publique exacte est présente dans le fichier authorized_keys du serveur.
Utilisez ssh-copy-id : Lorsque c'est possible, c'est la manière la plus sûre et la plus simple de configurer l'authentification par clé publique.
Mode verbeux : Utilisez ssh -vvv pour obtenir une sortie de diagnostic détaillée.

En suivant ces étapes, vous devriez être en mesure de diagnostiquer et de résoudre la plupart des problèmes de type "Permission Denied (publickey)", rétablissant ainsi un accès distant sécurisé à vos serveurs.