SSH Permission denied (publickey) : le vrai correctif

À 02:10, un déploiement est mort sur une ligne que j’ai tapée mille fois : ssh deploy@staging → Permission denied (publickey). La clé était bonne. C’est l’offre qui ne l’était pas.

TL;DR : Permission denied (publickey) signifie que chaque clé proposée par le client a été refusée par le serveur — un verdict de négociation, pas une faute de mot de passe. Diagnostiquez avec ssh -vvv (quelles clés ont été proposées) et le log serveur journalctl -u ssh (quelles clés ont été refusées, et pourquoi). Corrigez ensuite l’une des quatre causes : mauvais utilisateur, clé absente des authorized_keys, permissions trop ouvertes, ou clé ssh-rsa refusée par OpenSSH 8.8+. ssh-copy-id évite la plupart des récidives.

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

L’erreur est un verdict, pas un indice : tout ce qui était dans l’offre a été refusé.

Pourquoi SSH affiche « Permission denied (publickey) » ?

L’authentification par clé publique est une négociation du type offre-refus. Le client propose toutes les clés qu’il trouve — identités de votre agent, votre ~/.ssh/config, noms de fichiers par défaut (id_ed25519, id_rsa) et tout ce qui passe par -i. Le serveur compare chaque offre aux ~/.ssh/authorized_keys du compte ciblé. Quand rien ne correspond, et que l’authentification par mot de passe est désactivée ou déjà épuisée, le client affiche la ligne que tout ingénieur devops sait par cœur.

Deux faits comptent pour le débogage. D’abord, le message ne dit pas quel utilisateur vous avez visé — la moitié des cas, c’est une clé parfaitement valide rangée dans les authorized_keys du mauvais compte. Ensuite, le serveur vous a déjà dit pourquoi : sshd journalise chaque offre refusée. La pile d’appels que personne ne demande et que tout le monde nécessite, c’est -vvv.

Comment voir quelle clé SSH propose réellement ?

ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
# debug1: Offering public key: /home/you/.ssh/id_ed25519 RSA-SHA256 (explicit)
# debug1: Authentications that can continue: publickey
# deploy@staging: Permission denied (publickey).

Lisez trois lignes : Offering public key (ce que le client a proposé), Authentications that can continue (ce que le serveur accepte encore — si password est absent, aucune invite de mot de passe n’arrivera jamais) et le verdict final. Si la clé visée n’apparaît jamais dans la liste, le problème est côté client : mauvais chemin -i, un IdentityFile oublié dans ~/.ssh/config, ou un agent (ssh-add -l) qui répond en premier avec une identité périmée.

Quelles sont les quatre vraies causes ?

Cause	Signature	Correctif
Mauvais utilisateur	La clé marche pour root@host, échoue pour deploy@host	La clé doit être dans les ~/.ssh/authorized_keys de cet utilisateur
Clé non installée	Le log serveur affiche Failed publickey pour chaque offre	ssh-copy-id user@host
Permissions trop ouvertes	Client : WARNING: UNPROTECTED PRIVATE KEY FILE — la clé est écartée, jamais proposée	chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
Clé ssh-rsa héritée	Serveur sous OpenSSH 8.8+ ; ancienne clé RSA jamais acceptée	Régénérer en ed25519, ou mettre la clé à niveau

La cause « permissions » mérite sa propre note, car OpenSSH l’applique strictement : une clé privée lisible par le groupe ou les autres est refusée par le client lui-même et sort silencieusement de l’offre. Le correctif tient en deux commandes :

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

La cause ssh-rsa piège les vieilles images CI et les Raspberry Pi : OpenSSH 8.8 (publiée le 2021-10-01, openssh.com/txt/release-8.8) a désactivé par défaut les signatures ssh-rsa — la variante SHA-1. Selon les notes de version, “the ssh-rsa signature scheme is … disabled by default”. Une clé RSA générée en 2018 n’est pas cassée ; c’est son format de signature qu’on ne parle plus. Générer une clé ed25519 (ssh-keygen -t ed25519) est la réponse durable, et les consoles cloud offrent une console série quand on se verrouille dehors en pleine correction.

Comment voir pourquoi le serveur a refusé la clé ?

Le log côté serveur est le témoin honnête. Sur Ubuntu (systemd), sshd journalise le verdict de chaque offre :

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"
# sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:...
# sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:...

Un Failed publickey avec une empreinte inattendue signifie que le client a proposé une autre clé que celle que vous croyiez — retour au -vvv. Un Failed publickey avec votre empreinte signifie que la clé est bonne mais pas installée pour ce compte, ou que les permissions du home côté serveur sont fausses (la même règle 700/600 vaut pour le ~/.ssh et le ~/.ssh/authorized_keys du serveur). Si sshd refuse de démarrer pendant que vous éditez sa configuration, c’est une autre chasse — voir systemd service not starting.

Comment installer ma clé correctement ?

ssh-copy-id deploy@staging
# Number of key(s) added: 1
ssh -o BatchMode=yes deploy@staging 'echo ok'   # preuve non interactive

ssh-copy-id ajoute votre clé publique aux authorized_keys du compte cible avec des permissions saines — cette commande existe parce que le copier-coller manuel dans authorized_keys échoue juste assez souvent, sur un saut de ligne final ou un dossier manquant. Le test BatchMode est la vraie preuve : il désactive toutes les invites, donc un succès signifie que la clé seule a porté le login. Une fois la clé en place, scp et rsync héritent de la même authentification — le choix entre eux est une question de bande passante, pas d’identifiants (rsync vs scp).

Le triage en 30 secondes

ssh -vvv user@host 2>&1 | grep -i offering      # 1. quelles clés proposées ?
journalctl -u ssh -n 50 | grep -i publickey     # 2. pourquoi refusées ?
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. 700 / 600 ?
ssh-copy-id user@host                           # 4. installer, puis vérifier avec BatchMode

Permission denied (publickey) est un résultat de négociation, pas une invite de mot de passe — le serveur a refusé chaque clé de l’offre, et son log sait déjà pourquoi.

Les quatre commandes dans l’ordre et la panne cesse d’être mystérieuse : l’une d’elles nomme le coupable à chaque fois. La mienne, c’était une identité d’agent périmée qui répondait avant la bonne clé — ssh-add -d, et le déploiement est repassé au vert à 02:31.