Corriger « Permission denied (publickey) » avec SSH

Ce que signifie réellement « Permission denied (publickey) »

« Permission denied (publickey) » signifie que votre client a envoyé une ou plusieurs clés publiques et que le serveur n’en a accepté aucune. Le réseau fonctionne et sshd est en cours d’exécution : le refus se produit lors de la dernière étape de l’authentification. Le correctif ne repose jamais sur des suppositions, car ssh -v vous indique laquelle des cinq causes s’applique.

Les éléments entre parenthèses correspondent aux méthodes que le serveur acceptait. Permission denied (publickey) signifie à lui seul que l’authentification par mot de passe est désactivée sur ce serveur ; aucun mot de passe ne peut donc servir de solution de repli. Permission denied (publickey,password) signifie que les mots de passe étaient proposés et que vous avez également échoué avec cette méthode.

Un seul message couvre cinq problèmes distincts, et il reste volontairement vague. Un serveur qui répondrait « utilisateur inexistant » ou « cette clé n’est pas installée » aiderait toute personne à rechercher des comptes valides. Ne commencez donc pas par remplacer des clés ni par modifier des fichiers de configuration. Exécutez une commande, lisez trois lignes de sortie, et les cinq causes possibles se réduisent à une seule.

Exécutez d’abord ssh -v et lisez trois lignes

Répétez la commande qui a échoué en ajoutant -v :

ssh -v deploy@203.0.113.10

Une sortie abrégée mais réaliste ressemble à ceci :

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

Trois lignes contiennent toutes les informations nécessaires.

Authenticating to 203.0.113.10:22 as 'deploy' est le nom d’utilisateur qui sera réellement utilisé. Ce n’est pas celui que vous vouliez utiliser, mais celui que ssh a déterminé à partir de la ligne de commande, de ~/.ssh/config ou de votre nom de connexion local.

Authentications that can continue: publickey est la liste des méthodes acceptées par le serveur, envoyée avant toute tentative avec une clé. Si publickey est absent de cette première liste, l’authentification par clé publique est désactivée sur le serveur. Aucune clé ne pourra donc fonctionner.

Offering public key: ... correspond à une ligne par clé réellement envoyée par votre client. Elle indique le fichier d’origine et son empreinte SHA256. Une clé sans ligne Offering n’a jamais été envoyée au serveur.

Séparez maintenant le problème en deux :

• Il n’y a pas de ligne Offering public key pour la clé attendue. Le problème vient de votre machine, car le serveur n’a pas du tout reçu votre clé.
• La clé est proposée et Authentications that can continue: publickey réapparaît. Le serveur a reçu cette clé et l’a refusée. Le problème vient donc du serveur.

Les causes ci-dessous sont classées selon la fréquence à laquelle elles s’avèrent être la réponse.

Cause 1 : vous vous connectez avec le mauvais nom d’utilisateur

La cause la plus fréquente est aussi la moins intéressante. sshd, le daemon serveur SSH (Secure Shell), ne vous indique jamais qu’un compte n’existe pas. Il exécute tout l’échange avec un nom d’utilisateur inventé, puis refuse la connexion à la fin avec le même message, car divulguer les noms de comptes valides aide un attaquant. Une faute de frappe dans le nom d’utilisateur ressemble exactement à une clé défectueuse.

Vérifiez la ligne Authenticating to ... as avant toute autre chose. Si elle indique le nom de connexion de votre ordinateur portable au lieu du compte du serveur, vous avez omis le nom d’utilisateur dans la commande.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

Le compte par défaut dépend de l’image créée par votre fournisseur. En août 2026, les images cloud Ubuntu utilisent généralement un compte ubuntu, les images Debian utilisent debian ou admin, Rocky Linux et AlmaLinux utilisent rocky et almalinux, et de nombreux fournisseurs de VPS installent directement votre clé dans root. Le panneau de contrôle de votre fournisseur indique le compte qu’il a créé. Aucune commande exécutée depuis l’extérieur du serveur ne peut le lui demander.

Un bloc Host dans ~/.ssh/config définit également le nom d’utilisateur et prend le pas sur votre nom de connexion local :

Host vps-prod
  HostName 203.0.113.10
  User deploy

Si vous avez créé vous-même le compte et que vous n’avez ensuite pas pu vous y connecter, la clé a probablement été installée pour l’utilisateur par défaut de l’image et n’a jamais été copiée sur ce compte. Cette étape fait partie des dix premières minutes sur un nouveau VPS et il est facile de l’oublier.

Cause 2 : la clé que vous pensez envoyer n’est pas celle qui est envoyée

Par défaut, ssh ne propose que les clés détenues par ssh-agent, ainsi qu’un ensemble fixe de noms de fichiers dans ~/.ssh : id_ed25519, id_ecdsa, id_rsa et les variantes hardware et DSA de ces noms. Une clé enregistrée sous ~/.ssh/vps-prod est invisible pour ssh tant que vous ne l’indiquez pas explicitement. C’est pourquoi la sortie détaillée ne contient aucune ligne Offering public key pour cette clé.

Indiquez le fichier et empêchez les clés de l’agent de prendre sa place :

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

-i seul ne suffit pas lorsque l’agent détient des clés, car ssh propose toujours d’abord les clés de l’agent, puis le fichier indiqué en dernier. Cela a son importance, car le serveur compte chaque clé refusée dans MaxAuthTries, dont la valeur par défaut est 6. Un agent qui détient sept clés peut atteindre cette limite avant que ssh n’essaie votre clé correcte. Le message devient alors :

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes limite la tentative au fichier que vous avez indiqué. Affichez les clés détenues par l’agent avec ssh-add -l, puis supprimez-les avec ssh-add -D s’il a accumulé d’anciennes clés au fil des années. Enregistrez ensuite ces paramètres afin que la prochaine connexion ne dépende pas du souvenir des options :

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Autre piège côté client. ssh refuse d’utiliser une clé privée lisible par d’autres comptes sur votre propre machine. Il affiche un avertissement, puis ignore la clé. Celle-ci n’est donc jamais proposée et le serveur ne la reçoit jamais :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod corrige le problème. Le transfert d’une clé sur une clé USB ou via un partage Windows est la cause habituelle de la perte des permissions. L’emplacement des clés et leur nommage sont expliqués dans Notions de base sur la gestion des clés SSH.

Cause 3 : la clé publique n’a jamais atteint authorized_keys

Si ssh -v montre que la clé est bien envoyée, mais que le serveur la refuse toujours, vérifiez ensuite si cette clé se trouve dans le fichier authorized_keys du compte. Ouvrez la console de votre fournisseur pour le contrôler, puisque vous ne pouvez pas vous connecter en SSH pour effectuer cette vérification.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

ssh-keygen -lf sur un fichier authorized_keys affiche une empreinte par entrée :

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

Comparez ces empreintes avec celle de votre ligne Offering public key. Si elle ne figure pas dans la liste, la clé n’est pas installée sur ce compte, quelles que soient vos manipulations précédentes.

Voici quatre causes fréquentes :

• Vous avez collé la clé privée au lieu du fichier .pub. Une ligne de clé publique commence par ssh-ed25519 ou ssh-rsa. Une clé privée commence par -----BEGIN OPENSSH PRIVATE KEY-----.
• Le collage s’est réparti sur plusieurs lignes. Chaque entrée doit tenir sur une seule ligne. Une clé coupée est donc interprétée comme plusieurs entrées invalides et ne correspond à rien.
• La clé a été ajoutée dans /root/.ssh/authorized_keys alors que vous vous connectez avec deploy, ou inversement. Le fichier est propre à chaque compte. Il n’existe pas de fichier partagé.
• Le champ « add my key » du fournisseur a écrit la clé uniquement pour l’utilisateur par défaut de l’image. Le compte créé ensuite possède donc un répertoire .ssh vide.

Depuis la console, la méthode sûre pour ajouter une clé en tant que root est la suivante :

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Exécutez de nouveau sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys. La nouvelle empreinte doit maintenant figurer dans la liste. Depuis une machine qui peut encore se connecter avec un mot de passe, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 effectue la même opération et définit correctement les permissions.

Cause 4 : pourquoi sshd ignore authorized_keys lorsque les permissions sont trop ouvertes

StrictModes yes est la configuration par défaut de sshd. Avec cette configuration, sshd refuse de lire authorized_keys si ce fichier, le répertoire .ssh ou le répertoire personnel du compte peut être modifié par un utilisateur autre que le propriétaire. La raison est simple : si le groupe ou les autres utilisateurs peuvent écrire dans votre répertoire personnel, tout compte disposant de cet accès peut remplacer authorized_keys et prendre le contrôle de la connexion. sshd considère alors le chemin comme non fiable, comme si aucune clé n’existait.

Le client affiche le simple message Permission denied. Le journal du serveur indique la véritable cause :

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

ou, lorsque le problème vient du fichier lui-même :

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

Ce que sshd accepte :

• Le répertoire personnel : il ne doit être inscriptible ni par le groupe ni par les autres utilisateurs. 755, 750 et 700 sont acceptés. 775 et 777 sont refusés.
• ~/.ssh : mode 700.
• ~/.ssh/authorized_keys : mode 600.
• Propriétaire : les trois éléments doivent appartenir au compte avec lequel vous vous connectez, et non à root.

Le propriétaire est aussi important que le mode. Un fichier dans /home/deploy/.ssh appartenant à root échoue au même contrôle. C’est ce qui se produit lorsque vous le créez avec sudo nano sans ensuite le rendre à son propriétaire. Corrigez les deux à la fois :

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

La dernière commande affiche le résultat. Le répertoire personnel doit avoir au minimum drwxr-xr-x, ou des permissions plus restrictives, et drwx------ doit être appliqué à .ssh. Si ces chaînes ne sont pas encore évidentes, consultez comment lire une chaîne de permissions comme drwxr-xr-x avant de modifier les modes sur un serveur en production.

Sur Rocky Linux et AlmaLinux, ajoutez SELinux (security-enhanced Linux) à la liste des causes possibles. Un répertoire .ssh créé par une méthode inhabituelle peut avoir le mauvais label de fichier. sshd se voit alors refuser l’accès en lecture, même si les modes sont corrects. sudo restorecon -Rv /home/deploy/.ssh rétablit les labels, et sudo ausearch -m avc -ts recent indique si SELinux est le composant qui a refusé l’accès.

Cause 5 : sshd est configuré pour vous refuser

La lecture de /etc/ssh/sshd_config ne suffit pas sur un système Ubuntu ou Debian récent. Ce fichier commence par Include /etc/ssh/sshd_config.d/*.conf, et OpenSSH conserve la première valeur trouvée pour chaque paramètre. Un fichier drop-in tel que 50-cloud-init.conf est donc lu en premier et prend le dessus sur toute modification effectuée plus bas dans le fichier principal. C’est pourquoi une modification peut sembler correcte sans rien changer du tout.

Demandez à sshd quelle configuration il utilise réellement :

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

Voici à quoi ressemble une réponse correcte :

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Voici les éléments à rechercher dans votre propre sortie :

• pubkeyauthentication no. Aucune clé ne sera acceptée. Cela apparaît également dans ssh -v sous la forme d’une première liste Authentications that can continue: sans aucun publickey.
• authorizedkeysfile pointe vers un autre emplacement, par exemple /etc/ssh/authorized_keys/%u. Le fichier présent dans le répertoire personnel est alors complètement ignoré, et les règles de permissions de la cause 4 s’appliquent au nouvel emplacement.
• allowusers ou allowgroups est présent. Tout compte qui n’est pas listé est refusé avec exactement cette erreur, sans explication. denyusers et denygroups font l’inverse.
• permitrootlogin no lorsque vous essayez de vous connecter en tant que root. prohibit-password est le réglage intermédiaire utile : root peut utiliser une clé, mais pas un mot de passe.

Les blocs Match n’apparaissent pas dans une simple commande sshd -T, car leur résultat dépend de l’identité de la personne qui se connecte. Interrogez la configuration pour une connexion précise :

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Un autre paramètre concerne les anciennes clés. OpenSSH 8.8 a cessé d’accepter par défaut les signatures SHA-1 (ssh-rsa). Une clé RSA qui fonctionnait depuis des années peut donc cesser de fonctionner juste après la mise à niveau du serveur. Le client l’indique clairement :

debug1: send_pubkey_test: no mutual signature algorithm

La bonne solution consiste à créer une nouvelle clé : ssh-keygen -t ed25519 -C "deploy@vps-prod", puis à installer le fichier .pub comme indiqué plus haut. Définir PubkeyAcceptedAlgorithms +ssh-rsa sur le serveur réactive les anciennes signatures et vous permet de vous connecter immédiatement. Considérez cette option comme un moyen d’accéder au serveur, et non comme la fin de l’intervention. Les autres paramètres côté serveur à vérifier sont décrits dans le renforcement de la sécurité du serveur SSH sur un VPS.

Comment prouver qu’une clé privée correspond à la clé publique installée

La plupart des hésitations face à cette erreur viennent du fait qu’on ne sait pas si deux fichiers forment une paire. Une commande permet de le vérifier :

ssh-keygen -y -f ~/.ssh/vps-prod

Cette commande affiche la clé publique dérivée de la clé privée. Elle ne lit jamais le fichier .pub placé à côté. Elle indique donc ce que contient réellement la clé privée, et non ce qu’affirme un fichier .pub obsolète. Si la clé est protégée par une phrase secrète, la commande vous la demande. Cela prouve également que vous connaissez toujours cette phrase secrète.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

La première commande affiche l’empreinte d’un fichier de clé publique. La seconde affiche les empreintes que votre agent détient. Comparez les quatre représentations de cette même chaîne : l’empreinte de la ligne Offering public key de ssh -v, l’empreinte de votre fichier .pub, les empreintes de ssh-keygen -lf dans le fichier authorized_keys du serveur et l’empreinte présente dans le journal du serveur. L’endroit où elles cessent de correspondre indique votre erreur.

Consultez le journal du serveur lorsque la connexion échoue

Le client ne reçoit volontairement aucune information utile. Le serveur consigne la cause réelle. Commencez par suivre le journal dans la session de console, puis exécutez depuis votre ordinateur portable la commande ssh qui échoue.

sudo journalctl -u ssh -f

Ubuntu 24.04 n’installe pas rsyslog par défaut. /var/log/auth.log peut donc ne pas y exister. Sur Rocky Linux et AlmaLinux, l’unité s’appelle sshd et les mêmes enregistrements sont également écrits dans /var/log/secure.

Définissez LogLevel VERBOSE dans la configuration de sshd, puis rechargez le service. Chaque tentative consigne alors l’empreinte que le serveur a réellement reçue :

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

Cette ligne indique de quel côté se trouve le problème. Si vous reconnaissez l’empreinte, votre clé est bien arrivée et a été rejetée par le serveur. Examinez alors les causes 3, 4 et 5. Si vous ne reconnaissez pas l’empreinte, votre client a envoyé une autre clé que celle prévue. Revenez donc à la cause 2.

Si le journal reste difficile à interpréter, lancez un second sshd sur un autre port, en mode debug. Il reste au premier plan, accepte une connexion, affiche son raisonnement, puis se termine :

sudo /usr/sbin/sshd -ddd -p 2222

Depuis la session de console sur le même serveur, connectez-vous à cette instance via l’adresse loopback :

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

L’utilisation de 127.0.0.1 exclut le firewall du test. La sortie du mode debug indique le fichier ouvert, l’empreinte comparée et le refus exact, notamment les lignes telles que Authentication refused: bad ownership or modes for directory /home/deploy. Appuyez sur Ctrl+C lorsque vous avez trouvé la cause. Le sshd réel, sur le port 22, n’est pas modifié pendant toute l’opération.

Ne pas vous verrouiller hors du serveur

Chaque étape qui modifie la configuration du serveur doit prévoir un moyen d’y accéder qui ne dépend pas de SSH. Configurez-le tant que SSH fonctionne, et non après une panne.

1. Ouvrez la console de votre fournisseur, via une connexion série ou VNC (virtual network computing), et vérifiez que vous pouvez vous y connecter.
2. Vérifiez que vous connaissez un mot de passe local fonctionnel pour un compte avec les droits sudo. Si ce n’est pas le cas, réinitialisez d’abord le mot de passe root depuis la console du fournisseur.
3. Gardez votre session SSH actuelle ouverte. Une session ouverte survit à systemctl restart ssh. Elle reste donc un moyen d’accès si la nouvelle configuration est incorrecte.
4. Vérifiez la syntaxe avant de redémarrer : sudo sshd -t n’affiche rien lorsque le fichier est valide. En cas d’erreur, il affiche le fichier et le numéro de ligne concernés.
5. Ouvrez un deuxième terminal et connectez-vous avec une nouvelle session avant de fermer la première. Une configuration incorrecte empêche les nouvelles connexions, mais laisse les connexions existantes intactes. La session que vous utilisez ne permet donc pas de vérifier si la modification a fonctionné.

Redémarrez avec sudo systemctl restart ssh sur Debian et Ubuntu, ou avec sudo systemctl restart sshd sur Rocky Linux et AlmaLinux. Sur Ubuntu 24.04, sshd est lancé depuis une socket unit. Une modification de Port ou ListenAddress nécessite donc également sudo systemctl restart ssh.socket avant de prendre effet.

FAQ

Pourquoi ai-je « Permission denied (publickey) » alors que la même clé fonctionne sur un autre serveur ?

Parce que la clé est correcte, mais qu’un élément autour d’elle ne l’est pas. Exécutez ssh -v et recherchez la ligne Offering public key. Si votre clé n’est pas listée, ssh ne l’a jamais envoyée : le fichier n’est pas présent dans ~/.ssh sous un nom par défaut et n’est pas chargé dans l’agent. Ajoutez donc -i /path/to/key -o IdentitiesOnly=yes. Si la clé est listée mais que le serveur la refuse toujours, elle est absente du authorized_keys du compte, le chemin qui y mène est accessible en écriture par le groupe, ou la configuration de sshd bloque l’utilisateur. Le journal du serveur permet de distinguer ces cas.

Comment voir quelle clé SSH envoie réellement ?

ssh -v host affiche une ligne debug1: Offering public key: pour chaque clé. Chaque ligne indique le fichier source et une empreinte SHA256. ssh-add -l liste les empreintes détenues par l’agent. ssh-keygen -lf ~/.ssh/id_ed25519.pub affiche l’empreinte d’un fichier de clé donné, et ssh-keygen -y -f ~/.ssh/id_ed25519 affiche la clé publique réellement dérivée d’une clé privée. Pour que la connexion réussisse, l’empreinte de la ligne Offering doit également apparaître dans le résultat de ssh-keygen -lf exécuté sur le authorized_keys du serveur.

Pourquoi sshd ignore-t-il mon fichier authorized_keys ?

Parce que StrictModes est activé par défaut, et que le fichier, le répertoire .ssh ou le répertoire personnel est accessible en écriture par le groupe ou par tout le monde, ou appartient au mauvais compte. sshd ne fait pas confiance à un chemin qu’une autre personne peut modifier. Il se comporte donc comme si aucune clé n’existait. Définissez les permissions du répertoire personnel sur 755 ou plus restrictives, celles de .ssh sur 700, et celles de authorized_keys sur 600. Les trois éléments doivent appartenir au compte utilisé pour la connexion. Avec LogLevel VERBOSE, le serveur journalise Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Ma clé ne fonctionne plus depuis la mise à niveau du serveur. Qu’est-ce qui a changé ?

S’il s’agit d’une clé RSA, il s’agit très probablement du changement concernant SHA-1. OpenSSH 8.8 a désactivé par défaut les signatures SHA-1 ssh-rsa. Une clé qui ne peut signer qu’avec cette méthode est donc désormais refusée. La sortie détaillée du client affiche debug1: send_pubkey_test: no mutual signature algorithm. Générez une clé moderne avec ssh-keygen -t ed25519 et installez son fichier .pub. Si vous devez rétablir l’accès immédiatement, PubkeyAcceptedAlgorithms +ssh-rsa sur le serveur réactive les anciennes signatures. Supprimez cette ligne dès que la nouvelle clé fonctionne.

J’ai modifié sshd_config et je ne peux plus du tout me connecter. Comment rétablir l’accès ?

Utilisez la console de votre fournisseur. Elle ne passe pas par SSH. Connectez-vous avec un mot de passe local, exécutez sudo sshd -t pour afficher l’erreur de syntaxe et son numéro de ligne, annulez la modification, puis redémarrez le service. Vérifiez ensuite sudo sshd -T pour confirmer les valeurs appliquées, car un fichier dans /etc/ssh/sshd_config.d/ peut remplacer la configuration principale. Si vous n’avez pas de mot de passe local, réinitialisez d’abord le mot de passe root depuis la console, puis corrigez le fichier.