Koneksi SSH adalah tulang punggung administrasi server modern. Bayangkan situasi ini: Anda sedang buru-buru harus menyelesaikan insiden di server produksi, Anda mengetikkan perintah SSH dengan sangat yakin, memasukkan password yang Anda ketahui 100% benar, tetapi yang muncul di layar bukan shell server yang ditunggu, melainkan pesan error yang dingin dan frustratif. Pesan itu menolak koneksi Anda mentah-mentah, bahkan ketika Anda sangat yakin bahwa kredensial yang dimasukkan tidak salah. Situasi seperti ini bukan sekadar gangguan teknis kecil; ia adalah roadblock yang bisa menghentikan alur kerja, memicu downtime lebih lama, dan menimbulkan kepanasan jika terjadi saat deployment malam hari.

Banyak administrator sistem, terutama yang masih baru di lingkungan Linux atau yang baru pertama kali mengonfigurasi server di cloud, pernah mengalami skenario ini. Kebingungan sering kali muncul karena logika awal kita sederhana: jika password benar, maka akses harus diberikan. Namun, mekanisme keamanan di sistem operasi berbasis Unix tidak bekerja sekadar dengan logika biner "password benar atau salah". Ada lapisan izin (permission) sistem berkas, aturan ownership, konfigurasi daemon SSH, hingga kebijakan keamanan seperti SELinux atau AppArmor yang berperan sebagai penjaga gerbang tambahan.

Artikel ini hadir sebagai panduan komprehensif untuk membongkar, mendiagnosis, dan memperbaiki masalah Permission denied pada SSH ketika Anda menggunakan password yang benar. Kita tidak akan sekadar memberikan perintah-perintah siap pakai tanpa penjelasan, melainkan akan menyelami anatomi dari error itu sendiri, memahami secara mendalam mengapa sistem bertindak demikian, hingga memberikan solusi permanen yang memastikan masalah ini tidak kembali menghantui Anda di masa depan.

Anatomi Pesan Error

Pertama-tama, mari kita kenali musuh yang akan kita hadapi. Pesan error yang muncul di terminal Anda biasanya memiliki variasi, tetapi intinya selalu sama. Berikut adalah kutipan pesan error asli (verbatim) yang paling sering ditemui:

user@local-machine:~$ ssh admin@192.168.1.10
admin@192.168.1.10's password: 
Permission denied, please try again.
admin@192.168.1.10's password: 
Permission denied, please try again.
admin@192.168.1.10's password: 
Permission denied (publickey,password).

Dalam bahasa Indonesia, pesan tersebut dapat diartikan secara singkat sebagai: "Izin ditolak, silakan coba lagi. Izin ditolak (kunci publik, password)." Pesan ini secara eksplisit memberitahu Anda bahwa upaya otentikasi telah gagal pada metode yang dicoba, yang dalam konteks ini adalah metode password (dan kemudian diikuti oleh metode publickey).

Namun, pertanyaan paling mendasar adalah: kenapa error ini muncul padahal password yang diketikkan sudah benar? Untuk menjawabnya, kita harus memahami bahwa pesan Permission denied pada SSH adalah pesan yang sangat generik. Ia adalah topi hitam yang menutupi berbagai jenis kegagalan di balik layar. SSH daemon (sshd) di sisi server sengaja dibuat untuk memberikan pesan error yang samar sebagai bentuk pembelaan keamanan (security through obscurity). Tujuannya adalah agar penyerang yang mencoba menebak password atau mengeksploitasi sistem tidak mendapatkan petunjuk spesifik mengapa upaya mereka gagal. Apakah gagal karena password salah? Apakah gagal karena direktori home pengguna tidak ada? Atau apakah gagal karena izin berkas pada kunci SSH terlalu terbuka? Semuanya akan dilaporkan dengan pesan yang sama: Permission denied.

Spesifik untuk kasus "dengan password yang benar", error ini hampir selalu disebabkan oleh sistem operasi yang menolak untuk menjalankan proses sesi pengguna karena pelanggaran kebijakan izin berkas (file permissions). Di ekosistem Linux, daemon SSH (sshd) berjalan dengan hak root. Ketika pengguna berhasil diverifikasi password-nya, sshd akan mencoba membuat proses child dan menjatuhkan hak aksesnya (drop privileges) menjadi hak pengguna tersebut. Proses ini memerlukan direktori home yang aman. Jika direktori home atau berkas-berkas konfigurasi di dalamnya (seperti ~/.ssh/) memiliki izin tulis untuk group atau other (misalnya izin 775 atau 777), maka sshd akan menganggap lingkungan itu telah terkompromi atau tidak aman, dan ia akan langsung memutus koneksi sebelum sesi SSH sempat dibuka, meskipun password yang dimasukkan telah dievaluasi sebagai benar. Pemahaman mengenai anatomi error ini adalah kunci untuk tidak berjalan di tempat saat melakukan debugging.

Penyebab Umum

Setelah memahami bahwa error ini adalah bentuk pertahanan sistem terhadap lingkungan yang tidak aman, kita perlu memetakan penyebab-penyebab umum yang memicu pertahanan tersebut. Berikut adalah 4 root cause paling sering terjadi, diurutkan dari yang paling umum dijumpai sehari-hari:

  1. Izin (Permission) pada direktori ~/.ssh/ atau berkas ~/.ssh/authorized_keys terlalu longgar. Ini adalah juara bertahan penyebab paling sering. Banyak pengguna yang terbiasa menggunakan perintah chmod 777 untuk "memaksa" aplikasi berjalan, tanpa sadar bahwa tindakan itu membuat sshd menolak membaca berkas otorisasi. Izin 777 pada berkas kunci sama saja dengan membiarkan siapa saja di server mengubah kunci masuk Anda, sebuah risiko keamanan fatal.
  2. Ownership (kepemilikian) berkas SSH salah. Berkas ~/.ssh/authorized_keys atau direktori ~/.ssh/ mungkin saja dimiliki oleh root atau pengguna lain, bukan oleh pengguna yang mencoba log masuk. Meskipun izinnya sudah benar secara numerik (misalnya 700), jika pemiliknya salah, proses pengguna biasa tidak akan dapat membaca berkas tersebut, dan sshd akan menolak akses.
  3. Konfigurasi PasswordAuthentication dinonaktifkan di server. Terkadang, demi keamanan, administrator server menonaktifkan otentikasi berbasis password sepenuhnya di berkas sshd_config. Dalam skenario ini, meskipun Anda memasukkan password yang paling benar sekaligus, server secara mutlak tidak akan memprosesnya dan hanya mengizinkan masuk via SSH key.
  4. Pengguna tidak memiliki shell yang valid. Saat membuat pengguna, terkadang shell default-nya diset ke /usr/sbin/nologin atau /bin/false. Tujuannya agar pengguna itu ada di sistem (misalnya untuk keperluan FTP atau kepemilikan berkas), tetapi tidak boleh masuk ke terminal interaktif. SSH akan menolak sesi interaktif untuk pengguna seperti ini.

Menentukan penyebab yang tepat:

Langkah pertama diagnosis adalah memeriksa izin dan ownership dari mesin lokal maupun server (jika Anda masih memiliki akses melalui cara lain, seperti konsol vendor cloud atau pengguna root lain). Anda bisa menggunakan perintah ls -ld untuk direktori dan ls -la untuk berkas di dalamnya.

Periksa hal-hal berikut di mesin lokal (komputer Anda):

  • Izin direktori ~/.ssh/ harus 700 atau 755.
  • Izin berkas private key (misal id_rsa) harus ketat 600.

Periksa hal-hal berikut di server tujuan:

  • Izin direktori home ~ seharusnya 755 atau 700 (tidak boleh bisa ditulis oleh group/other).
  • Izin direktori ~/.ssh/ harus 700.
  • Izin berkas ~/.ssh/authorized_keys harus 600 atau 644.
  • Pemilik (owner) direktori dan berkas tersebut haruslah adalah pengguna yang sedang Anda gunakan untuk log masuk, bukan root.

Jika semua izin dan ownership sudah persis seperti di atas namun masih gagal, langkah kedua adalah memeriksa konfigurasi daemon SSH di server. Buka berkas /etc/ssh/sshd_config dan cari baris PasswordAuthentication. Jila nilainya no, maka itu penyebabnya. Jika bukan, cek berkas /etc/passwd untuk melihat apakah shell pengguna Anda diset ke /bin/bash atau shell valid lainnya.

Cara Memperbaiki

Bagian ini akan membahas solusi secara langkah demi langkah. Kita akan mengasumsikan Anda mendapatkan error ini, dan Anda memiliki akses darurat ke server (misalnya melalui root via konsol cloud, atau Anda sudah masuk sebagai pengguna lain yang memiliki hak sudo). Perbaikan akan diurutkan berdasarkan skenario root cause yang paling umum.

Skenario 1: Memperbaiki Izin Berkas dan Ownership (Root Cause Paling Umum)

Jika penyebabnya adalah izin berkas yang longgar atau ownership yang salah, Anda harus mengembalikannya ke nilai default yang ketat. Inilah solusi permanen untuk masalah ini.

Langkah 1: Pastikan Anda berada di home directory pengguna yang bermasalah di server. Misalnya, pengguna tersebut bernama deployer.

# Masuk ke home directory pengguna
cd /home/deployer

Langkah 2: Perbaiki ownership direktori ~/.ssh dan berkas di dalamnya agar dimiliki sepenuhnya oleh pengguna deployer.

# Keluaran yang tampak: Tidak ada output jika berhasil, hanya kembali ke prompt
sudo chown -R deployer:deployer .ssh

Langkah 3: Setel izin direktori dan berkas secara presisi. Ini adalah langkah kritis.

# Hanya pemilik yang bisa baca, tulis, dan masuk ke direktori
sudo chmod 700 .ssh
# Keluaran yang tampak: Tidak ada output jika berhasil

# Hanya pemilik yang bisa baca dan tulis berkas authorized_keys
sudo chmod 600 .ssh/authorized_keys
# Yang akan kamu lihat: Tidak ada output jika berhasil

Langkah 4: Verifikasi perubahan yang telah dilakukan.

ls -la .ssh/
# Keluaran yang tampak:
# total 8
# drwx------ 2 deployer deployer 4096 Okt 10 12:00 .
# -rw------- 1 deployer deployer  800 Okt 10 12:00 authorized_keys

Perhatikan bahwa izin direktori adalah drwx------ (700) dan berkas adalah -rw------- (600), serta pemiliknya adalah deployer:deployer. Ini adalah kondisi yang sangat aman dan akan membuat sshd senang.

Skenario 2: Memperbaiki PasswordAuthentication yang Dinonaktifkan

Jika Anda yakin password Anda benar tetapi server menolak karena konfigurasi, Anda perlu mengubah berkas konfigurasi SSH daemon.

Langkah 1: Buka berkas konfigurasi menggunakan editor teks dengan hak root.

sudo nano /etc/ssh/sshd_config

Langkah 2: Cari baris PasswordAuthentication. Hapus tanda pagar (#) di depannya jika ada, dan ubah nilainya menjadi yes.

# Sebelum:
# PasswordAuthentication no

# Sesudah:
PasswordAuthentication yes

Langkah 3: Simpan berkas tersebut, lalu restart layanan SSH agar konfigurasi baru diterapkan.

sudo systemctl restart sshd
# Atau di beberapa distro lama:
sudo service sshd restart
# Keluaran yang tampak: Tidak ada output error. Prompt kembali normal.

Verifikasi Solusi Berhasil

Cara paling mutlak untuk memverifikasi apakah solusi di atas berhasil adalah dengan mencoba membangun koneksi SSH kembali dari mesin lokal Anda. Namun, sebelum itu, mari gunakan metode verifikasi yang lebih verbose untuk melihat apa yang sebenarnya terjadi di balik layar.

Dari mesin lokal Anda, jalankan SSH dengan flag -v (verbose) untuk melihat proses otentikasi langkah demi langkah:

ssh -v deployer@192.168.1.10

Jika perbaikan izin berhasil, Anda akan melihat log seperti ini di bagian akhir output:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
deployer@192.168.1.10's password: 
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.10 ([192.168.1.10]:22).

Pesan Authentication succeeded (password) adalah bukti bahwa password diterima dan lingkungan sesi dianggap aman, sehingga koneksi berlanjut ke shell interaktif. Jika masih gagal, output -v akan memberi tahu tepat di titik mana proses dibatalkan, yang sangat membantu untuk debugging lebih lanjut.

Supaya Tidak Terulang

Memperbaiki masalah saat terjadi downtime memang memberikan pelajaran berharga, tetapi pekerjaan administrator sistem yang sebenarnya adalah memastikan masalah tersebut tidak pernah terulang kembali. Mencegah error Permission denied akibat izin berkas yang kacau atau konfigurasi yang salah membutuhkan pendekatan proaktif, baik itu melalui otomasi, konfigurasi yang tepat, maupun penerapan Kebiasaan yang baik secara konsisten di seluruh infrastruktur.

Pertama, mari kita bicarakan tentang penggunaan SSH keys sebagai ganti password. Ini adalah Praktik terbaik fundamental yang sayangnya masih sering dilewatkan. Menggunakan otentikasi berbasis SSH key tidak hanya menghilangkan risiko serangan brute-force, tetapi juga secara elegan mem-bypass banyak masalah permission pada password. Namun, penggunaan SSH key membawa tanggung jawab baru: Anda harus memastikan bahwa mesin lokal Anda (di mana private key berada) juga mematuhi aturan izin yang ketat. Banyak pengguna yang mendapatkan error Permission denied (publickey,password) bukan karena server bermasalah, melainkan karena private key di mesin lokal mereka (misalnya ~/.ssh/id_rsa) memiliki izin 644 (bisa dibaca group/other). Daemon SSH klien di mesin lokal akan menolak menggunakan private key yang izinnya terlalu terbuka. Oleh karena itu, jalankan perintah ini di mesin lokal Anda segera setelah membuat kunci SSH:

# Di mesin lokal
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

Kedua, untuk mencegah masalah ownership dan izin di sisi server yang sering terjadi ketika banyak orang bekerja sama di satu server atau ketika menggunakan deployment tool seperti Capistrano atau Ansible, otomasi adalah sahabat terbaik Anda. Jangan pernah membuat pengguna dan mengonfigurasi folder SSH secara manual berulang-ulang. Gunakan skrip provisioning. Berikut adalah contoh potongan skrip Bash yang aman untuk menyiapkan pengguna dan lingkungan SSH mereka dari awal:

#!/bin/bash
# Skrip setup pengguna aman
USERNAME="deployer"

# Membuat pengguna dengan home directory
useradd -m -s /bin/bash "$USERNAME"

# Membuat folder .ssh dengan izin yang ketat secara langsung
mkdir -p /home/"$USERNAME"/.ssh
chmod 700 /home/"$USERNAME"/.ssh

# Menyalin kunci publik (asumsi kunci ada di tempat yang sama)
cp /tmp/id_rsa.pub /home/"$USERNAME"/.ssh/authorized_keys
chmod 600 /home/"$USERNAME"/.ssh/authorized_keys

# Memastikan ownership benar SEKALI LALU UNTUK SELAMANYA
chown -R "$USERNAME":"$USERNAME" /home/"$USERNAME"/.ssh

echo "Pengguna $USERNAME berhasil dibuat dengan konfigurasi SSH yang aman."

Ketiga, perbedaan sistem operasi (OS) juga memengaruhi bagaimana kita mencegah error ini. Di sistem berbasis RHEL (CentOS, AlmaLinux, Rocky Linux), Anda harus sangat waspada terhadap SELinux. Meskipun izin berkas Unix (rwx) sudah benar, jika konteks keamanan SELinux pada berkas authorized_keys tidak tepat, SSH akan tetap menolak akses dengan pesan error yang sama. Untuk mencegah ini di lingkungan RHEL, selalu restore konteks SELinux setelah memanipulasi berkas di direktori .ssh:

# Khusus untuk sistem dengan SELinux (RHEL/CentOS)
restorecon -Rv /home/deployer/.ssh
# Hasil yang muncul:
# Relabeled /home/deployer/.ssh from unconfined_u:object_r:user_home_t:s0 to unconfined_u:object_r:ssh_home_t:s0

Di sisi lain, pada sistem berbasis Debian/Ubuntu, AppArmor adalah sistem MAC (Mandatory Access Control) yang berlaku, meskipun profile AppArmor untuk SSH jarang sekali menyebabkan masalah izin secara default dibandingkan SELinux. Namun, memastikan AppArmor tidak berada dalam mode enforce yang salah untuk profil SSH juga merupakan langkah pencegahan yang baik, yang bisa dicek dengan perintah sudo aa-status.

Dengan mengotomasi pembuatan pengguna, mematuhi ketatnya izin di mesin lokal, dan menghormati kebijakan keamanan bawaan distribusi Linux Anda, error Permission denied akibat salah konfigurasi dapat dicegah hingga mendekati nol persen.

Langkah Lanjutan

Terkadang, meskipun Anda telah mengikuti seluruh langkah perbaikan di atas—izin sudah 700/600, ownership sudah tepat, konfigurasi sshd_config sudah diubah, dan verbose mode tidak menunjukkan kegagalan yang jelas—koneksi SSH tetap menolak dengan pesan Permission denied. Dalam dunia teknologi, situasi di mana solusi yang seharusnya work tidak memberikan hasil adalah tanda bahwa ada variabel tersembunyi yang belum kita temukan. Untuk kasus seperti ini, kita harus meninggalkan tebakan dan mulai membaca log sistem yang sebenarnya.

Log adalah sumber kebenaran absolut. Sementara klien SSH di mesin lokal Anda hanya bisa menebak berdasarkan flag -v, daemon SSH di sisi server mencatat setiap langkah otentikasi dan alasan tepat di balik penolakannya. Cara membaca log bergantung pada distribusi Linux yang Anda gunakan. Pada sistem modern yang menggunakan systemd (Ubuntu 16.04+, Debian 9+, CentOS 7+), Anda dapat membaca log real-time dari daemon SSH menggunakan journalctl:

# Pantau log SSH secara real-time di server
sudo journalctl -u ssh -f
# Atau, jika nama unitnya sshd:
sudo journalctl -u sshd -f

Sementara log itu berjalan di satu terminal, coba lakukan koneksi SSH dari mesin lokal di terminal lain. Amati pesan yang muncul di log server. Jika masalahnya adalah izin berkas, Anda mungkin akan melihat pesan yang sangat spesifik seperti:

sshd[12345]: Authentication refused: bad ownership or modes for directory /home/deployer/.ssh

Pesan itu jauh lebih informatif daripada sekadar "Permission denied" di klien. Ia bahkan bisa memberi tahu apakah masalahnya ada di direktori home utama, direktori .ssh, atau berkas authorized_keys secara spesifik.

Pada distro lama atau sistem yang tidak menggunakan systemd, log SSH biasanya disimpan langsung di dalam berkas teks di /var/log/auth.log (Debian/Ubuntu) atau /var/log/secure (CentOS/RHEL). Anda bisa menggunakan tail untuk memantau berkas tersebut:

# Di Debian/Ubuntu
sudo tail -f /var/log/auth.log | grep sshd

# Di CentOS/RHEL
sudo tail -f /var/log/secure | grep sshd

Jika dari log Anda menemukan bahwa otentikasi gagal bukan karena izin berkas, melainkan karena sesuatu yang berkaitan dengan PAM (Pluggable Authentication Modules), misalnya PAM: Authentication failure, maka Anda memasuki wilayah deep-dive yang berbeda. PAM adalah lapisan otentikasi tambahan yang bisa memblokir login meskipun password UNIX benar, misalnya karena pengguna tersebut terkunci (account locked), atau melebihi batas percobaan login (faillock). Untuk memeriksa apakah pengguna terkunci, gunakan perintah passwd -S username atau periksa berkas /etc/shadow (tanda seru ! atau tanda bintang * di depan hash password menandakan akun yang dinonaktifkan).

Untuk eksplorasi lebih mendalam mengenai mekanisme otentikasi SSH, izin berkas, dan konfigurasi PAM, tidak ada sumber yang lebih otoritatif daripada dokumentasi resmi. Halaman manual (man) di sistem Linux itu sendiri adalah teman terbaik Anda. Jalankan man sshd untuk memahami secara detail bagaimana daemon SSH memproses authorized_keys dan aturan ketat izin apa saja yang diberlakukan. Selain itu, OpenSSH官方网站 (www.openssh.com) menyediakan panduan release notes yang sering kali menjelaskan perubahan perilaku keamanan di versi terbaru yang mungkin menyebabkan konfigurasi lama Anda ditolak.

Terakhir, jika masalah terkait PAM dan account locking, membaca manual PAM dengan perintah man pam_unix dan man pam_faillock akan memberikan wawasan mengapa login ditolak meskipun kredensialnya benar secara teori. Di titik ini, Anda tidak lagi sekadar memperbaiki error, melainkan memahami filosofi keamanan sistem operasi Linux itu sendiri.