Corriger « Permission denied (publickey) » en 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 actif : le refus se produit lors de la dernière étape de l’authentification. Si votre session s’interrompt avant cette étape, vous êtes face à un refus de connexion ou un délai d’attente dépassé, ce qui correspond à un autre diagnostic et à d’autres tests. La correction ne repose jamais sur des suppositions, car ssh -v indique laquelle des cinq causes est en jeu.

Les termes 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 prendre le relais. Permission denied (publickey,password) signifie que les mots de passe étaient proposés, mais que ces tentatives ont également échoué.

Un même message couvre cinq problèmes distincts, et son manque de précision est volontaire. Un serveur qui répondrait « utilisateur inexistant » ou « cette clé n’est pas installée » aiderait quiconque cherche des comptes valides. Ne commencez donc pas par remplacer les clés ou modifier les 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

Voici à quoi ressemble une sortie abrégée mais réaliste :

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éduit 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 ne figure pas dans 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: ... affiche une ligne par clé réellement envoyée par votre client, avec 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 aucune ligne Offering public key pour la clé attendue. Le problème se trouve sur votre machine, car le serveur n’a jamais reçu votre clé.
• La clé est proposée et Authentications that can continue: publickey apparaît de nouveau. Le serveur a reçu cette clé et l’a refusée. Le problème se trouve donc sur le serveur.

Les causes ci-dessous sont classées selon la fréquence à laquelle elles expliquent le problème.

Cause 1: vous utilisez le mauvais nom d’utilisateur

La cause la plus fréquente est aussi la moins intéressante. sshd, le daemon 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 facilite le travail d’un attaquant. Une faute de frappe dans le nom d’utilisateur ressemble exactement à un problème de clé.

Vérifiez la ligne Authenticating to ... as avant toute autre chose. Si elle contient 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 fournissent généralement un compte ubuntu, les images Debian un compte debian ou admin, Rocky Linux et AlmaLinux fournissent 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 ce nom est prioritaire sur celui de votre compte 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 dans le nouveau 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 propose uniquement 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 matérielles et DSA de ces noms. Une clé enregistrée sous ~/.ssh/vps-prod est invisible pour ssh tant que vous ne la lui indiquez pas explicitement. C’est pourquoi la sortie détaillée n’affiche aucune ligne Offering public key correspondante.

Indiquez le fichier et empêchez les clés de l’agent de passer avant celui-ci :

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

-i seul ne suffit pas lorsque l’agent contient des clés, car ssh propose toujours les clés de l’agent en premier et le fichier indiqué en dernier. C’est important, car le serveur compte chaque clé refusée dans MaxAuthTries, dont la valeur par défaut est 6. Un agent contenant sept clés peut atteindre la limite avant que votre clé correcte ne soit proposée. Le message devient alors :

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

Si vous voyez plutôt ce message, le serveur a interrompu la session avant que votre clé correcte soit testée. Ce cas est traité dans trop d’échecs d’authentification. 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 videz-les avec ssh-add -D si celui-ci a accumulé plusieurs années d’anciennes clés. Enregistrez ensuite les paramètres afin que la prochaine connexion ne dépende pas de la mémorisation 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 voit 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. La section Notions de base sur la gestion des clés SSH explique où stocker les clés et quels noms leur attribuer.

Cause 3 : la clé publique n’est jamais arrivée dans authorized_keys

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

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 n’apparaît pas dans la liste, la clé n’est pas installée sur ce compte, quelles que soient vos actions 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 lue comme plusieurs entrées incorrectes et ne correspond à rien.
• La clé a été placée dans /root/.ssh/authorized_keys alors que vous vous connectez avec le compte deploy, ou l’inverse. Le fichier est propre à chaque compte. Il n’existe pas de fichier partagé.
• La boîte de dialogue « ajouter ma clé » du fournisseur l’a écrite uniquement pour l’utilisateur par défaut de l’image. Le compte créé ensuite possède donc un répertoire .ssh vide.

Pour ajouter une clé correctement depuis la console, en tant que root :

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 apparaître 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 valeur par défaut de sshd. Avec cette valeur, 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 son propriétaire. La raison est directe : si le groupe ou les autres utilisateurs peuvent écrire dans votre répertoire personnel, n’importe quel 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 enregistre la véritable raison :

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 accessible en écriture ni au groupe ni aux 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 situé dans /home/deploy/.ssh et 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 réattribuer au bon compte. Corrigez les deux éléments en une seule 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 défini sur .ssh. Si ces chaînes ne sont pas encore claires, 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 un chemin inhabituel peut avoir la mauvaise étiquette de fichier. sshd se voit alors refuser l’accès en lecture, même si les modes semblent corrects. sudo restorecon -Rv /home/deploy/.ssh rétablit les étiquettes, et sudo ausearch -m avc -ts recent indique si SELinux était le composant qui refusait l’accès.

Cause 5 : sshd est configuré pour vous refuser

Lire /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'

Une réponse correcte ressemble à ceci :

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

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

• pubkeyauthentication no. Aucune clé ne sera acceptée. Cette configuration 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. Votre fichier dans le répertoire personnel est alors complètement ignoré, et les règles de permissions de la cause 4 s’appliquent à ce nouvel emplacement.
• allowusers ou allowgroups est présent. Tout compte qui n’est pas listé est refusé avec exactement cette erreur, sans autre explication. denyusers et denygroups font l’inverse.
• permitrootlogin no est défini alors que 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 sortie sshd -T simple, car leur résultat dépend de l’identité du client. Demandez 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 aujourd’hui. Considérez donc ce réglage comme un moyen d’accéder au serveur, pas comme une solution définitive. Les autres paramètres côté serveur qu’il est utile de vérifier sont présentés dans renforcer la sécurité du serveur SSH sur un VPS.

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

La plupart des incertitudes liées à 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 la véritable clé associée à 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 confirme é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 dans ssh-keygen -lf sur le authorized_keys du serveur et l’empreinte dans le journal du serveur. L’endroit où elles cessent de correspondre indique votre erreur.

Lire le journal du serveur pendant l’échec de la connexion

Le client ne reçoit volontairement aucune information utile. Le serveur enregistre la véritable cause. Lancez le suivi du journal dans la session de console, puis exécutez la commande ssh qui échoue depuis votre ordinateur portable.

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 enregistre alors l’empreinte réellement reçue par le serveur :

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 donc les causes 3, 4 et 5. Si vous ne reconnaissez pas l’empreinte, votre client a envoyé une clé différente de celle prévue. Revenez donc à la cause 2.

Si le journal reste difficile à interpréter, lancez un deuxième sshd sur un autre port en mode debug. Il reste au premier plan, accepte une seule 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 pare-feu 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 identifié la cause. Le sshd réel sur le port 22 n’est pas modifié pendant toute l’opération.

Comment éviter de vous verrouiller hors du serveur

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

1. Ouvrez la console de votre fournisseur, via le port série ou VNC (virtual network computing), puis vérifiez que vous pouvez vous y connecter.
2. Vérifiez que vous connaissez un mot de passe local fonctionnel pour un compte disposant de 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 de récupérer l’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 et affiche le fichier ainsi que le numéro de ligne lorsqu’il ne l’est pas.
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 ne ferme pas les connexions existantes. La session dans laquelle vous travaillez 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 démarré depuis une socket unit ; une modification de Port ou ListenAddress nécessite donc aussi sudo systemctl restart ssh.socket pour prendre effet.

FAQ

Pourquoi est-ce que j’obtiens « Permission denied (publickey) » alors que la même clé fonctionne sur un autre serveur ?

Parce que la clé est correcte et que le problème se situe ailleurs. Exécutez ssh -v et recherchez la ligne Offering public key. Si votre clé n’y figure pas, ssh ne l’a jamais envoyée : le fichier n’est pas présent dans ~/.ssh sous un nom par défaut et la clé n’est pas chargée 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 fichier authorized_keys du compte, le chemin qui y mène est accessible en écriture au 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 la sortie 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 au groupe ou à tous les utilisateurs, 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 sur des permissions plus restrictives, .ssh sur 700 et authorized_keys sur 600. Les trois éléments doivent appartenir au compte utilisé pour la connexion. Avec LogLevel VERBOSE, le serveur enregistre Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Ma clé ne fonctionne plus juste après 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 désactive par défaut les signatures SHA-1 ssh-rsa. Une clé qui ne peut signer que de cette manière 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écupérer 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 me connecter du tout. 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 actives, car un fichier dans /etc/ssh/sshd_config.d/ peut remplacer les paramètres de 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.