Cara Mengatasi "Permission denied (publickey)" saat Git Push

Sedang asyik push commit ke GitHub, tiba-tiba terminal memuntahkan ini:

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.

Kamu pastikan URL remote benar, coba ulang — tetap sama. Bingung harus mulai dari mana karena pesan error-nya terasa ambigu. Apakah key-nya salah? Apakah akunmu kehilangan akses? Atau ada sesuatu yang salah di sisi lokal?

Kabar baiknya: error ini punya diagnosis yang sangat sistematis. Menurut dokumentasi resmi GitHub, "Permission denied (publickey)" artinya server GitHub menolak koneksi SSH karena tidak bisa mengautentikasi kamu lewat public key. Ini bukan error kredensial HTTPS — jadi buang jauh-jauh ide untuk membuat Personal Access Token. Error HTTPS punya pesan berbeda, biasanya berupa "could not read Username" atau permintaan password.

Artikel ini memandu kamu melalui diagnosis berurutan — mulai dari tes koneksi paling dasar sampai ke penyebab-penyebab spesifik lintas OS. Tidak perlu tebak-tebakan. Setiap langkah memberikan data yang mengarah ke solusi yang tepat. Kalau kamu butuh panduan lengkap setup SSH key dari awal, bisa merujuk ke artikel tentang setup SSH key di Windows. Di sini fokusnya: mengapa error muncul dan cara memperbaikinya.

Memahami Error "Permission denied (publickey)"

Sebelum membahas solusi, penting untuk memahami apa yang sebenarnya terjadi saat error ini muncul.

Apa Arti Error Ini

Saat kamu menjalankan git push dengan remote URL berprotokol SSH (format git@github.com:user/repo.git), Git membuka koneksi SSH ke server GitHub di port 22. Server lalu meminta bukti identitas — yaitu public key yang sudah kamu daftarkan di akun GitHub harus cocok dengan private key di komputer lokal kamu.

Kalau tidak cocok — misalnya public key belum terdaftar, atau private key yang dipakai bukan pasangan dari public key yang terdaftar — server menolak. Dan pesan yang kamu lihat adalah "Permission denied (publickey)".

Perintah ini juga bisa muncul saat git pull dan git clone, bukan hanya push. Yang membedakan adalah protokolnya: selama kamu pakai SSH, error ini bisa muncul kapan saja.

Pesan Error Lengkap

Pesan error yang paling umum terlihat seperti ini:

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.

Dua baris terakhir — "Could not read from remote repository" dan "correct access rights" — sebenarnya hanya lanjutan dari error autentikasi pertama. Mereka muncul karena gagalnya koneksi di tahap autentikasi, bukan karena masalah hak akses secara terpisah.

Kalau kamu melihat pesan seperti "could not read Username for 'https://github.com'" atau permintaan password, itu error HTTPS, bukan SSH. Solusinya berbeda: kamu perlu Personal Access Token, bukan SSH key. Cek URL remote kamu dengan git remote -v untuk memastikan pakai protokol yang tepat.

Jangan Pakai `sudo` dengan Git

Satu jebakan yang sering luput: menggunakan sudo atau elevated privileges saat menjalankan Git. Kalau kamu generate SSH key tanpa sudo lalu menjalankan sudo git push, Git akan mencari key di konteks user root — yang pasti berbeda dari key yang kamu daftarkan di GitHub.

Dokumentasi resmi GitHub secara eksplisit menyarankan: jangan gunakan sudo atau elevated privileges dengan Git. Kalau kamu mengalami error ini setelah pakai sudo, coba jalankan ulang tanpa.

Diagnosis Sistematis: Urutan Cek yang Benar

Alih-alih langsung menebak penyebabnya, ikuti urutan diagnosis ini. Setiap langkah memberikan informasi yang menyempitkan kemungkinan.

Langkah 1 — Uji Koneksi Dasar

Perintah pertama dan paling informatif:

ssh -T git@github.com

Kalau koneksi berhasil, kamu akan melihat:

Hi USERNAME! You've successfully authenticated, but GitHub does not provide shell access.

Pastikan pesan ini memuat username kamu, bukan user lain. Exit code 1 di sini adalah normal — bukan error.

Kalau yang muncul adalah "Permission denied (publickey)", lanjut ke langkah berikutnya.

Langkah 2 — Uji Verbose

Jalankan versi verbose untuk mendapat detail di mana autentikasi gagal:

ssh -vT git@github.com

Perhatikan output yang ditampilkan. Beberapa baris kunci yang perlu dicari:

debug1: Connecting to github.com port 22. — artinya koneksi ke host benar di port default.
debug1: identity file /Users/YOU/.ssh/id_ed25519 type -1 — artinya SSH tidak menemukan file key tersebut. Type -1 berarti file tidak ada.
debug1: Offering RSA public key: /Users/YOU/.ssh/id_rsa — artinya file key ditemukan dan sedang ditawarkan ke server.
debug1: Authentications that can continue: publickey diikuti Permission denied (publickey). — artinya key yang ditawarkan ditolak server.

Kalau kamu melihat type -1, artinya file key tidak ditemukan di path yang diharapkan. Kalau key ditawarkan tapi ditolak, kemungkinan key yang dipakai berbeda dengan yang terdaftar di GitHub.

Langkah 3 — Cek Key yang Ter-load di Agent

ssh-add -l -E sha256

Perintah ini menampilkan fingerprint semua key yang sudah dimuat ke ssh-agent. Kalau output-nya kosong, berarti tidak ada key yang ter-load — agent mungkin sudah berjalan tapi key-nya belum ditambahkan, atau agent belum berjalan sama sekali.

Kalau ada output berupa fingerprint (deretan karakter SHA256), catat fingerprint-nya — nanti akan dicocokkan dengan key yang terdaftar di GitHub.

Catatan penting: di kebanyakan sistem, private key default (~/.ssh/id_rsa atau ~/.ssh/id_ed25519) secara otomatis ditambahkan ke agent. Jadi kalau kamu belum pernah menjalankan ssh-add secara manual tapi key default-nya ada, kemungkinan sudah ter-load.

Langkah 4 — Cek File Key dan Key Terdaftar di GitHub

Cek file key yang ada di komputer:

ls -al ~/.ssh

Pastikan ada file seperti id_ed25519.pub atau id_rsa.pub. Kalau tidak ada, berarti belum generate key sama sekali.

Kalau file sudah ada, sekarang cek apakah public key-nya terdaftar di akun GitHub. Buka GitHub, klik foto profil → Settings → bagian "Access" → SSH and GPG keys. Bandingkan fingerprint dari ssh-add -l -E sha256 dengan daftar key di halaman ini. Kalau key kamu tidak ada di daftar, itu penyebab error-nya.

Dari sini, diagnosis sudah cukup untuk mengidentifikasi penyebab. Mari bahas satu per satu.

Penyebab #1: Public Key Belum Terdaftar di GitHub

Ini penyebab paling umum. SSH key hanya bisa dipakai untuk autentikasi kalau public key-nya sudah didaftarkan di akun GitHub.

Cara Menambahkan Key

Buka GitHub → Settings → SSH and GPG keys → New SSH key.
Isi Title dengan label yang deskriptif — misalnya "Laptop pribadi" atau "PC kantor". Ini penting supaya mudah dikenali dan dicabut kalau perangkat hilang.
Paste isi public key ke kolom Key.

Cara menyalin public key ke clipboard tergantung OS:

Di Windows (Git Bash):

clip < ~/.ssh/id_ed25519.pub

Kalau error The '<' operator is reserved for future use, pakai alternatif ini:

cat ~/.ssh/id_ed25519.pub | clip

Di PowerShell:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | Set-Clipboard

Di macOS:

pbcopy < ~/.ssh/id_ed25519.pub

Di Linux:

cat ~/.ssh/id_ed25519.pub

Lalu copy output yang tampil secara manual. Pastikan tidak ada whitespace atau newline tambahan di awal/akhir — ini bisa merusak key.

Setelah ditambahkan, uji lagi dengan ssh -T git@github.com.

Peringatan Keamanan

Kalau kamu melihat SSH key di halaman GitHub Settings yang tidak kamu kenal, hapus segera dan hubungi GitHub Support. Bisa jadi ini indikasi masalah keamanan — seseorang mungkin telah menambahkan key-nya ke akunmu.

Penyebab #2: Salah User (git@github.com vs USERNAME@github.com)

Kesalahan sederhana tapi sangat umum: menggunakan username GitHub sendiri di URL SSH.

Dokumentasi resmi GitHub menegaskan: "All connections, including those for remote URLs, must be made as the 'git' user." Untuk github.com, user SSH selalu git — bukan username kamu.

Kalau kamu menjalankan:

ssh -T GITHUB-USERNAME@github.com

Hasilnya selalu gagal:

Permission denied (publickey).

Sedangkan yang benar adalah:

ssh -T git@github.com

Kalau URL remote di repository kamu memakai username pribadi, perbaiki dengan:

git remote set-url origin git@github.com:user/repo.git

Verifikasi dengan git remote -v untuk memastikan URL sudah benar. Artikel tentang mengganti remote repository membahas ini lebih lengkap.

Untuk hosting lain selain github.com, user SSH bisa berbeda — misalnya GitHub Enterprise di domain sendiri memakai octocorp@octocorp.ghe.com. Tapi untuk github.com, selalu pakai git.

Penyebab #3: Key Tidak Ter-load ke ssh-agent

ssh-agent adalah program yang "mengingat" key dan passphrase kamu selama sesi aktif, sehingga kamu tidak perlu memasukkan passphrase setiap kali push. Kalau agent berjalan tapi key belum di-load ke dalamnya, autentikasi akan gagal.

Cek Status Agent

Kalau ssh-add -l -E sha256 menghasilkan output kosong, berarti agent tidak punya key yang ter-load.

Menjalankan Agent di Linux/macOS

Di Linux dan macOS, ssh-agent dijalankan sebagai proses per-sesi:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

eval memulai agent di background dan mengekspor variabel lingkungan yang dibutuhkan. Setelah itu, ssh-add memuat key ke agent. Proses ini biasanya dijalankan otomatis saat login, tapi kalau tidak, kamu perlu menjalankannya manual.

Menjalankan Agent di Windows

Di Windows, ssh-agent bekerja secara fundamental berbeda — ini sumber kebingungan terbesar.

Di Linux, agent adalah proses sesi. Di Windows, agent adalah Windows system service bernama "OpenSSH Authentication Agent". Service ini tidak otomatis berjalan — default-nya Disabled atau Manual.

Buka PowerShell sebagai Administrator, lalu:

Get-Service -Name ssh-agent | Set-Service -StartupType Manual
Start-Service ssh-agent

Setelah service berjalan, di PowerShell biasa (tidak perlu admin lagi), tambahkan key:

ssh-add c:/Users/YOU/.ssh/id_ed25519

Ganti YOU dengan nama folder user kamu. Kalau diminta passphrase, masukkan.

Kalau kamu mencoba eval "$(ssh-agent -s)" di Git Bash tapi ssh-agent sudah berjalan sebagai service Windows, perintah ini bisa gagal. Untuk kasus Windows, lebih stabil pakai cara service seperti di atas. Penjelasan lengkap tentang setup ssh-agent di Windows ada di artikel SSH key untuk GitHub di Windows.

Penyebab #4: Multiple Key / Salah Key Ter-pilih

Kalau kamu punya beberapa akun GitHub — misalnya akun pribadi dan akun kantor — atau bekerja dari beberapa mesin, kamu mungkin punya lebih dari satu SSH key. Masalahnya: SSH secara default memilih key pertama yang ditemukan, yang belum tentu key yang benar untuk repository yang sedang kamu kerjakan.

Diagnosis

Jalankan ssh -vT git@github.com dan perhatikan baris yang menunjukkan key mana yang ditawarkan:

debug1: Offering public key: /Users/YOU/.ssh/id_ed25519 RSA

Kalau key yang ditawarkan berbeda dari yang terdaftar di akun GitHub untuk repository itu, autentikasi gagal.

Solusi: Host Alias di ~/.ssh/config

Gunakan Host alias agar setiap URL memakai key yang tepat. Misalnya untuk akun kantor:

Host github.com-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_kerja

Lalu clone atau push pakai URL dengan alias:

git clone git@github.com-work:perusahaan/proyek.git

Sedangkan untuk akun pribadi tetap pakai github.com biasa — atau bisa juga ditambahkan alias terpisah.

Untuk kasus macOS, kamu bisa menambahkan konfigurasi agar key otomatis dimuat ke agent dan passphrase tersimpan di keychain:

Host github.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

Konfigurasi ini memastikan key dimuat otomatis setiap kali kamu membuka terminal, tanpa perlu ssh-add manual.

Izin File Private Key (Linux/macOS)

Penyebab ini spesifik untuk Linux dan macOS, dan sering muncul tanpa diduga — terutama setelah kamu menyalin key dari satu mesin ke mesin lain.

Kenapa Permission Penting

OpenSSH menuntut izin file yang ketat pada private key. Kalau file ~/.ssh/id_ed25519 atau ~/.ssh/id_rsa memiliki izin yang terlalu longgar (misalnya world-readable), SSH akan menolak memakai key tersebut demi alasan keamanan.

Masalah ini sering terjadi saat:

Key di-copy dari Windows ke Linux/macOS (izin inherit dari sistem sumber).
Key di-restore dari backup yang tidak mempertahankan permission.
Permission berubah karena operasi tertentu seperti cp tanpa flag -p.

Perbaikan Izin

Jalankan perintah berikut di terminal:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Penjelasan:

700 pada folder .ssh — hanya owner yang bisa akses folder.
600 pada private key — hanya owner yang bisa baca dan tulis.
644 pada public key — boleh dibaca semua user (ini memang sifat public key).

Setelah memperbaiki izin, uji lagi dengan ssh -T git@github.com.

Jangan pernah menurunkan izin secara sembarangan (misalnya chmod 777) hanya agar SSH berfungsi. Itu tidak aman dan OpenSSH tetap menolaknya — jadi kamu justru mendapat dua masalah sekaligus.

Konflik Dua OpenSSH di Windows

Ini masalah yang paling membingungkan di Windows dan sering membuat developer bertanya-tanya: "Key sudah benar, sudah terdaftar, sudah di-load ke agent, tapi Git tetap gagal. Kenapa?"

Dua Implementasi OpenSSH

Di Windows bisa ada dua binary OpenSSH yang berjalan berdampingan:

OpenSSH bawaan Windows di C:\Windows\System32\OpenSSH\ssh.exe
OpenSSH milik Git for Windows (MSYS2) di C:\Program Files\Git\usr\bin\ssh.exe

Ketika kamu menjalankan ssh-add lewat PowerShell, key masuk ke service ssh-agent Windows. Tapi ketika Git menjalankan operasi push/pull, Git menggunakan ssh.exe miliknya sendiri (dari MSYS2) yang tidak terhubung ke service agent Windows. Hasilnya: Git tidak menemukan key, autentikasi gagal.

Solusi: core.sshCommand

Paksa Git menggunakan OpenSSH bawaan Windows dengan mengatur config global:

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"
git config --global gpg.ssh.program "C:/Windows/System32/OpenSSH/ssh-keygen.exe"

Setelah itu, Git akan menggunakan ssh.exe yang sama dengan yang terhubung ke service agent Windows. Uji push kembali.

Alternatif lain: saat install atau reinstall Git for Windows, pilih opsi "Use external OpenSSH" — ini mengatur path secara otomatis selama instalasi.

Penjelasan lebih detail tentang konflik ini dan cara kerja ssh-agent di Windows ada di artikel SSH key untuk GitHub di Windows.

Error Terkait dan Langkah Akhir

Beberapa error dan situasi yang berkaitan erat dengan "Permission denied (publickey)" tapi mungkin tidak langsung terlihat seperti itu.

Membedakan Error HTTPS vs SSH

Cara paling cepat membedakannya:

Pesan Error	Protokol	Solusi
`Permission denied (publickey).`	SSH	Perbaiki SSH key
`could not read Username for 'https://github.com'`	HTTPS	Pakai Personal Access Token
`Authentication failed for 'https://github.com'`	HTTPS	Perbarui PAT atau credential helper

Kalau pesan meminta Username atau Password, kamu sedang memakai HTTPS — bukan masalah publickey. Cek dengan git remote -v.

Verifikasi Fingerprint GitHub

Pertama kali terhubung ke GitHub lewat SSH, kamu akan melihat prompt kepercayaan host:

The authenticity of host 'github.com' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
Are you sure you want to continue connecting (yes/no)?

Verifikasi fingerprint di baris kedua cocok dengan fingerprint ED25519 GitHub yang resmi. Ketik yes hanya kalau fingerprint-nya benar. Ini langkah keamanan untuk mencegah serangan man-in-the-middle.

Generate Key Baru

Kalau semua pengecekan sudah benar tapi autentikasi tetap gagal — atau kalau key lama sudah dianggap kompromi atau passphrase-nya lupa — generate key baru:

ssh-keygen -t ed25519 -C "email@example.com"

Load ke agent:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Daftarkan public key baru di GitHub → Settings → SSH and GPG keys, lalu hapus key lama dari daftar yang sudah tidak dipakai.

Beralih Sementara ke HTTPS

Kalau SSH terus bermasalah dan kamu butuh push segera, beralih sementara ke HTTPS dengan Personal Access Token:

git remote set-url origin https://github.com/user/repo.git

Setelah remote diubah, push dan pull akan meminta PAT sebagai password. Ini solusi sementara yang memungkinkan workflow tetap berjalan sambil menyelesaikan masalah SSH.

SSH over Port 443

Kalau firewall memblokir port 22, kamu bisa SSH lewat port HTTPS (443):

ssh -T -p 443 git@ssh.github.com

Kalau berhasil, set permanen di ~/.ssh/config:

Host github.com
  Hostname ssh.github.com
  Port 443
  User git

Restart Agent Setelah Reboot

Khususnya di Windows, pastikan service ssh-agent berjalan setelah reboot. Kalau kamu sudah mengatur StartupType ke Automatic, service akan start sendiri. Kalau tidak, kamu perlu menjalankan Start-Service ssh-agent lagi di PowerShell admin setiap kali reboot.

Best Practices Keamanan

Beberapa kebiasaan yang menjaga SSH key tetap aman dan troubleshooting lebih mudah di masa depan.

Diagnosis berurutan, jangan tebak. Ikuti urutan ssh -T git@github.com → ssh -vT → ssh-add -l -E sha256 → ls -al ~/.ssh → cek GitHub Settings. Setiap langkah memberikan data, bukan opini. Ini menghemat waktu dan menghindari solusi yang salah.

Gunakan Ed25519 untuk key baru. RSA 4096 hanya untuk sistem legacy yang tidak mendukung Ed25519. GitHub sudah menghapus DSA dan mewajibkan SHA-2 untuk RSA baru.

Pahami perbedaan agent lintas OS. Linux/macOS menjalankan agent sebagai proses per-sesi yang biasanya otomatis. Windows menjalankannya sebagai sistem service yang tidak otomatis berjalan. Jangan biarkan kedua cara berjalan tanpa konfigurasi core.sshCommand.

Jaga izin file private key. chmod 600 pada private key di Linux/macOS. Jangan menurunkan izin sembarangan demi "membuat SSH jalan" — itu tidak aman dan tetap ditolak OpenSSH.

Rutin review key di GitHub. Cabut key yang tidak dikenal atau sudah tidak dipakai. GitHub juga otomatis menghapus key yang inactive selama sekitar 1 tahun. Kalau menemukan key asing, hapus segera dan hubungi GitHub Support.

Verifikasi fingerprint GitHub saat prompt pertama kali muncul. Jangan langsung ketik yes tanpa memeriksa — pastikan fingerprint-nya cocok dengan yang tercatat di dokumentasi GitHub.

Penutup

Error "Permission denied (publickey)" pada dasarnya satu hal: server GitHub menolak koneksi SSH karena tidak bisa membuktikan identitas kamu lewat key. Solusinya tidak perlu jadi tebakan — ikuti diagnosis berurutan dari ssh -T git@github.com sampai ke cek GitHub Settings, dan setiap langkah akan mengarahkan ke penyebab yang tepat.

Penyebab paling umum bisa diringkas: public key belum terdaftar, user salah (harus git, bukan username), key tidak ter-load ke ssh-agent, multiple key yang salah terpilih, izin file terlalu longgar di Linux/macOS, atau konflik dua OpenSSH di Windows.

Yang perlu diingat:

Selalu pakai git@github.com (ssh -T git@github.com), bukan username kamu.
Di Windows, ssh-agent adalah service yang perlu di-start manual — tidak seperti Linux yang otomatis.
chmod 600 pada private key di Linux/macOS, jangan pernah longgarkan demi "hack".
core.sshCommand di Windows menyelesaikan konflik dua OpenSSH.
Kalau semua sudah dicek tapi tetap gagal, generate key baru atau beralih ke HTTPS sementara.

Dengan diagnosis yang benar, error ini biasanya selesai dalam hitungan menit — bukan jam.

Error ini paling sering dialami saat menghubungkan project lokal ke GitHub atau setup SSH key untuk GitHub di Windows — keduanya sudah kita bahas terpisah. Sementara itu, cara mengganti remote repository juga sering jadi bagian dari perbaikan error ini. Jadi tiga artikel itu saling melengkapi kalau kamu ingin memahami alur SSH secara menyeluruh.

Untuk pendalaman, dokumentasi resmi adalah rujukan terbaik: Error: Permission denied (publickey), Testing your SSH connection, Generating a new SSH key and adding it to the ssh-agent, GitHub's SSH key fingerprints, dan Using SSH over the HTTPS port.