SSH Permission denied (publickey): de echte fix

Om 02:10 stierf een deploy op een regel die ik duizend keer heb getypt: ssh deploy@staging → Permission denied (publickey). De key was prima. Het aanbod niet.

TL;DR: Permission denied (publickey) betekent dat elke key die de client aanbood door de server geweigerd werd — een onderhandelingsuitslag, geen wachtwoordtypfout. Diagnose met ssh -vvv (welke keys werden aangeboden) en het serverlog journalctl -u ssh (welke keys geweigerd, en waarom). Fix dan één van de vier oorzaken: verkeerde user, key ontbreekt in authorized_keys, permissies te ruim, of een ssh-rsa-key geweigerd door OpenSSH 8.8+. ssh-copy-id voorkomt de meeste herhalingen.

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

De fout is een uitslag, geen hint: alles in het aanbod werd geweigerd.

Waarom zegt SSH ‘Permission denied (publickey)‘?

Publickey-auth is een aanbied-en-weiger-onderhandeling. De client biedt elke key aan die hij kan vinden — identiteiten van je agent, je ~/.ssh/config, standaardbestandsnamen (id_ed25519, id_rsa) en alles wat met -i meegegeven wordt. De server checkt elk aanbod tegen de ~/.ssh/authorized_keys van het doelaccount. Matcht niets, en is password-auth uitgezet of al uitgeput, dan print de client de ene regel die elke devops-engineer uit het hoofd kent.

Twee feiten tellen bij het debuggen. Eén: de boodschap zegt niet welke user je trof — de helft van alle gevallen is een prima key in de authorized_keys van het verkeerde account. Twee: de server zei het je al — sshd logt elke geweigerde aanbieding. De client-side stack trace die niemand vroeg en iedereen nodig heeft, is -vvv.

Hoe vind ik welke key SSH echt aanbiedt?

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).

Lees drie regels: Offering public key (wat de client voorstelde), Authentications that can continue (wat de server nog accepteert — ontbreekt password, dan komt er nooit een wachtwoordprompt) en de einduitslag. Staat je bedoelde key nooit in de aanbiedlijst, dan zit het probleem aan de clientkant: verkeerd -i-pad, een IdentityFile in ~/.ssh/config die je vergat, of een agent (ssh-add -l) met een verouderde identiteit die eerst antwoordt.

Wat zijn de vier echte oorzaken?

Oorzaak	Kenmerk	Fix
Verkeerde user	Key werkt voor root@host, faalt voor deploy@host	Key moet in de ~/.ssh/authorized_keys van die user
Key niet geïnstalleerd	Serverlog toont Failed publickey bij elk aanbod	ssh-copy-id user@host
Permissies te ruim	Client: WARNING: UNPROTECTED PRIVATE KEY FILE — de key wordt overgeslagen, nooit aangeboden	chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
Legacy ssh-rsa-key	Server draait OpenSSH 8.8+; oude RSA-key nooit geaccepteerd	Opnieuw genereren als ed25519, of de key upgraden

De permissieoorzaak verdient een eigen noot, want OpenSSH handhaaft hem hard: een private key die groep of wereld kan lezen, wordt door de client zelf geweigerd en valt stilletjes uit het aanbod. De fix is twee commando’s:

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

De ssh-rsa-oorzaak raakt oudere CI-images en Raspberry Pis: OpenSSH 8.8 (uitgebracht 2021-10-01, openssh.com/txt/release-8.8) zette ssh-rsa-handtekeningen — de SHA-1-variant — standaard uit. Volgens de release notes: ‘the ssh-rsa signature scheme is … disabled by default’. Een RSA-key uit 2018 is niet kapot; zijn handtekeningformaat wordt gewoon niet meer gesproken. Een ed25519-key genereren (ssh-keygen -t ed25519) is het duurzame antwoord, en cloudconsoles geven je een seriële console als je jezelf midden in de fix buitensluit.

Hoe zie ik waarom de server de key weigerde?

Het serverlog is de eerlijke getuige. Op Ubuntu (systemd) logt sshd per-aanbieding-uitslagen:

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:...

Failed publickey met een fingerprint die je niet verwachtte, betekent dat de client een andere key aanbood dan je dacht — terug naar -vvv. Failed publickey met jouw fingerprint betekent dat de key klopt maar niet voor dat account geïnstalleerd is, of dat de home-directory-permissies aan de serverkant fout zitten (zelfde 700/600-regel geldt voor de ~/.ssh en ~/.ssh/authorized_keys van de server). Start sshd niet terwijl je configs bewerkt, dan is dat een andere jacht — zie systemd-service start niet.

Hoe installeer ik mijn key correct?

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

ssh-copy-id plakt je public key aan de authorized_keys van het doelaccount en zet zinnige permissies — het bestaat omdat handmatig plakken in authorized_keys net vaak genoeg faalt op een afsluitende newline of een ontbrekende map. De BatchMode-check is de echte test: hij zet alle prompts uit, dus succes betekent dat de key alleen de login droeg. Werkt de key eenmaal, dan erven scp en rsync dezelfde auth gratis — de keuze tussen hen is bandbreedte, geen credentials (rsync vs scp).

De triage van 30 seconden

ssh -vvv user@host 2>&1 | grep -i offering      # 1. which keys were offered?
journalctl -u ssh -n 50 | grep -i publickey     # 2. why were they refused?
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. 700 / 600?
ssh-copy-id user@host                           # 4. install, then verify with BatchMode

Permission denied (publickey) is een onderhandelingsuitslag, geen wachtwoordprompt — de server weigerde elke key in het aanbod, en zijn log weet al waarom.

Draai de vier commando’s op volgorde en de faling is niet meer mysterieus: één benoemt elke keer de boosdoener. De mijne was een verouderde agent-identiteit die vóór de juiste key antwoordde — ssh-add -d, en de deploy werd groen om 02:31.