Kenapa login SSH ke VPS error Permission denied (publickey)?

Pesan itu berarti server menolak semua key yang ditawarkan klien ssh. Penyebab umumnya: public key belum masuk ke ~/.ssh/authorized_keys, nama user salah, atau izin ~/.ssh dan authorized_keys terlalu longgar. Jalankan ssh -v untuk melihat key mana yang dicoba, lalu pasang mode 700 di ~/.ssh dan 600 di authorized_keys, bukan chmod 777.

Apakah aman mematikan login password SSH di VPS?

Aman, asalkan login dengan key sudah berhasil, dan ini salah satu langkah paling efektif karena bot tidak bisa lagi menebak password. Risikonya ada kalau dilakukan terlalu cepat. Biarkan sesi yang sedang terbuka tetap hidup dan pastikan kamu bisa login dari terminal kedua sebelum menutup apa pun.

Bagaimana cara masuk lagi ke VPS kalau terkunci dari SSH?

Pakai console web atau mode rescue di panel provider, karena keduanya tidak bergantung pada SSH. Login di sana, batalkan perubahan konfigurasi sshd atau jalankan ufw disable kalau firewall penyebabnya, jalankan sshd -t, lalu restart ssh.service. Lain kali simpan cadangan sshd_config dan tes dari sesi kedua.

Kenapa VPS perlu user biasa selain root?

Root bisa mengubah atau menghapus apa saja, jadi satu salah ketik bisa merusak seluruh server. User biasa dengan sudo membuatmu mengetik perintah berbahaya dengan sengaja. Dengan begitu kamu juga bisa mengatur PermitRootLogin no, sehingga key yang tercuri tidak langsung memberi akses root.

Kenapa SSH timeout kalau saya connect lewat nama domain?

Kalau domain itu di-proxy Cloudflare, proxy hanya menangani trafik HTTP dan HTTPS, bukan SSH, sehingga koneksimu tidak pernah sampai ke server. Sambungkan ke alamat IP server atau ke hostname DNS-only. Periksa juga bahwa aturan ufw mengizinkan port 22.

Cara Login SSH ke VPS Pertama Kali dan Mengamankannya

Cara login SSH ke VPS untuk pemula: login pertama, user sudo, SSH key, matikan password dan root, firewall ufw, plus cara menghindari terkunci dari server.

Ringkasan Utama

Cara login SSH ke VPS yang aman: masuk pertama kali sebagai root, buat user biasa dengan sudo, buat key Ed25519 di laptop lalu pasang dengan ssh-copy-id, matikan login password dan login root, kemudian aktifkan firewall ufw setelah port 22 diizinkan. Selalu tes dari sesi kedua sebelum menutup sesi lama supaya tidak terkunci.

Provider mengirim email berisi alamat IP, user root, dan sebuah password. Kamu mengetik ssh root@alamat-ip, lalu terminal menanyakan sesuatu tentang fingerprint yang tidak kamu mengerti. Beberapa menit kemudian server memang terbuka, tetapi siapa pun yang tahu alamatnya bisa mencoba menebak password root. Pemula biasanya berhenti di salah satu dari tiga titik: prompt fingerprint, pesan Permission denied (publickey), atau yang paling mahal, mematikan login password lalu terkunci di luar server sendiri.

Panduan ini membawamu dari login pertama sampai server yang hanya bisa dimasuki dengan key, dalam enam langkah berurutan. Setiap perintah dan opsi saya cocokkan dengan dokumentasi Ubuntu Server dan man page OpenSSH serta ufw, dan semua contoh memakai placeholder: IP 203.0.113.10 dan user bernama deploy. Contoh ditulis untuk Ubuntu atau Debian. Pola yang sama dipakai deploy situs ini: GitHub Actions login sebagai user biasa dengan key dari secret, tanpa password, dan tanpa alamat atau nama user yang tertulis di repository.

Mau memahami konsepnya dulu, termasuk cara kerja key dan kenapa SSH tidak bisa lewat proxy Cloudflare? Ikuti pelajaran gratis SSH untuk pemula: login ke server Linux dengan key di jalur DevOps from zero, lengkap dengan lab di komputermu sendiri.

Yang kamu butuhkan

Sebuah VPS Linux (panduan ini memakai Ubuntu atau Debian) yang sudah menyala, beserta alamat IP, user awal, dan password dari provider.
Terminal di laptop: Terminal di macOS atau Linux, atau PowerShell atau WSL di Windows, dengan klien ssh terpasang.
Akses console web dari panel provider. Ini pintu darurat kalau SSH gagal, jadi cari tombolnya sekarang, sebelum kamu butuh.
Dua jendela terminal yang bisa dibuka berdampingan. Kamu akan memakainya untuk satu trik penting di Langkah 4.

Belum punya VPS? Lihat dulu panduan memilih VPS murah di Indonesia, lalu kembali ke sini setelah servernya menyala.

Login pertama memakai user dan password dari provider. Ketik perintah di bawah, ganti alamat IP dengan milikmu. Kalau port SSH-nya bukan 22, tambahkan -p diikuti nomor port.

# Dari laptop. Pakai user dan IP dari email provider (di sini: placeholder).
ssh root@203.0.113.10

# Pertama kali, kira-kira muncul ini. Fingerprint-nya milik server kamu:
# The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
# ED25519 key fingerprint is SHA256:<fingerprint-server-kamu>.
# Are you sure you want to continue connecting (yes/no/[fingerprint])?
# Ketik: yes   (ssh lalu menyimpannya di ~/.ssh/known_hosts)

Prompt fingerprint itu bukan error. Ini cara ssh bertanya: benarkah ini server yang kamu maksud? Setelah kamu menjawab yes, fingerprint disimpan di ~/.ssh/known_hosts, dan kalau suatu saat berubah, ssh memperingatkan dan menolak lanjut. Untuk yang teliti, cocokkan fingerprint-nya dengan yang tampil di console provider, atau jalankan ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub di sana.

Langkah 2: Buat user biasa dengan hak sudo

Login sebagai root itu seperti memegang kunci semua pintu sekaligus: satu salah ketik bisa merusak apa pun. Buat user biasa untuk pemakaian sehari-hari, lalu beri hak sudo supaya perintah berbahaya harus diketik secara sadar. Jalankan ini di server, masih sebagai root.

# Di server, masih sebagai root
adduser deploy                # isi password + data singkat; ini password untuk sudo
usermod -aG sudo deploy       # beri hak sudo (Ubuntu dan Debian)

# Cek dari sesi root: pindah ke user baru lalu coba sudo
su - deploy
sudo whoami                   # harus mencetak: root
exit

Jangan lanjut sebelum sudo whoami mencetak root. Kalau muncul pesan bahwa user deploy tidak ada di file sudoers, ulangi usermod dari sesi root. Mematikan login root di Langkah 4 tanpa user sudo yang berfungsi adalah salah satu jalan tercepat menuju terkunci.

Langkah 3: Buat SSH key dan pasang ke server

SSH key adalah sepasang file: private key yang tinggal di laptopmu, dan public key yang dipasang di server. Dokumentasi Ubuntu merekomendasikan ssh-keygen -t ed25519. Manual ssh-keygen menyebut file private key tidak boleh bisa dibaca siapa pun selain kamu, dan passphrase boleh dikosongkan tetapi sebaiknya diisi supaya key yang tercuri tidak langsung bisa dipakai. Jalankan semua ini di laptop.

# Di LAPTOP kamu (bukan di server)
ssh-keygen -t ed25519
# Enter file in which to save the key: tekan Enter (jadi ~/.ssh/id_ed25519)
# Enter passphrase: isi passphrase; kosong juga boleh, tapi lebih lemah

# Pasang public key ke user deploy di server
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

# Tes: harus masuk TANPA diminta password server
ssh deploy@203.0.113.10

ssh-copy-id masuk ke server lalu menambahkan public key ke ~/.ssh/authorized_keys milik user tujuan, membuat file dan foldernya kalau belum ada. Kalau perintah itu tidak tersedia di laptopmu, lakukan manual dengan perintah di bawah. Ini juga cara kamu memasang key kedua nanti.

# Kalau ssh-copy-id tidak ada di laptop kamu: tempel manual, di server sebagai user deploy
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys   # tempel SATU baris isi id_ed25519.pub di sini
chmod 600 ~/.ssh/authorized_keys

Dua mode di atas bukan hiasan. Manual sshd menyarankan folder ~/.ssh dan authorized_keys tidak bisa diakses user lain, dan sshd menolak file itu kalau bisa ditulisi pihak lain selama StrictModes aktif, yang merupakan default. Jadi kalau key gagal dipakai, jangan menjalankan chmod 777: itu memperburuk keadaan.

Sekarang key sudah berfungsi, tutup jalur password. Selama server menerima password, bot di internet bisa terus menebak. Dengan PasswordAuthentication no, tebakan password tidak ada gunanya karena server tidak lagi menerimanya. PermitRootLogin punya default prohibit-password, artinya root masih bisa masuk dengan key. Mengubahnya menjadi no memaksa semua orang masuk sebagai user biasa.

Inilah langkah tempat orang mengunci dirinya sendiri. Jangan tutup sesi yang sedang terbuka sampai kamu berhasil login dari terminal kedua. Sesi yang masih hidup tetap bisa dipakai untuk membetulkan salah ketik.

# Wrong: ubah, restart, lalu menutup satu-satunya sesi.
# Satu salah ketik dan pintu tertutup dari luar.
sudo nano /etc/ssh/sshd_config
sudo systemctl restart ssh.service
exit

# Right: cadangkan, ubah lewat file drop-in, cek sintaks, restart,
# lalu tes dari terminal KEDUA sementara terminal pertama tetap terbuka.
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original
sudo nano /etc/ssh/sshd_config.d/00-hardening.conf
sudo sshd -t                      # tidak mencetak apa-apa = konfigurasi valid
sudo systemctl restart ssh.service

Dokumentasi Ubuntu menjelaskan bahwa file utama sshd_config diawali baris Include untuk folder sshd_config.d, dan OpenSSH memakai nilai pertama yang ditemukan untuk tiap pengaturan, sehingga file di folder itu mengalahkan file utama. Karena itu cara paling aman adalah satu file kecil di folder tersebut. Isinya hanya tiga baris. KbdInteractiveAuthentication punya default yes, jadi ikut dimatikan supaya satu-satunya jalan masuk adalah key.

# /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Perintah sshd -t hanya memeriksa validitas konfigurasi, dan Ubuntu menyarankannya sebelum restart. Setelah restart, sshd -T mencetak konfigurasi efektif. Kalau ada file lain yang mengatur hal yang sama lebih dulu, di sinilah kamu melihatnya.

# Lihat nilai yang BENAR-BENAR dipakai sshd, bukan yang kamu kira
sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '
# passwordauthentication no
# kbdinteractiveauthentication no
# permitrootlogin no

Langkah 5: Pasang firewall ufw, izinkan port 22 dulu

ufw adalah alat firewall bawaan Ubuntu. Man page ufw menyebut ia terpasang nonaktif dengan kebijakan default menolak trafik masuk, dan bahwa mengaktifkannya bisa memutus koneksi yang sedang berjalan, misalnya ssh. Urutannya karena itu penting: izinkan SSH sebelum enable, bukan sesudahnya.

# Wrong: aktifkan dulu, izinkan nanti. Sesi SSH-mu bisa putus di tengah jalan.
sudo ufw enable
sudo ufw allow 22/tcp

# Right: izinkan SSH DULU, baru aktifkan
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp          # hanya kalau server ini melayani web
sudo ufw allow 443/tcp         # hanya kalau server ini melayani web
sudo ufw enable
# Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
# Firewall is active and enabled on system startup

sudo ufw status verbose        # baris pertama: Status: active

Buka hanya port yang benar-benar dipakai. Server tanpa website cukup port 22. Kalau SSH-mu berjalan di port lain, izinkan port itu, bukan 22.

Langkah 6: Tes dari sesi kedua, dan kalau terkunci

Buka terminal kedua tanpa menutup yang pertama, lalu buktikan tiga hal: user deploy masuk dengan key, root ditolak, dan password ditolak.

# Terminal KEDUA, saat terminal pertama masih terbuka
ssh deploy@203.0.113.10                                   # harus masuk dengan key

ssh root@203.0.113.10                                     # harus ditolak
# root@203.0.113.10: Permission denied (publickey).

ssh -o PubkeyAuthentication=no deploy@203.0.113.10        # password harus ditolak juga
# deploy@203.0.113.10: Permission denied (publickey).

Kalau ketiganya sesuai, baru tutup sesi lama. Kalau salah satunya gagal, sesi pertama masih terbuka untuk memperbaiki konfigurasi, tanpa perlu menolong dari luar.

# Dari console / rescue provider, sebagai root: kembalikan SSH ke keadaan awal
rm /etc/ssh/sshd_config.d/00-hardening.conf
sshd -t
systemctl restart ssh.service

# Kalau penyebabnya firewall
ufw disable

Bagaimana kalau sesi pertama sudah tertutup dan kamu terkunci? Buka console atau mode rescue dari panel provider, login di sana, lalu kembalikan pengaturan di atas. Nama dan letak menu console berbeda di tiap provider, jadi periksa dokumentasi providermu. Cadangan sshd_config.original dari Langkah 4 adalah salinan keadaan semula kalau kamu butuh membandingkan.

Error umum dan cara memperbaikinya

Hampir semua pesan di bawah muncul pada percobaan pertama seorang pemula. Tambahkan -v pada perintah ssh untuk melihat langkah mana yang gagal.

Gejala	Penyebab	Perbaikan
Permission denied (publickey)	Public key belum terpasang, salah user, atau ssh memakai key yang salah. Bisa juga izin ~/.ssh atau authorized_keys terlalu longgar.	Jalankan ssh -v dan ssh -i ~/.ssh/id_ed25519 deploy@203.0.113.10. Di server pastikan ~/.ssh bermode 700 dan authorized_keys 600. Jangan chmod 777.
Connection timed out	Alamat atau port salah, ufw memblokir port 22, atau kamu mengarah ke hostname yang di-proxy Cloudflare. Proxy itu untuk trafik HTTP dan HTTPS, bukan SSH.	Cek IP dan port, periksa aturan ufw dari console, dan pakai alamat IP atau nama DNS-only untuk SSH, bukan nama domain yang di-proxy.
Connection refused	Alamat bisa dijangkau, tetapi tidak ada sshd yang mendengarkan di port itu: layanan mati atau Port-nya bukan 22.	Dari console, pastikan layanan ssh.service berjalan dan lihat pengaturan Port di konfigurasi sshd. Lalu coba lagi dengan -p nomor-port.
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED	Fingerprint server berbeda dari catatan di known_hosts. Biasanya server diinstal ulang, tetapi bisa juga ada pihak di tengah jalan.	Cocokkan fingerprint baru lewat console. Kalau memang instal ulang, hapus catatan lama dengan ssh-keygen -R 203.0.113.10, lalu login lagi.
deploy is not in the sudoers file	User deploy belum masuk grup sudo, atau kamu lupa Langkah 2.	Login sebagai root, jalankan usermod -aG sudo deploy, lalu login ulang sebagai deploy sebelum mengetes sudo.
Sesi putus setelah ufw enable, atau terkunci setelah restart ssh	Firewall diaktifkan sebelum port 22 diizinkan, atau konfigurasi sshd berisi salah ketik yang lolos karena tidak dicek.	Masuk lewat console provider, jalankan ufw disable atau hapus file drop-in, jalankan sshd -t, lalu restart ssh.service. Lain kali tes dari sesi kedua.
UNPROTECTED PRIVATE KEY FILE	File private key di laptop bisa dibaca user lain, dan ssh mengabaikannya.	Jalankan chmod 600 ~/.ssh/id_ed25519. Public key boleh dibagikan, private key tidak.

Checklist akhir

Ada user biasa dengan hak sudo, dan sudo whoami mencetak root.
Login dengan key berhasil dari laptop, tanpa meminta password server.
PasswordAuthentication no dan PermitRootLogin no tampil di keluaran sshd -T.
ssh root dan login password sama-sama ditolak dari terminal kedua.
ufw aktif dengan port 22 diizinkan, dan hanya port lain yang memang kamu butuhkan.
Private key punya passphrase, dan salinannya tersimpan di tempat yang aman selain laptop.

Server yang sudah aman tetap bisa rusak karena hal lain. Langkah berikutnya yang saya sarankan adalah strategi backup 3-2-1 untuk VPS, supaya satu salah ketik tidak berarti data hilang.

Belajar lebih dalam

Panduan ini sengaja berupa langkah praktis. Kalau kamu ingin mengerti kenapa SSH memeriksa izin file, bagaimana known_hosts dan authorized_keys bekerja, dan bagaimana menjalankan lab SSH aman di Docker di komputermu sendiri, ikuti pelajaran gratisnya.

SSH untuk pemula: login ke server Linux dengan key (pelajaran 2, DevOps from zero)

Aturan yang bisa dibawa pulang: jangan pernah mengubah cara login saat hanya punya satu sesi. Tambahkan jalur baru dulu, buktikan jalur itu bekerja dari sesi kedua, baru tutup jalur lama.

Sumber dan dokumentasi