Server Solusi – Saat mencoba mengakses VPS melalui SSH, kamu mungkin menemukan pesan Permission denied meskipun alamat IP server dan port SSH sudah benar. Masalah ini cukup membingungkan karena koneksi ke server bisa saja berhasil, tetapi proses login tetap ditolak.

Pesan tersebut tidak selalu berarti permission file Linux salah. SSH juga dapat menolak login karena username keliru, password tidak sesuai, private key tidak ditemukan, public key belum terdaftar, atau metode autentikasi yang digunakan tidak diizinkan oleh server.

Saya menyarankan kamu memulai troubleshooting dari pesan error lengkap dan log autentikasi, bukan langsung mengubah permission dengan chmod 777 atau menonaktifkan fitur keamanan SSH. Dengan begitu, perbaikan bisa diarahkan ke penyebab yang benar tanpa menambah risiko keamanan server.

Mengapa SSH menampilkan Permission denied?

Cara mengatasi Permission denied saat SSH adalah memastikan username dan metode autentikasi sudah benar, memeriksa private key yang digunakan, memvalidasi permission file SSH, lalu membaca log autentikasi di server.

Jika kamu menggunakan SSH key, periksa apakah public key sudah terpasang di file ~/.ssh/authorized_keys milik akun tujuan. Jika menggunakan password, pastikan password benar dan server memang mengizinkan autentikasi password. Untuk mengetahui penyebab yang lebih spesifik, jalankan SSH dalam mode verbose menggunakan opsi -v.

Kenali Jenis Error Permission Denied

Sebelum melakukan perubahan, perhatikan pesan yang muncul di terminal. Setiap variasi pesan dapat memberikan petunjuk berbeda.

Pesan di atas merupakan petunjuk awal, bukan bukti pasti. Penyebab sebenarnya perlu dikonfirmasi melalui pemeriksaan sisi client dan server.

Baca JugaVPS Kehabisan Inode Meski Disk Masih Kosong? Solusinya

Periksa Username, IP, dan Port SSH

Kesalahan yang paling mudah terlewat adalah menggunakan username yang tidak sesuai dengan akun di VPS.

Sebagai contoh, beberapa penyedia VPS memberikan akses awal melalui akun root, sementara server lain menggunakan akun seperti ubuntu, debian, atau username yang dibuat sendiri. Nama akun tersebut tidak bisa dianggap sama pada setiap server.

Coba koneksi menggunakan format berikut:

ssh username@IP_SERVER

Jika server menggunakan port SSH khusus, tambahkan opsi -p:

ssh -p 2222 username@IP_SERVER

Ganti username, IP_SERVER, dan 2222 sesuai konfigurasi server kamu.

Jika kamu tidak mengetahui username yang benar, periksa informasi akses dari penyedia VPS atau administrator server. Jangan mencoba mengubah konfigurasi SSH sebelum memastikan akun tujuan memang tersedia.

Aktifkan Mode Verbose untuk Menemukan Penyebab

Jika username dan alamat server sudah benar tetapi login tetap ditolak, langkah berikutnya adalah memeriksa proses autentikasi dari sisi client.

Jalankan:

ssh -v username@IP_SERVER

Untuk mendapatkan informasi diagnostik lebih terperinci, kamu juga bisa menggunakan:

ssh -vvv username@IP_SERVER

Opsi -v dan -vvv menampilkan informasi proses koneksi, pemilihan metode autentikasi, dan penggunaan SSH key. Informasi ini membantu mengetahui apakah client menemukan key yang sesuai dan apakah server menerima atau menolaknya.

Perhatikan baris yang berkaitan dengan pesan berikut:

• identity file ... type -1: file identitas pada lokasi tersebut tidak ditemukan atau tidak dapat digunakan sebagai key yang dikenali.

• Offering public key: client menawarkan public key kepada server.

• Server accepts key: server menerima key pada tahap pemeriksaan tersebut; autentikasi tetap perlu dilihat sampai selesai.

• Authentications that can continue: server menyatakan metode autentikasi yang masih bisa dicoba.

• No more authentication methods to try: metode yang tersedia sudah dicoba tetapi belum berhasil.

Output sebenarnya dapat berbeda tergantung versi OpenSSH dan konfigurasi server. Jangan menganggap satu baris log sebagai bukti tunggal tanpa melihat bagian berikutnya.

Langkah berikutnya: jika client tidak menemukan private key, periksa lokasi key. Jika key sudah ditawarkan tetapi ditolak, lanjutkan dengan pemeriksaan authorized_keys, permission, kepemilikan file, dan log server.

Baca JugaCara Mengatasi apt update Error di Ubuntu dengan Tepat

Periksa Private Key di Komputer Lokal

Jika kamu menggunakan autentikasi berbasis SSH key, pastikan private key yang benar tersedia di komputer lokal.

Untuk Linux atau macOS, lihat daftar file di direktori SSH:

ls -la ~/.ssh

File yang umum digunakan antara lain:

id_ed25519id_ed25519.pub

File tanpa ekstensi .pub biasanya merupakan private key, sedangkan file dengan ekstensi .pub merupakan public key. Jangan mengirimkan atau membagikan private key kepada siapa pun.

Jika key kamu menggunakan nama atau lokasi khusus, tentukan secara eksplisit saat melakukan koneksi:

ssh -i ~/.ssh/id_ed25519 username@IP_SERVER

Sesuaikan path tersebut dengan lokasi private key yang benar.

Perbaiki permission private key

Pada Linux dan macOS, SSH dapat menolak private key yang memiliki permission terlalu terbuka. Untuk private key milik akun kamu, gunakan:

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

Perintah pertama membatasi akses ke direktori .ssh, sedangkan perintah kedua membatasi akses baca dan tulis private key hanya untuk pemiliknya.

Jika nama file private key berbeda, ganti id_ed25519 dengan nama yang sesuai. Hindari menerapkan perintah ini secara membabi buta pada direktori milik pengguna lain.

Coba koneksi kembali:

ssh -i ~/.ssh/id_ed25519 username@IP_SERVER

Jika pesan UNPROTECTED PRIVATE KEY FILE sudah tidak muncul tetapi login masih ditolak, berarti kamu perlu memeriksa autentikasi di sisi server.

Pastikan Public Key Terdaftar di Server

Private key di komputer lokal harus memiliki pasangan public key yang telah diizinkan pada akun tujuan. Memiliki private key saja tidak otomatis memberikan akses ke VPS.

Pada server yang masih bisa diakses melalui console penyedia VPS atau sesi administratif lain, masuk menggunakan akun tujuan lalu periksa file berikut:

ls -ld "$HOME" "$HOME/.ssh"ls -l "$HOME/.ssh/authorized_keys"

File authorized_keys biasanya berisi public key yang diizinkan untuk login. Jika file tersebut tidak ada, public key belum tentu terpasang pada lokasi yang diharapkan. Lokasi sebenarnya bisa berubah sesuai konfigurasi AuthorizedKeysFile.

Baca JugaCara Mengatasi Out of Memory di Linux VPS

Jika kamu masih bisa login menggunakan password dan kebijakan server mengizinkannya, public key dapat disalin dengan perintah berikut dari komputer lokal:

ssh-copy-id username@IP_SERVER

Perintah ini menggunakan public key yang dipilih oleh mekanisme ssh-copy-id. Jika kamu mempunyai beberapa key atau memakai nama file khusus, periksa opsi yang didukung oleh versi ssh-copy-id kamu agar key yang benar dipasang.

Jika tidak bisa login sama sekali, gunakan console web atau recovery console dari penyedia VPS untuk memeriksa konfigurasi. Jangan menghapus file authorized_keys yang sudah ada karena tindakan tersebut dapat menghilangkan akses bagi pengguna lain.

Periksa Permission dan Kepemilikan File SSH di Server

OpenSSH menerapkan pemeriksaan keamanan terhadap file yang digunakan untuk autentikasi. Permission atau kepemilikan yang tidak sesuai dapat menyebabkan public key diabaikan atau ditolak.

Untuk konfigurasi Linux yang menggunakan direktori home standar, pola permission yang umum adalah:

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

Namun, jalankan perintah tersebut sebagai pengguna yang benar dan hanya setelah memastikan file itu memang miliknya.

Periksa juga kepemilikan direktori:

whoamiecho "$HOME"ls -ld "$HOME" "$HOME/.ssh"ls -l "$HOME/.ssh/authorized_keys"

Pastikan whoami dan $HOME menunjukkan akun tujuan yang benar. Jika file dimiliki oleh akun lain, jangan langsung mengubah kepemilikan tanpa memahami bagaimana akun tersebut dibuat dan bagaimana server mengelola home directory.

Pada beberapa sistem, direktori home juga tidak boleh dapat ditulis oleh pengguna lain. Jika pemeriksaan menunjukkan masalah tersebut, evaluasi permission home directory berdasarkan kebutuhan sistem sebelum mengubahnya.

Hindari chmod -R 777 ~/.ssh. Perintah itu memberikan akses terlalu luas dan bertentangan dengan tujuan pengamanan private key serta konfigurasi SSH.

Periksa Log Autentikasi SSH di Server

Jika client sudah menawarkan key tetapi login tetap gagal, log server biasanya menjadi sumber informasi yang lebih spesifik.

Pada Ubuntu dan Debian, coba:

sudo journalctl -u ssh.service --since "15 minutes ago" --no-pager

Pada distribusi yang menggunakan unit sshd, coba:

Baca JugaCara Mencari Penyebab systemctl service failed di Linux

sudo journalctl -u sshd.service --since "15 minutes ago" --no-pager

Nama unit bergantung pada distribusi dan paket yang digunakan. Jika salah satu nama tidak ditemukan, periksa unit SSH yang tersedia di sistem.

Untuk Ubuntu yang mencatat autentikasi ke file sistem, kamu juga bisa melihat:

sudo tail -n 100 /var/log/auth.log

Di sebagian distribusi berbasis RHEL, log autentikasi dapat ditemukan di /var/log/secure. Jika sistem tidak menyimpan log pada file tersebut, gunakan journal systemd.

Saat memeriksa log, cari pesan yang berkaitan dengan username dan waktu koneksi yang gagal. Beberapa petunjuk yang mungkin ditemukan:

• Key ditolak atau tidak cocok dengan daftar key yang diizinkan.

• Akun tidak diizinkan masuk melalui kebijakan SSH.

• Metode autentikasi yang diperlukan tidak diaktifkan.

• Permission atau kepemilikan file autentikasi tidak memenuhi pemeriksaan keamanan.

Jangan langsung mengubah konfigurasi hanya berdasarkan dugaan. Cocokkan pesan log dengan output ssh -v agar perbaikan lebih terarah.

Periksa Konfigurasi sshd_config

Jika username, key, dan permission sudah benar, periksa apakah server mengizinkan metode autentikasi yang kamu gunakan.

File konfigurasi utama OpenSSH umumnya berada di:

/etc/ssh/sshd_config

Ubuntu juga dapat menggunakan file tambahan di:

/etc/ssh/sshd_config.d/

Konfigurasi tambahan penting diperiksa karena dapat memengaruhi nilai efektif yang digunakan server.

Untuk memeriksa pengaturan autentikasi yang efektif, kamu dapat menjalankan:

sudo sshd -T | grep -E 'pubkeyauthentication|passwordauthentication|authorizedkeysfile|permitrootlogin|allowusers|denyusers'

Perintah ini membantu menampilkan nilai konfigurasi efektif yang relevan. Namun, untuk aturan yang bergantung pada alamat client, username, atau blok Match, pemeriksaan tersebut mungkin perlu disesuaikan dengan konteks koneksi.

Beberapa pengaturan yang perlu diperhatikan:

• PubkeyAuthentication: menentukan apakah autentikasi menggunakan public key diizinkan.

• PasswordAuthentication: menentukan apakah autentikasi password diizinkan.

• AuthorizedKeysFile: menentukan lokasi file public key yang diperiksa.

• PermitRootLogin: mengatur kebijakan login root.

• AllowUsers dan DenyUsers: membatasi pengguna yang dapat atau tidak dapat login.

Jika kamu menemukan pembatasan yang tidak sesuai kebutuhan, ubah hanya aturan yang memang menjadi penyebab masalah. Jangan mengaktifkan login root atau autentikasi password secara sembarangan untuk mengatasi satu akun yang gagal login.

Validasi sebelum menerapkan perubahan

Sebelum memuat konfigurasi yang sudah diubah, jalankan:

sudo sshd -t

Jika tidak ada output error, pemeriksaan sintaks berhasil. Ini tidak menjamin seluruh kebijakan autentikasi sudah benar, tetapi dapat membantu mendeteksi kesalahan sintaks.

Jika kamu harus menerapkan perubahan pada server produksi, pertahankan sesi SSH yang masih aktif dan pastikan tersedia console alternatif sebelum melakukan restart atau reload layanan. Kesalahan konfigurasi bisa membuat kamu kehilangan akses jarak jauh. Dokumentasi Ubuntu juga menyarankan validasi konfigurasi sebelum restart layanan SSH.

Jika Login Menggunakan Password Tetap Ditolak

Untuk koneksi berbasis password, lakukan pemeriksaan berikut:

1. Pastikan username benar.

2. Pastikan password sesuai dengan akun di server, bukan password panel hosting atau akun lain.

3. Periksa log server untuk melihat alasan penolakan.

4. Pastikan kebijakan SSH mengizinkan autentikasi password jika memang itu metode yang ingin digunakan.

5. Periksa apakah akun dibatasi oleh kebijakan sistem atau konfigurasi SSH.

Jika autentikasi password dinonaktifkan, mengetik ulang password tidak akan menyelesaikan masalah. Kamu perlu menggunakan metode autentikasi yang diizinkan, seperti SSH key, atau meminta administrator meninjau kebijakan server.

Pada VPS yang menggunakan SSH key sebagai metode utama, mempertahankan kebijakan tersebut sering kali lebih tepat daripada mengaktifkan password hanya karena satu koneksi gagal.

Verifikasi Setelah Perbaikan

Setelah melakukan perubahan, uji koneksi dengan username, alamat IP, port, dan key yang sama seperti sebelumnya:

ssh -v -i ~/.ssh/id_ed25519 username@IP_SERVER

Jika login berhasil, kamu seharusnya memperoleh sesi shell pada akun tujuan. Periksa identitas akun dengan:

whoami

Jika masih gagal, ulangi pemeriksaan output verbose dan log server pada waktu percobaan terbaru. Perubahan permission atau konfigurasi belum bisa dianggap berhasil hanya karena perintahnya berjalan tanpa error.

Untuk menghindari kehilangan akses, jangan menutup sesi administratif yang masih berfungsi sebelum kamu berhasil membuka koneksi baru dan memverifikasi bahwa akses sudah pulih.

Cara Mencegah Permission Denied Saat SSH Terulang

Beberapa kebiasaan berikut membantu mengurangi masalah autentikasi SSH:

• Simpan informasi akses dengan benar. Catat username, IP, port, dan key yang digunakan untuk setiap server.

• Amankan private key. Batasi permission file dan jangan mengirimkan private key melalui chat atau email.

• Dokumentasikan perubahan konfigurasi. Simpan salinan konfigurasi sebelum mengubah aturan SSH.

• Gunakan metode autentikasi yang konsisten. Hindari mencampur banyak key tanpa dokumentasi tentang akun dan server tujuannya.

• Pertahankan jalur akses alternatif. Pastikan console penyedia VPS tersedia sebelum mengubah konfigurasi SSH di server produksi.

• Periksa log setelah perubahan. Jika login gagal, gunakan log autentikasi untuk memastikan apakah masalah berasal dari akun, key, atau kebijakan server.

Langkah pencegahan ini tidak menjamin seluruh gangguan SSH bisa dihindari, tetapi membantu mempersempit sumber masalah dan mengurangi risiko kehilangan akses.

FAQs

Mengapa muncul Permission denied (publickey)?

Pesan ini menunjukkan bahwa autentikasi public key tidak berhasil. Penyebabnya dapat berupa private key yang salah, public key yang belum terdaftar pada akun tujuan, lokasi authorized_keys yang berbeda, atau permission dan kebijakan SSH yang tidak sesuai. Gunakan ssh -v dan log server untuk menentukan penyebabnya.

Apakah chmod 777 bisa mengatasi SSH Permission Denied?

Tidak disarankan. Permission 777 memberi akses baca, tulis, dan eksekusi kepada semua pengguna. Pada file atau direktori SSH, permission terlalu terbuka justru dapat menimbulkan masalah keamanan dan membuat autentikasi key ditolak. Gunakan permission sesuai kebutuhan file dan akun pemiliknya.

Bagaimana jika saya tidak bisa login untuk memperbaiki authorized_keys?

Gunakan console web atau recovery console dari penyedia VPS, jika tersedia. Dari sana, periksa akun tujuan, file authorized_keys, permission, kepemilikan, dan log autentikasi. Jangan menghapus key yang sudah terpasang tanpa memastikan bahwa kamu memiliki jalur akses alternatif.

Mengapa SSH meminta password padahal saya sudah membuat SSH key?

Client mungkin tidak menggunakan key yang kamu maksud, key belum ditambahkan ke agent, server menolak key, atau autentikasi password masih menjadi metode berikutnya yang ditawarkan. Gunakan ssh -v atau tentukan key dengan opsi -i untuk melihat key mana yang digunakan.

Apakah saya perlu restart SSH setelah memperbaiki permission?

Perubahan permission pada authorized_keys biasanya tidak memerlukan restart layanan SSH. Jika kamu mengubah konfigurasi sshd_config, validasi terlebih dahulu dengan sudo sshd -t, lalu terapkan perubahan sesuai kebutuhan dan konfigurasi distribusi. Pertahankan sesi aktif serta akses alternatif selama proses tersebut.

Penutup

Masalah Permission denied saat SSH tidak selalu disebabkan oleh permission file. Username yang salah, private key yang tidak sesuai, public key yang belum terdaftar, kebijakan autentikasi, dan pembatasan akun juga dapat menyebabkan login ditolak.

Untuk menanganinya secara sistematis, mulai dari memeriksa username dan port, lanjutkan dengan ssh -v, validasi private key dan authorized_keys, lalu periksa log autentikasi server. Jika perlu mengubah konfigurasi, validasi terlebih dahulu dan pastikan kamu memiliki akses alternatif.

Dengan mengikuti urutan tersebut, kamu dapat mempersempit penyebab masalah tanpa harus mengubah permission atau menurunkan keamanan SSH secara sembarangan.