Dépannage des problèmes de permission SSH refusée (publickey)

Permission denied (publickey) signifie que le serveur était joignable, mais qu'il n'a accepté aucune tentative d'authentification par clé publique pour l'utilisateur que vous avez essayé. Cela réduit le problème. Vous ne dépannez plus le routage, le DNS, ou si le port SSH est ouvert. Vous dépannez l'identité : le nom d'utilisateur, la clé privée que votre client a proposée, la clé publique stockée sur le serveur, et les règles du serveur qui décident si cette connexion est autorisée.

La commande la plus rapide et utile est :

ssh -vvv user@your_server_ip

Recherchez Authenticating to ... as 'user', puis cherchez Offering public key. Si la clé attendue n'est pas proposée, corrigez le client. Si la clé attendue est proposée et rejetée, corrigez le authorized_keys côté serveur, la propriété, les permissions, ou la politique du démon SSH.

Causes courantes de l'erreur 'Permission Denied (publickey)'

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

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

Guide de dépannage étape par étape

Examinons les étapes pratiques pour diagnostiquer et résoudre 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 a les permissions correctes.

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

Votre clé privée se trouve souvent dans ~/.ssh/id_ed25519 ou ~/.ssh/id_rsa, mais de nombreuses équipes utilisent des noms spécifiques au projet. Listez vos clés :

ls -la ~/.ssh

Ne téléchargez pas et ne collez pas une clé privée dans authorized_keys. Le serveur a besoin du contenu du fichier .pub, pas de la clé privée.

Vérifier les permissions des fichiers locaux

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 (par exemple, 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 réel de votre fichier de clé privée.

Si vous testez une clé spécifique, forcez-la :

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod user@your_server_ip

Cela empêche votre agent de proposer d'abord une longue liste de clés non liées.

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

C'est souvent le coupable le plus courant. Le serveur doit avoir votre clé publique correctement listée pour l'utilisateur avec lequel vous tentez de vous authentifier.

Accéder au serveur (si possible)

Si vous pouvez toujours accéder au serveur via 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érifier l'emplacement du fichier authorized_keys

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

Vérifier les permissions des fichiers côté serveur

Comme 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érifiez également la propriété. Le répertoire .ssh et le fichier authorized_keys doivent normalement appartenir au compte avec lequel vous vous connectez :

chown -R youruser:youruser ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Si StrictModes est activé dans sshd_config, OpenSSH peut rejeter les clés lorsque le répertoire personnel ou le chemin .ssh est accessible en écriture par les mauvais utilisateurs.

Vérifier le 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 être 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, suivie d'une longue chaîne de caractères, et éventuellement d'un commentaire.

Exemple d'entrée authorized_keys :

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... your_public_key_string user@hostname

N'ajoutez pas votre clé privée à authorized_keys. Seule la clé publique doit être ici.

3. Assurez-vous 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érer votre clé publique locale

Votre clé publique est la contrepartie 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 cette sortie avec l'entrée dans le fichier ~/.ssh/authorized_keys du serveur. Même une seule faute de frappe ou un caractère manquant entraînera l'échec de l'authentification.

Pour une comparaison plus propre, imprimez la clé publique dérivée de la clé privée que vous essayez d'utiliser :

ssh-keygen -y -f ~/.ssh/id_ed25519_prod

Cette sortie doit correspondre à une ligne dans le authorized_keys de l'utilisateur distant.

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 user@your_server_ip

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écifiez la clé privée correcte (si ce n'est pas celle par défaut)

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

Utilisation du drapeau -i

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

ssh -i ~/.ssh/my_other_key user@your_server_ip

Configuration de ~/.ssh/config

Pour plus de commodité, vous pouvez configurer votre client SSH pour toujours utiliser 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 :

Host your_server_alias
  HostName your_server_ip_or_domain
  User your_username
  IdentityFile ~/.ssh/my_other_key
  IdentitiesOnly yes

Ensuite, vous pouvez vous connecter simplement en utilisant :

ssh your_server_alias

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 qu'il a chargé votre clé.

Vérifier si l'agent est en cours d'exécution

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.

Ajouter une clé à l'agent

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

ssh-add ~/.ssh/id_rsa

Si une phrase de passe vous est demandée, saisissez-la. Vous pouvez vérifier quelles clés sont ajoutées avec ssh-add -l.

Si ssh-add -l montre de nombreuses clés non liées et que le serveur se déconnecte après plusieurs tentatives, supprimez les anciennes clés de l'agent ou utilisez IdentitiesOnly yes pour cet hôte.

6. Débogage en mode verbeux

SSH a 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 user@your_server_ip

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

Exemple d'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 signifie que le client a essayé id_rsa, le serveur ne l'a pas acceptée, et le client est passé à la méthode autorisée suivante.

7. Révision de sshd_config côté serveur (Avancé)

Vérifiez /etc/ssh/sshd_config et tous les fichiers dans /etc/ssh/sshd_config.d/. Confirmez que l'authentification par clé publique est activée :

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Ensuite, recherchez les blocs Match près du bas du fichier. Un bloc Match User, Match Group, ou Match Address ultérieur peut remplacer les paramètres précédents pour le compte exact que vous testez.

Après toute modification, validez la syntaxe avant de recharger :

sudo sshd -t
sudo systemctl reload sshd

Certains systèmes utilisent ssh comme nom de service au lieu de sshd.

Un ordre de dépannage fiable

Utilisez la sortie verbeuse pour éviter de deviner. Confirmez d'abord le nom d'utilisateur. Ensuite, confirmez que le client propose la clé privée que vous attendez. Ensuite, confirmez que la clé publique correspondante se trouve dans le authorized_keys de l'utilisateur cible. Ensuite, vérifiez la propriété et les permissions. Ce n'est qu'après que ceux-ci sont propres que vous devriez passer du temps sur sshd_config, les blocs Match, les contextes SELinux, ou les restrictions de compte.

Cet ordre résout la plupart des cas de Permission denied (publickey) sans changements aléatoires, et il vous évite d'affaiblir la sécurité SSH juste pour obtenir une connexion urgente.