L’erreur Permission denied (publickey). est l’un des problèmes SSH les plus frustrants à diagnostiquer car elle peut avoir plusieurs causes, et le message d’erreur lui-même fournit très peu d’informations sur ce qui s’est mal passé. Cet article se concentre sur une cause particulièrement difficile — les répertoires home chiffrés — et couvre également les autres causes courantes et leurs solutions.
Le Problème
Vous avez correctement configuré l’authentification par clé SSH sur votre serveur Ubuntu. Tout fonctionne parfaitement — jusqu’à ce que vous redémarriez le serveur. Après le redémarrage, vous obtenez :
Permission denied (publickey).Vous accédez au serveur via la console, et tout semble correct — les clés sont au bon endroit, les permissions semblent correctes. Vous réessayez SSH et ça fonctionne. Redémarrez le serveur ou le service SSH, et l’erreur revient.
Ce comportement intermittent est le symptôme clé qui pointe vers un répertoire home chiffré comme cause racine.
Pourquoi les Répertoires Home Chiffrés Cassent l’Authentification SSH par Clé
Lorsque vous installez Ubuntu et choisissez de chiffrer votre répertoire home, le système utilise eCryptfs pour chiffrer ~/.Private et le monter dans votre répertoire home lors de la connexion. Voici ce qui se passe :
- Avant la connexion : Le contenu de votre répertoire home est chiffré. Le démon SSH essaie de lire
~/.ssh/authorized_keysmais ne peut pas car le répertoire est chiffré. - Pendant la connexion console : Vous entrez votre mot de passe, ce qui déclenche le déchiffrement et le montage de votre répertoire home.
- Après la connexion :
~/.ssh/authorized_keysest maintenant lisible, donc l’authentification par clé SSH fonctionne.
Cela crée un schéma déroutant où les clés SSH fonctionnent après une connexion manuelle mais échouent après un redémarrage.
Point clé : Les serveurs cloud (AWS, Azure, DigitalOcean, etc.) ne chiffrent pas les répertoires home par défaut, c’est pourquoi ce problème n’affecte généralement que les serveurs que vous avez installés vous-même avec l’option de chiffrement.
Diagnostic du Problème
Étape 1 : Activer la Sortie SSH Détaillée
Connectez-vous avec une verbosité maximale pour voir exactement où l’authentification échoue :
ssh -vvv utilisateur@votre-serveurRecherchez des lignes comme :
debug1: Offering public key: /home/votreutilisateur/.ssh/id_ed25519
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).La réponse type 51 signifie que le serveur a rejeté la clé.
Étape 2 : Vérifier les Logs du Serveur
Sur le serveur (accédé via console), examinez le journal d’authentification :
sudo tail -50 /var/log/auth.logPour les problèmes de répertoire home chiffré, vous pourriez voir :
sshd[1234]: Could not open authorized keys '/home/utilisateur/.ssh/authorized_keys': No such file or directoryCe message apparaît parce que le répertoire chiffré apparaît vide au démon SSH.
Étape 3 : Vérifier le Chiffrement du Répertoire Home
Vérifiez si votre répertoire home est chiffré :
ls -la /home/Si vous voyez un répertoire .ecryptfs ou .Private, votre répertoire home utilise le chiffrement :
ls -la /home/utilisateur/
# Si chiffré et non monté, vous pourriez voir :
# .ecryptfs .Private Access-Your-Private-Data.desktop README.txtVous pouvez également vérifier :
mount | grep ecryptfsSolution 1 : Stocker les Clés SSH en Dehors du Répertoire Home Chiffré (Recommandé)
La meilleure approche est de configurer SSH pour lire les clés autorisées depuis un emplacement en dehors du répertoire home chiffré.
Créer le Répertoire Alternatif de Clés
sudo mkdir -p /etc/ssh/authorized_keysCopier Vos Clés Autorisées
sudo cp ~/.ssh/authorized_keys /etc/ssh/authorized_keys/$USER
sudo chown root:root /etc/ssh/authorized_keys/$USER
sudo chmod 644 /etc/ssh/authorized_keys/$USERMettre à Jour la Configuration SSH
Éditez la configuration du démon SSH :
sudo nano /etc/ssh/sshd_configTrouvez la directive AuthorizedKeysFile et changez-la en :
AuthorizedKeysFile /etc/ssh/authorized_keys/%uLe %u est remplacé par le nom d’utilisateur pendant l’authentification.
Redémarrer SSH
sudo systemctl restart sshdTester la Configuration
Depuis votre machine locale :
ssh utilisateur@votre-serveurCela devrait maintenant fonctionner même après un redémarrage car /etc/ssh/authorized_keys/ n’est pas dans le répertoire home chiffré.
Important : Lorsque vous ajouterez de nouvelles clés SSH à l’avenir, vous devrez les ajouter à
/etc/ssh/authorized_keys/nomutilisateurau lieu de~/.ssh/authorized_keys.
Pour un tutoriel détaillé de cette approche, consultez : Comment stocker votre clé publique SSH dans un répertoire différent.
Solution 2 : Déchiffrer le Répertoire Home
Si vous décidez que vous n’avez plus besoin du chiffrement du répertoire home :
# Assurez-vous d'être connecté en tant que l'utilisateur
ecryptfs-migrate-home -u $USERAvertissement : Sauvegardez vos données avant de tenter cela. Le déchiffrement du répertoire home peut échouer s’il n’y a pas suffisamment d’espace disque (vous avez besoin d’environ le double de l’espace de votre répertoire home temporairement).
Autres Causes Courantes de ‘Permission denied (publickey)’
Si votre répertoire home n’est pas chiffré, l’erreur provient probablement d’une de ces causes :
Permissions de Fichiers Incorrectes
SSH est très strict concernant les permissions. Les éléments suivants doivent être correctement configurés :
# Répertoire home : pas d'écriture pour groupe/autres
chmod 755 ~
# ou
chmod 700 ~
# Répertoire .ssh : propriétaire uniquement
chmod 700 ~/.ssh
# authorized_keys : lecture/écriture propriétaire uniquement
chmod 600 ~/.ssh/authorized_keys
# Clé privée (sur votre client) : lecture propriétaire uniquement
chmod 600 ~/.ssh/id_ed25519Clé Non Ajoutée à authorized_keys
Vérifiez que votre clé publique est dans le fichier authorized_keys du serveur :
cat ~/.ssh/authorized_keysComparez-la avec votre clé publique locale :
# Sur votre machine locale
cat ~/.ssh/id_ed25519.pubAgent SSH Non Chargé
Si votre clé utilise une phrase de passe et l’agent SSH ne fonctionne pas :
# Démarrer l'agent
eval "$(ssh-agent -s)"
# Ajouter votre clé
ssh-add ~/.ssh/id_ed25519Mauvais Type de Clé
Les serveurs plus anciens peuvent ne pas supporter les types de clés plus récents comme Ed25519. Essayez de générer une clé RSA :
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_legacy
ssh-copy-id -i ~/.ssh/id_rsa_legacy.pub utilisateur@serveurConfiguration du Serveur Bloquant l’Authentification par Clé Publique
Vérifiez que le serveur autorise l’authentification par clé publique :
sudo grep -E "PubkeyAuthentication|AuthorizedKeysFile" /etc/ssh/sshd_configAssurez-vous que :
PubkeyAuthentication yesSELinux ou AppArmor Bloquant l’Accès
Sur les systèmes avec contrôle d’accès obligatoire :
# Vérifier SELinux
sudo restorecon -R ~/.ssh/
# Vérifier AppArmor
sudo aa-statusListe de Vérification Rapide
| Vérification | Commande |
|---|---|
| Sortie SSH détaillée | ssh -vvv utilisateur@serveur |
| Journal d’authentification | sudo tail -50 /var/log/auth.log |
| Home chiffré ? | mount | grep ecryptfs |
| Permissions .ssh | ls -la ~/.ssh/ |
| Contenu authorized_keys | cat ~/.ssh/authorized_keys |
| Configuration SSH | sudo sshd -T | grep -i pubkey |
| Clés de l’agent SSH | ssh-add -l |
Résumé
L’erreur Permission denied (publickey) causée par des répertoires home chiffrés est particulièrement insidieuse car elle fonctionne de manière intermittente — l’authentification par clé SSH réussit après une connexion manuelle mais échoue après un redémarrage. La solution recommandée est de stocker les clés autorisées en dehors du répertoire home chiffré en mettant à jour AuthorizedKeysFile dans sshd_config.
Pour d’autres causes de cette erreur, vérifiez systématiquement les permissions de fichiers, confirmez que la clé est dans authorized_keys, assurez-vous que l’agent SSH fonctionne et vérifiez le sshd_config du serveur. L’utilisation de ssh -vvv et la vérification de /var/log/auth.log révéleront presque toujours la cause racine.