SSH Permission Denied (publickey): Ang Totoong Fix

Sa 02:10, namatay ang isang deploy sa linyang na-type ko na ng libong beses: ssh deploy@staging → Permission denied (publickey). Ayos ang key. Ang alok ang hindi.

TL;DR: ang Permission denied (publickey) ay nangangahulugang tinanggihan ng server ang bawat key na inalok ng client — hatol sa negosasyon, hindi maling password. I-diagnose gamit ang ssh -vvv (aling mga key ang inalok) at ang server log na journalctl -u ssh (aling mga key ang tinanggihan, at bakit). Tapos ayusin ang isa sa apat na sanhi: maling user, kulang ang key sa authorized_keys, masyadong bukas ang permissions, o ssh-rsa key na tinanggihan ng OpenSSH 8.8+. Pinipigilan ng ssh-copy-id ang karamihan ng pag-uulit.

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

Ang error ay hatol, hindi pahiwatig: lahat sa alok ay tinanggihan.

Bakit sinasabi ng SSH na “Permission denied (publickey)“?

Ang public-key auth ay negosasyon ng alok-at-tanggihan. Iminumungkahi ng client ang bawat key na mahahanap nito — mga identity mula sa agent mo, ang ~/.ssh/config mo, mga default filename (id_ed25519, id_rsa) at anumang ipinasa gamit ang -i. Tinitingnan ng server ang bawat alok laban sa ~/.ssh/authorized_keys ng target account. Kapag walang tumugma, at naka-disable o ubos na ang password auth, nililimbag ng client ang iisang linyang kabisado ng bawat devops engineer.

Dalawang bagay ang mahalaga sa pag-debug. Una, hindi sinasabi ng mensahe kung aling user ang tinamaan mo — kalahati ng lahat ng kaso ay perpektong mabuting key na nakaupo sa authorized_keys ng maling account. Ikalawa, sinabi na ng server kung bakit: naka-log ng sshd ang bawat tinanggihang alok. Ang client-side stack trace na walang humingi at kailangan ng lahat ay -vvv.

Paano ko makikita kung aling key ang talagang inaalok ng SSH?

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

Basahin ang tatlong linya: Offering public key (ano ang iminungkahi ng client), Authentications that can continue (ano pa ang tatanggapin ng server — kapag wala ang password, hindi kailanman darating ang password prompt), at ang panghuling hatol. Kapag hindi kailanman lumitaw ang inaasam mong key sa offer list, client-side ang problema: maling -i path, isang IdentityFile sa ~/.ssh/config na nakalimutan mo, o isang agent (ssh-add -l) na humahawak ng lumang identity na una pang sumasagot.

Ano ang apat na totoong sanhi?

Sanhi	Sintomas	Fix
Maling user	Gumagana ang key sa root@host, bumibigo sa deploy@host	Dapat nasa ~/.ssh/authorized_keys ng iyon na user ang key
Hindi naka-install ang key	Ipinapakita ng server log ang Failed publickey sa bawat alok	ssh-copy-id user@host
Masyadong bukas ang permissions	Client: WARNING: UNPROTECTED PRIVATE KEY FILE — nilalaktawan ang key, hindi kailanman inaalok	chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
Lumang ssh-rsa key	OpenSSH 8.8+ ang server; hindi kailanman tinatanggap ang lumang RSA key	Muling buohin bilang ed25519, o i-upgrade ang key

Karapat-dapat sa sariling tala ang sanhi ng permissions dahil ipinatutupad ito nang mahigpit ng OpenSSH: ang private key na mababasa ng group o ng iba ay tinatanggihan ng mismong client at tahimik na lumalagas sa alok. Dalawang command ang fix:

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

Nadadaya ang mga lumang CI image at Raspberry Pi ng sanhi ng ssh-rsa: hindi pinagana ng OpenSSH 8.8 (inilabas 2021-10-01, openssh.com/txt/release-8.8) ang mga ssh-rsa signature — ang barayant na batay sa SHA-1 — bilang default. Ayon sa release notes, “the ssh-rsa signature scheme is … disabled by default”. Hindi sira ang RSA key na ginawa noong 2018; ang signature format nito lang ang hindi na kinasasalitaan. Ang paggawa ng ed25519 key (ssh-keygen -t ed25519) ang matibay na sagot, at may serial console ang mga cloud console kapag naisara mo ang sarili sa gitna ng fix.

Paano ko makikita kung bakit tinanggihan ng server ang key?

Ang server-side log ang tapat na saksi. Sa Ubuntu (systemd), naka-log sa sshd ang hatol kada alok:

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

Ang Failed publickey na may fingerprint na hindi mo inaasahan ay nangangahulugang ibang key ang inalok ng client kaysa inakala mo — balik sa -vvv. Ang Failed publickey na may iyong fingerprint ay nangangahulugang tama ang key pero hindi naka-install para sa account na iyon, o mali ang home-directory permissions sa gawi ng server (parehong 700/600 rule ang naaangkop sa ~/.ssh at ~/.ssh/authorized_keys ng server). Kapag tumatangging magsimula ang sshd habang nag-eedit ka ng configs, iba ang paghahunting iyon — tingnan ang hindi mag-start ang systemd service.

Paano ko ii-install nang tama ang key ko?

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

Idinaragdag ng ssh-copy-id ang public key mo sa authorized_keys ng target account at nagtatakda ng makatwirang permissions — umiiral ito dahil eksaktong sapat na madalas bumigo ang mano-manong pag-paste sa authorized_keys sa isang trailing newline o kulang na directory. Ang totoong test ay ang BatchMode check: hindi nito pinapagana ang lahat ng prompt, kaya ang tagumpay ay nangangahulugang ang key lang ang nagdala ng login. Kapag gumana na ang key, minamana nang libre ng scp at rsync ang parehong auth — bandwidth ang pagpipilian sa pagitan nila, hindi credentials (rsync vs scp).

Ang 30-segundong triage

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

Resulta ng negosasyon ang Permission denied (publickey), hindi password prompt — tinanggihan ng server ang bawat key sa alok, at alam na ng log nito kung bakit.

I-run ang apat na command sa ayos at titigil na ang pagiging misteryo ng bigo: isa sa mga ito ang pangangalan sa salarin sa bawat pagkakataon. Akin ay lumang agent identity na una pang sumagot kaysa tamang key — ssh-add -d, at naging berde ang deploy sa 02:31.