■ space · le câble, rejoué · fig 1

■ la réponse d'abord

Permission denied (publickey) = toutes les clés offertes par le client ont été refusées — un verdict de négociation, pas une faute de frappe de mot de passe.

Diagnostic : ssh -vvv montre quelles clés ont été offertes ; journalctl -u ssh montre pourquoi elles ont été refusées.

Ensuite, c'est l'une des quatre causes : mauvais utilisateur, clé absente d'authorized_keys, permissions trop ouvertes, ou ssh-rsa refusé par OpenSSH 8.8+. ssh-copy-id prévient la plupart des récurrences.

4causes derrière un verdict

8.8premier OpenSSH à refuser ssh-rsa

02:10l'offre qui est morte

01LE CÂBLE

le client propose · le serveur refuse · trois lignes décident du côté où vit votre problème

FIG 1 · LE CONVOYEUR À PORTE-CLÉSclés 1–6 — ou les boutons

rejouez-le depuis le terminal

$ ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
debug1: Offering public key: /home/deploy/.ssh/id_rsa RSA SHA256:9T4xQmV…

02:10:03 — REFUSÉ. LE DÉPLOIEMENT EST MORT SUR SSH-RSA02:14:41 — le même client, accepté en ed25519

OFFRE id_rsa → REFUSÉE · OFFRE id_ed25519 → ACCEPTÉE · REGISTRE 1R · 1A

le tapis, c'est la liste des offres — chaque tampon que l'anneau prend, ssh -vvv s'imprime en une ligne

02LE TÉMOIN

l'anneau garde le décompte — le serveur a gardé le sien d'abord : journalctl a déjà journalisé chaque verdict

staging · le journal de sshd lui-même

Oct 18 02:10:03 staging sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:9T4xQmV…
Oct 18 02:14:41 staging sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:KP7wLn…

deux lignes, un arc : l'offre RSA refusée à 02:10 — la mort du déploiement — puis le même client, quatre minutes plus tard, accepté en ed25519

pourquoi ce fut refusé — sur Ubuntu, sshd journalise chaque verdict d'offre

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"

vérification : journalctl -u ssh -n 50 | grep Accepted → une ligne avec VOTRE empreinte et votre utilisateur

03LA TABLE DES CAUSES

le journal nomme le verdict, jamais la cause — six formes produisent un refus

cause	signe révélateur	correctif
La bonne clé existe, la mauvaise arrive	`-vvv` offre une identité que vous ne reconnaissez pas	`ssh-add -l` pour lister, `ssh-add -d` pour lâcher la périmée
`-i mykey` ignoré	Un IdentityFile de config écrase l'ordre des offres	Réparez ou retirez le bloc `~/.ssh/config`
Clé non installée	Le log du serveur affiche `Failed publickey` pour chaque offre — authorized_keys : vide, 0 clés	`ssh-copy-id user@host`
Mauvais utilisateur	La clé marche pour `root@host`, échoue pour `deploy@host`	La clé doit figurer dans `~/.ssh/authorized_keys`
Permissions trop ouvertes	`WARNING: UNPROTECTED PRIVATE KEY FILE` — la clé est écartée, jamais offerte	`chmod 700 ~/.ssh; chmod 600 ~/.ssh/*`
Clé ssh-rsa héritée	Le serveur tourne sur OpenSSH 8.8+ ; la vieille clé RSA jamais acceptée	Régénérez en ed25519, ou mettez la clé à niveau

chaque ligne se rejoue sur le câble — appuyez sur sa clé sur le convoyeur et regardez la négociation choisir cette cause

RÈGLE 01Trois lignes décident du camp. Offerte · encore acceptée · refusée — lisez-les dans l'ordre et le câble vous dit où vous placer.

RÈGLE 02ssh-copy-id, jamais le copier-coller à la main. Lignes partielles et permissions trop lâches, c'est comme ça que naît la récurrence.

RÈGLE 03BatchMode est la preuve. ssh -o BatchMode=yes … 'echo ok' — pas d'invite, pas d'espoir, juste ok.

04LE BARRAGE DES PERMISSIONS

chaque cause de la table a atteint le lecteur — celle-ci meurt du côté client du câble

~/.ssh— le répertoire, ls -ld700 → drwx------ · 755, c'est trop ouvert

~/.ssh/id_ed25519— la clé privée, ls -l600 → -rw------- · 644, et 664 sont trop ouvertes

■ le client refuse votre propre clé à votre place WARNING: UNPROTECTED PRIVATE KEY FILE. une clé lisible par le groupe ou par tous est discrètement écartée de l'offre — rien n'atteint le serveur ; le log -vvv ne montre aucune ligne offering

le correctif — deux chmod, dans l'ordre

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*

vérification : ls -ld ~/.ssh → drwx------ · ls -l ~/.ssh/id_ed25519 → -rw-------

05LA LANGUE RETRAITÉE

un refus porte une date — 8.8, sorti le 2021-10-01, a arrêté de parler ssh-rsa

« le schéma de signature ssh-rsa est ... désactivé par défaut » — notes de publication d'OpenSSH 8.8, 2021-10-01.

une clé RSA générée en 2018 n'est pas cassée — son format de signature n'est simplement plus parlé

la réponse qui dure—ssh-keygen -t ed25519 — une clé neuve dans la langue que tous les serveurs parlent encore

la même clé, surclassée—rsa-sha2-256 n'exige pas de régénération — la signature se surclasse sur place

l'installation—ssh-copy-id ajoute la clé et pose des permissions saines — il existe parce que le collage à la main échoue sur les lignes partielles

frappez la clé, installez-la

ssh-keygen -t ed25519
ssh-copy-id deploy@staging

la preuve — pas d'invite, pas d'espoir

$ ssh -o BatchMode=yes deploy@staging 'echo ok'
ok

vérification : ssh -o BatchMode=yes deploy@staging 'echo ok' → ok, sans invite

LA CLAUSE DU BLOCAGE Peur de vous enfermer dehors en pleine réparation ? Les consoles cloud vous donnent une console série qui ne dépend pas de sshd — tous les fournisseurs de VPS en ont une. si l'authentification par mot de passe est déjà désactivée et que votre correctif touche authorized_keys, gardez cette console ouverte avant de redémarrer quoi que ce soit

■ cachet d'honnêteté Testé sur : OpenSSH 8.8 → 9.x · Ubuntu · clés ed25519 + RSA · ssh-agent. Première publication 2026-09-18. La mécanique offre-et-refus, le refus UNPROTECTED PRIVATE KEY et la valeur par défaut ssh-rsa de 8.8 sont le comportement documenté d'OpenSSH ; les lignes -vvv et journalctl ci-dessus sont les formes exactes que ces outils impriment, tapées depuis des déploiements morts à 02:10 et revenus à la vie.

fin du câble · rien de fetché · tout est local