Kunci SSH: cara mengatur login ke server tanpa kata sandi

Kunci SSH adalah sepasang berkas: kunci privat tetap berada di komputer Anda, dan kunci publik dipasang di server. Saat terhubung, server memeriksa bahwa Anda memegang kunci privat yang cocok dengan salah satu kunci publik yang diizinkan, lalu memberi akses tanpa kata sandi. Cara ini lebih praktis dan jauh lebih aman dibanding kata sandi: menebak kunci dengan brute force hampir mustahil. Berikut setup kunci SSH dari pembuatan sampai penonaktifan login kata sandi, beserta kesalahan yang paling sering terjadi.

Cara kerja autentikasi dengan kunci

Kuncinya bersifat asimetris. Kunci publik (id_ed25519.pub) boleh ditunjukkan kepada siapa saja — dari sana tidak mungkin direkonstruksi kunci privatnya. Kunci privat (id_ed25519) tidak pernah meninggalkan komputer Anda dan tidak dikirim melalui jaringan.

Saat login, klien memberi tahu server kunci mana yang ingin dipakai. Server mencari kunci publik itu di ~/.ssh/authorized_keys milik pengguna, dan jika ditemukan, ia meminta klien menandatangani data sesi dengan kunci privat. Tanda tangan diverifikasi dengan kunci publik, dan login diizinkan. Kata sandi sama sekali tidak dikirim.

Langkah 1. Membuat kunci: ssh-keygen

Di komputer Anda (Linux, macOS, atau Windows 10/11 dengan OpenSSH bawaan), jalankan:

ssh-keygen -t ed25519 -C "alena@laptop"

Opsi -t menentukan algoritma, -C adalah komentar yang akan ditulis di akhir kunci publik agar mudah dikenali. Ed25519 adalah algoritma modern yang direkomendasikan: kuncinya pendek, cepat, dan kuat. Jika server sangat lama dan tidak mendukung Ed25519, gunakan RSA dengan panjang minimal 3072 bit: ssh-keygen -t rsa -b 4096.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alena/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alena/.ssh/id_ed25519
Your public key has been saved in /home/alena/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xq3v0m6c1y2pVv8m3N0uYv9yQm0e6dFv5gH2rZt1aBc alena@laptop

Perlukah passphrase

Passphrase mengenkripsi kunci privat di disk. Jika laptop dicuri atau berkas bocor, tanpa passphrase kunci itu tidak berguna bagi penyerang. Untuk kunci pribadi, sebaiknya pasang passphrase, dan agar tidak perlu memasukkannya setiap kali terhubung, gunakan ssh-agent: ia menyimpan kunci yang sudah didekripsi di memori sampai sesi berakhir.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # daftar kunci yang dimuat

Kunci tanpa passphrase dapat dibenarkan untuk otomatisasi, misalnya CI atau skrip cadangan. Kunci seperti itu sebaiknya dibatasi di sisi server (dijelaskan di bawah).

Langkah 2. Menyalin kunci publik ke server: ssh-copy-id

Cara paling sederhana adalah ssh-copy-id. Ia terhubung sekali lagi dengan kata sandi, menambahkan kunci publik Anda ke ~/.ssh/authorized_keys di server, dan mengatur izin yang benar.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/alena/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
deploy@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'deploy@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

Jika server mendengarkan pada port non-standar, tambahkan -p 2222.

Jika ssh-copy-id tidak tersedia

Di Windows tidak ada utilitas ssh-copy-id. Kunci bisa dikirim secara manual dengan satu perintah:

cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Penyedia cloud biasanya meminta kunci publik saat server dibuat — kunci itu masuk ke authorized_keys melalui cloud-init.

Langkah 3. Memeriksa login

ssh deploy@203.0.113.10

Jika kata sandi tidak lagi diminta (atau hanya passphrase kunci yang diminta), semuanya berjalan. Saat pertama kali terhubung ke server baru, SSH menampilkan fingerprint kunci host dan menanyakan apakah Anda mempercayainya. Setelah Anda menjawab yes, fingerprint disimpan di ~/.ssh/known_hosts, dan selanjutnya SSH akan memberi peringatan jika kunci server berubah.

Untuk melihat kunci mana yang dicoba klien dan mengapa server menolak, jalankan koneksi dengan keluaran rinci:

ssh -v deploy@203.0.113.10

File ~/.ssh/config: nama pendek untuk server

Jika ada beberapa server, mengetik pengguna, IP, port, dan path kunci setiap kali sangat merepotkan. Semuanya bisa dideskripsikan di ~/.ssh/config:

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host bastion
    HostName bastion.example.com
    User alena

Host db-internal
    HostName 10.0.0.15
    User admin
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Sekarang cukup ketik ssh prod, dan scp, rsync, serta Git juga memahami nama-nama ini: rsync -av ./site/ prod:/var/www/.

• IdentitiesOnly yes — hanya memakai kunci yang disebutkan. Tanpa baris ini, klien mencoba semua kunci di agent, dan server bisa memutus koneksi karena batas percobaan sebelum sampai ke kunci yang benar.
• ProxyJump — terhubung ke server internal melalui server perantara (bastion) dalam satu perintah.
• ServerAliveInterval — mengirim "ping" setiap 60 detik agar koneksi tidak putus saat diam.

Izin berkas harus 600, jika tidak SSH bisa menolak membacanya: chmod 600 ~/.ssh/config.

Agent forwarding: kapan dibutuhkan dan mengapa berbahaya

Kadang dari server perlu terhubung lebih jauh — misalnya melakukan git pull dari repositori privat. Kunci privat tidak boleh disalin ke sana. Sebagai gantinya dipakai ssh -A atau ForwardAgent yes: server mendapat akses ke agent Anda selama sesi berlangsung. Namun siapa pun yang memiliki root di server itu juga bisa memakai agent Anda selama Anda terhubung. Karena itu, aktifkan forwarding hanya untuk host tepercaya, dan untuk melewati server perantara gunakan ProxyJump — ia tidak membuka agent.

Langkah 4. Menonaktifkan login kata sandi

Selama login kata sandi masih diizinkan, server tetap menjadi sasaran brute force. Setelah Anda yakin login dengan kunci berhasil, nonaktifkan kata sandi. Penting: jangan tutup sesi yang sedang berjalan sebelum Anda menguji login di jendela baru, agar akses tidak hilang.

Buka /etc/ssh/sshd_config (atau buat berkas di /etc/ssh/sshd_config.d/ jika konfigurasi utama memuatnya dengan direktif Include), lalu atur:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no melarang login sebagai root sama sekali: administrator masuk dengan pengguna masing-masing dan menaikkan hak akses dengan sudo. Jika tetap perlu login root, gunakan PermitRootLogin prohibit-password — hanya dengan kunci.

Periksa sintaks dan muat ulang layanan:

sudo sshd -t
sudo systemctl reload ssh      # di Debian/Ubuntu; di keluarga RHEL — sshd

Perintah sshd -t tidak menampilkan apa-apa jika konfigurasinya benar. Sekarang di terminal baru, pastikan login dengan kunci berhasil, dan login dengan kata sandi ditolak server:

$ ssh -o PubkeyAuthentication=no deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey).

Perlindungan tambahan

Menonaktifkan kata sandi adalah langkah utama. Setelah itu biasanya akses ke port 22 dibatasi dengan firewall (ufw allow from 198.51.100.0/24 to any port 22) dan dipasang fail2ban, yang memblokir IP setelah beberapa percobaan gagal. Status perlindungan SSH ditampilkan oleh sudo fail2ban-client status sshd.

Kunci untuk otomatisasi bisa dibatasi langsung di authorized_keys dengan opsi sebelum kunci: misalnya from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup hanya mengizinkan login dari satu alamat dan tanpa shell interaktif.

Kesalahan umum dan cara memperbaikinya

Permission denied (publickey)

Ini kesalahan yang paling sering. Penyebabnya, dari yang paling umum:

1. Izin yang salah di server. sshd mengabaikan authorized_keys jika direktori atau berkasnya bisa ditulis oleh pihak lain. Perbaikan: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, dan direktori home tidak boleh bisa ditulis oleh grup maupun pihak lain.
2. Pemilik yang salah. Jika berkas dibuat dengan sudo, pemiliknya root. Perbaikan: sudo chown -R deploy:deploy /home/deploy/.ssh.
3. Kunci dipasang untuk pengguna lain. Anda menyalin kunci untuk root, tetapi login sebagai deploy, atau sebaliknya.
4. Klien menawarkan kunci yang salah. Lihat ssh -v: baris Offering public key menunjukkan kunci apa saja yang dicoba. Tentukan kunci yang benar dengan -i atau IdentityFile.
5. Kunci rusak saat disalin. Kunci publik harus berupa satu baris. Pindah baris dari clipboard akan merusaknya.

Penyebab penolakan di sisi server terlihat di log: sudo journalctl -u ssh -n 30 (di RHEL — -u sshd). Di sana sering muncul baris seperti Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

UNPROTECTED PRIVATE KEY FILE

Klien menolak memakai kunci privat yang bisa dibaca pengguna lain. Perbaikan: chmod 600 ~/.ssh/id_ed25519.

REMOTE HOST IDENTIFICATION HAS CHANGED

Kunci host tidak cocok dengan yang tersimpan di known_hosts. Ini terjadi setelah server diinstal ulang atau IP-nya berubah, tetapi tampilan yang sama juga muncul pada serangan "man-in-the-middle". Pastikan memang server itu yang dibuat ulang, lalu hapus entri lama: ssh-keygen -R 203.0.113.10.

Too many authentication failures

Agent menawarkan terlalu banyak kunci ke server, dan server menutup koneksi karena MaxAuthTries. Solusinya adalah IdentitiesOnly yes dan IdentityFile yang eksplisit di ~/.ssh/config.

Kesimpulan

Setup kunci SSH memakan waktu lima menit: ssh-keygen -t ed25519, ssh-copy-id, memeriksa login, lalu PasswordAuthentication no dan memuat ulang sshd sambil sesi kedua tetap terbuka. Berkas ~/.ssh/config menghemat perintah panjang, dan izin 700/600 menyelesaikan sebagian besar error "Permission denied". SSH, rsync, serta perlindungan server dengan firewall dan fail2ban dibahas dengan praktik dalam kursus Linux.