SSH Permission denied (publickey): solusi yang sebenarnya

Pukul 02:10 sebuah deploy mati di baris yang sudah saya ketik seribu kali: ssh deploy@staging → Permission denied (publickey). Kuncinya benar. Penawaran-nya yang tidak.

TL;DR: Permission denied (publickey) berarti setiap kunci yang ditawarkan klien ditolak oleh server — putusan negosiasi, bukan salah ketik sandi. Diagnosis dengan ssh -vvv (kunci mana yang ditawarkan) dan log server journalctl -u ssh (kunci mana yang ditolak, dan mengapa). Lalu perbaiki salah satu dari empat penyebab: pengguna salah, kunci tidak ada di authorized_keys, izin terlalu terbuka, atau kunci ssh-rsa yang ditolak OpenSSH 8.8+. ssh-copy-id mencegah sebagian besar kekambuhan.

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

Pesan error adalah putusan, bukan petunjuk: semua yang ada dalam penawaran ditolak.

Mengapa SSH menampilkan “Permission denied (publickey)“?

Autentikasi kunci publik adalah negosiasi tawaran–penolakan. Klien menawarkan setiap kunci yang bisa ditemukannya — identitas dari agen Anda, dari ~/.ssh/config, nama berkas bawaan (id_ed25519, id_rsa), dan apa pun yang dilewatkan lewat -i. Server mencocokkan setiap tawaran dengan ~/.ssh/authorized_keys milik akun target. Ketika tidak ada yang cocok, dan autentikasi sandi dimatikan atau sudah habis, klien mencetak baris yang setiap insinyur devops hafal di luar kepala.

Dua fakta penting untuk debugging. Pertama, pesan itu tidak menyebut pengguna mana yang Anda tuju — separuh kasus adalah kunci yang benar-benar bagus sedang duduk di authorized_keys akun yang salah. Kedua, server sudah memberi tahu alasannya: sshd mencatat setiap tawaran yang ditolak. Stack trace yang tidak diminta siapa pun tapi dibutuhkan semua orang adalah -vvv.

Bagaimana melihat kunci mana yang benar-benar ditawarkan 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).

Baca tiga baris: Offering public key (apa yang ditawarkan klien), Authentications that can continue (apa yang masih diterima server — jika password tidak muncul, permintaan sandi tidak akan pernah datang) dan putusan akhir. Jika kunci Anda tidak pernah muncul dalam daftar tawaran, masalahnya di sisi klien: jalur -i yang salah, IdentityFile yang terlupa di ~/.ssh/config, atau agen (ssh-add -l) yang menjawab lebih dulu dengan identitas basi.

Apa saja empat penyebab sebenarnya?

Penyebab	Ciri	Perbaikan
Pengguna salah	Kunci berhasil untuk root@host, gagal untuk deploy@host	Kunci harus ada di ~/.ssh/authorized_keys pengguna itu
Kunci belum terpasang	Log server menampilkan Failed publickey untuk setiap tawaran	ssh-copy-id user@host
Izin terlalu terbuka	Klien: WARNING: UNPROTECTED PRIVATE KEY FILE — kunci dilewati, tak pernah ditawarkan	chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
Kunci ssh-rsa lama	Server memakai OpenSSH 8.8+; kunci RSA lama tidak pernah diterima	Buat ulang sebagai ed25519, atau tingkatkan kuncinya

Penyebab izin layak mendapat catatan tersendiri, karena OpenSSH menegakkannya dengan keras: kunci privat yang bisa dibaca grup atau orang lain ditolak oleh klien sendiri dan menghilang diam-diam dari penawaran. Perbaikannya dua perintah:

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

Penyebab ssh-rsa menjebak image CI lama dan Raspberry Pi: OpenSSH 8.8 (rilis 2021-10-01, openssh.com/txt/release-8.8) menonaktifkan tanda tangan ssh-rsa — varian berbasis SHA-1 — secara bawaan. Menurut catatan rilisnya, “the ssh-rsa signature scheme is … disabled by default”. Kunci RSA buatan 2018 tidak rusak; format tanda tangan-nya saja yang sudah tidak dipakai. Membuat kunci ed25519 (ssh-keygen -t ed25519) adalah jawaban yang tahan lama, dan konsol awan memberi Anda konsol serial untuk saat Anda mengunci diri sendiri di tengah perbaikan.

Jika sshd menolak menyala saat Anda sedang menyunting konfigurasinya, itu perburuan lain — lihat systemd service not starting.

Bagaimana melihat mengapa server menolak kunci tersebut?

Log sisi server adalah saksi yang jujur. Di Ubuntu (systemd), sshd mencatat putusan setiap tawaran:

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 dengan sidik jari yang tidak Anda duga berarti klien menawarkan kunci lain dari yang Anda kira — kembali ke -vvv. Failed publickey dengan sidik jari Anda berarti kuncinya benar tetapi belum terpasang untuk akun itu, atau izin home di sisi server salah (aturan 700/600 yang sama berlaku untuk ~/.ssh dan ~/.ssh/authorized_keys milik server).

Bagaimana memasang kunci saya dengan benar?

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

ssh-copy-id menambahkan kunci publik Anda ke authorized_keys akun target dengan izin yang wajar — perintah ini ada karena menempel manual ke authorized_keys gagal persis sering cukup: newline di akhir atau direktori yang tidak ada. Uji BatchMode adalah bukti sejatinya: semua prompt dimatikan, jadi sukses berarti kunci saja yang mengangkat login. Begitu kunci bekerja, scp dan rsync mewarisi autentikasi yang sama cuma-cuma — memilih di antara keduanya soal bandwidth, bukan kredensial (rsync vs scp).

Triase 30 detik

ssh -vvv user@host 2>&1 | grep -i offering      # 1. kunci apa yang ditawarkan?
journalctl -u ssh -n 50 | grep -i publickey     # 2. mengapa ditolak?
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. sudah 700 / 600?
ssh-copy-id user@host                           # 4. pasang, lalu verifikasi dengan BatchMode

Permission denied (publickey) adalah hasil negosiasi, bukan permintaan sandi — server menolak setiap kunci dalam penawaran, dan lognya sudah tahu mengapa.

Jalankan empat perintah itu berurutan dan kegagalan berhenti jadi misteri: salah satunya selalu menyebut pelakunya. Punya saya adalah identitas agen basi yang menjawab sebelum kunci yang benar — ssh-add -d, dan deploy kembali hijau pukul 02:31.