Cara Menambahkan SSH Keys ke VPS Baru atau yang Sudah Ada

Kunci SSH adalah pasangan kunci kriptografi — sebuah kunci publik yang disimpan di server dan sebuah kunci privat yang disimpan di mesin lokal Anda — yang mengautentikasi identitas Anda tanpa mengirimkan kata sandi melalui jaringan. Saat Anda terhubung, server mengeluarkan tantangan kriptografi yang hanya dapat diselesaikan oleh kunci privat Anda, memberikan akses jika responsnya valid. Mekanisme ini membuat autentikasi kunci SSH secara fundamental lebih tahan terhadap serangan brute-force, credential stuffing, dan intersepsi man-in-the-middle dibandingkan skema berbasis kata sandi mana pun.

Panduan ini mencakup proses lengkap pembuatan, penerapan, dan penguatan autentikasi kunci SSH pada instans VPS baru maupun yang sudah ada — termasuk kasus tepi, jebakan izin, dan manajemen multi-kunci yang sebagian besar tutorial lewatkan sepenuhnya.

Mengapa Kunci SSH Secara Arsitektur Lebih Unggul dari Kata Sandi

Autentikasi kata sandi mengirimkan rahasia (atau hash-nya) melalui jaringan dan bergantung pada server yang menyimpan kredensial yang dapat diverifikasi. Autentikasi kunci publik SSH tidak pernah mengekspos kunci privat — tidak selama pembuatan, tidak selama login, tidak pernah. Kunci privat tidak pernah meninggalkan mesin lokal Anda.

Di luar keamanan dasar, kunci SSH membuka kemampuan operasional yang tidak dapat dilakukan oleh kata sandi:

• Otomasi tanpa pengawasan — Pipeline CI/CD, playbook Ansible, dan pekerjaan rsync berbasis cron memerlukan autentikasi non-interaktif. Kata sandi sepenuhnya merusak hal ini.
• Kontrol akses terperinci — Setiap entri authorized_keys dapat membawa pembatasan command=, from=, dan no-pty, membatasi dengan tepat apa yang diizinkan dilakukan oleh kunci tertentu.
• Kemampuan audit — Kunci individual dapat dicabut tanpa mengubah kata sandi bersama dan mengganggu setiap pengguna atau skrip lainnya.
• Ketahanan terhadap phishing — Tidak ada kata sandi yang dapat dicuri melalui halaman login palsu.

Prasyarat

Sebelum melanjutkan, konfirmasikan hal-hal berikut:

• Anda memiliki VPS yang berjalan atau sedang dalam proses penyediaan.
• Mesin lokal Anda menjalankan Linux, macOS, atau Windows dengan OpenSSH terinstal (Windows 10/11 sudah dilengkapi OpenSSH secara default; verifikasi dengan ssh -V).
• Anda memiliki akses root atau sudo ke server target.
• Anda memahami bahwa kehilangan kunci privat Anda tanpa metode login alternatif (akses konsol, kunci pemulihan) dapat mengunci Anda secara permanen.

Memilih Algoritma Kunci yang Tepat

Perintah ssh-keygen -t rsa -b 4096 asli sudah solid tetapi bukan satu-satunya pilihan. Memahami trade-off membantu Anda membuat pilihan yang tepat untuk lingkungan Anda.

Ed25519 adalah algoritma yang direkomendasikan untuk server mana pun yang menjalankan OpenSSH 6.5 atau lebih baru (dirilis 2014). Gunakan RSA 4096 hanya saat terhubung ke sistem lama yang tidak mendukung kunci elliptic-curve.

Bagian 1: Menambahkan Kunci SSH ke VPS Baru

Banyak panel kontrol hosting memungkinkan Anda menyuntikkan kunci publik pada saat penyediaan, sebelum instans pernah melakukan boot. Ini adalah pendekatan paling bersih — kunci sudah tertanam dalam image dan autentikasi kata sandi mungkin tidak perlu diaktifkan sama sekali.

Langkah 1: Buat Pasangan Kunci SSH Anda

Buka terminal di mesin lokal Anda. Buat pasangan kunci Ed25519:

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

Jika Anda memerlukan RSA untuk alasan kompatibilitas:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Saat diminta lokasi file, tekan Enter untuk menerima default (~/.ssh/id_ed25519 atau ~/.ssh/id_rsa). Saat diminta passphrase, tetapkan satu — ini mengenkripsi kunci privat di disk, sehingga meskipun laptop Anda dicuri, kunci tersebut tidak berguna tanpa passphrase. Agen SSH Anda (ssh-agent) akan menyimpan kunci yang didekripsi dalam memori sehingga Anda hanya mengetik passphrase sekali per sesi.

Verifikasi file yang dihasilkan:

ls -la ~/.ssh/

Anda akan melihat:

• id_ed25519 — kunci privat Anda (izin harus 600; jangan pernah bagikan file ini)
• id_ed25519.pub — kunci publik Anda (aman untuk disalin ke mana saja)

Tampilkan kunci publik untuk menyalinnya:

cat ~/.ssh/id_ed25519.pub

Outputnya terlihat seperti:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

Salin seluruh string ini — Anda akan menempelkannya ke panel hosting Anda.

Langkah 2: Tambahkan Kunci Publik Selama Penyediaan VPS

Masuk ke panel kontrol hosting Anda. Selama alur kerja pembuatan VPS:

1. Pilih sistem operasi Anda (Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9, dll.).
2. Temukan bagian Kunci SSH atau Autentikasi.
3. Tempelkan seluruh isi id_ed25519.pub ke dalam kolom yang disediakan.
4. Selesaikan konfigurasi yang tersisa (paket, wilayah, nama host).

Setelah VPS melakukan boot, sistem penyediaan menulis kunci publik Anda ke /root/.ssh/authorized_keys secara otomatis. Tidak diperlukan login kata sandi.

Langkah 3: Hubungkan ke VPS yang Baru Disediakan

ssh root@your_vps_ip

Jika Anda menggunakan nama file kunci non-default, tentukan secara eksplisit:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Koneksi yang berhasil tanpa prompt kata sandi mengonfirmasi bahwa kunci telah disuntikkan dengan benar. Jika Anda menetapkan passphrase, agen SSH atau prompt passphrase akan menanganinya secara lokal.

Bagian 2: Menambahkan Kunci SSH ke VPS yang Sudah Ada

Jika VPS Anda sudah berjalan dengan autentikasi kata sandi, Anda perlu menerapkan kunci publik secara manual. Ini adalah proses dua fase: salin kunci, lalu opsional perkuat daemon SSH.

Langkah 1: Buat Pasangan Kunci (Jika Anda Belum Memilikinya)

Ikuti proses yang sama seperti Langkah 1 di Bagian 1 di atas. Jika Anda sudah memiliki pasangan kunci, ambil kunci publik Anda:

cat ~/.ssh/id_ed25519.pub

Langkah 2: Salin Kunci Publik ke Server

Metode A — ssh-copy-id (Direkomendasikan)

Utilitas ssh-copy-id menangani pembuatan direktori, penambahan file, dan pengaturan izin secara otomatis:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip

Masukkan kata sandi Anda saat diminta. Alat ini menambahkan kunci ke ~/.ssh/authorized_keys di server jarak jauh dan menetapkan izin yang benar. Ini adalah metode paling aman karena mencegah penimpaan kunci yang sudah ada secara tidak sengaja.

Metode B — Penerapan Manual

Gunakan ini ketika ssh-copy-id tidak tersedia (misalnya, di beberapa lingkungan Windows atau jaringan yang dibatasi):

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

Pipeline tunggal ini lebih aman daripada membuka editor teks di server jarak jauh karena menambahkan daripada menimpa.

Metode C — Manual melalui Editor Teks (Cadangan)

Masuk ke server dengan kata sandi Anda:

ssh root@your_vps_ip

Buat direktori .ssh jika belum ada:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Buka authorized_keys di editor teks:

nano ~/.ssh/authorized_keys

Tempelkan kunci publik Anda pada baris baru. Simpan dengan Ctrl+X, lalu Y, lalu Enter. Tetapkan izin:

chmod 600 ~/.ssh/authorized_keys

Keluar dari sesi:

exit

Langkah 3: Verifikasi Login Berbasis Kunci

Uji koneksi sebelum membuat perubahan lebih lanjut pada daemon SSH. Buka jendela terminal baru (jangan tutup sesi Anda yang sudah ada):

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Jika Anda terhubung tanpa prompt kata sandi, kunci berfungsi. Lanjutkan ke langkah penguatan di bawah hanya setelah mengonfirmasi ini.

Jebakan kritis: Jika Anda menonaktifkan autentikasi kata sandi sebelum memverifikasi akses kunci, dan penerapan kunci gagal karena alasan apa pun, Anda akan mengunci diri sendiri. Selalu uji terlebih dahulu.

Langkah 4: Perkuat Konfigurasi Daemon SSH

Setelah akses berbasis kunci dikonfirmasi, buka file konfigurasi daemon SSH:

nano /etc/ssh/sshd_config

Terapkan pengaturan berikut:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes

Catatan penting tentang direktif ini:

• PermitRootLogin prohibit-password mengizinkan login root melalui kunci tetapi memblokir login kata sandi root — jalan tengah yang lebih baik daripada PermitRootLogin no saat Anda masih menyiapkan pengguna sudo non-root.
• ChallengeResponseAuthentication no menonaktifkan autentikasi keyboard-interaktif, yang dapat melewati PasswordAuthentication no pada beberapa konfigurasi PAM.
• Di Ubuntu 22.04+, file /etc/ssh/sshd_config.d/50-cloud-init.conf mungkin menimpa pengaturan Anda. Periksa dan edit jika perlu.

Validasi sintaks konfigurasi sebelum memulai ulang:

sshd -t

Jika tidak ada kesalahan yang dilaporkan, mulai ulang layanan SSH:

systemctl restart sshd

Pada sistem yang menggunakan ssh.service alih-alih sshd.service:

systemctl restart ssh

Mengelola Beberapa Kunci SSH dan Pengguna

Lingkungan dunia nyata jarang melibatkan satu kunci dan satu pengguna. Berikut cara menangani skenario yang lebih kompleks.

Menambahkan Kunci untuk Beberapa Pengguna

Setiap akun pengguna memiliki file ~/.ssh/authorized_keys-nya sendiri. Untuk menambahkan kunci untuk pengguna non-root bernama deploy:

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
echo "ssh-ed25519 AAAAC3... deploy@ci-server" >> /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Langkah chown sering terlewat dan menyebabkan kegagalan autentikasi — SELinux dan OpenSSH keduanya memverifikasi bahwa file authorized_keys dimiliki oleh pengguna yang mengautentikasi.

Membatasi Apa yang Dapat Dilakukan Kunci

Anda dapat menambahkan prefiks opsi pada baris mana pun di authorized_keys untuk membatasi kemampuannya. Ini sangat berguna untuk kunci deployment atau otomasi backup:

command="/usr/bin/rsync --server --daemon .",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3... backup@monitoring

Kunci ini hanya dapat menjalankan rsync dalam mode daemon — tidak ada yang lain.

Menggunakan ~/.ssh/config untuk Koneksi yang Lebih Bersih

Alih-alih mengetik perintah ssh yang panjang, tentukan alias host di mesin lokal Anda:

Host myserver
    HostName 203.0.113.45
    User root
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Setelah menyimpan ini ke ~/.ssh/config, hubungkan hanya dengan:

ssh myserver

Menggunakan ssh-agent untuk Menyimpan Cache Passphrase

Jika kunci privat Anda memiliki passphrase (seharusnya demikian), tambahkan ke agen agar Anda tidak diminta berulang kali:

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

Di macOS, tambahkan --apple-use-keychain untuk bertahan setelah reboot:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Jebakan Umum dan Pemecahan Masalah

Masalah: Masih diminta kata sandi setelah menambahkan kunci

Jalankan koneksi dengan output verbose untuk mendiagnosis:

ssh -vvv root@your_vps_ip

Cari baris seperti Offering public key dan Server accepts key. Jika kunci ditawarkan tetapi ditolak, masalahnya hampir selalu izin file di server.

Periksa izin di server:

ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

Izin yang diperlukan:

• ~/.ssh/ — 700 (drwx——)
• ~/.ssh/authorized_keys — 600 (-rw——-)
• Direktori home ~/ — tidak boleh dapat ditulis oleh semua orang (755 atau 750)

Masalah: SELinux memblokir autentikasi di RHEL/Rocky/AlmaLinux

restorecon -Rv ~/.ssh

Masalah: File authorized_keys memiliki akhiran baris Windows (CRLF)

Jika Anda mengedit file di Windows dan mentransfernya, akhiran baris mungkin rusak. Perbaiki dengan:

sed -i 's/r//' ~/.ssh/authorized_keys

Masalah: Kunci yang salah ditawarkan

Jika Anda memiliki beberapa kunci, tentukan yang benar secara eksplisit:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Atau konfigurasikan di ~/.ssh/config seperti yang ditunjukkan di atas.

Kunci SSH dalam Konteks Infrastruktur Hosting Anda

Autentikasi kunci SSH bukan hanya masalah satu server — ini berskala di seluruh infrastruktur Anda. Jika Anda mengelola armada server dedicated, pendekatan terpusat menggunakan alat seperti Ansible, Puppet, atau manajer rahasia (HashiCorp Vault, AWS Secrets Manager) untuk mendistribusikan dan merotasi kunci yang diotorisasi sangatlah penting.

Untuk tim yang menjalankan aplikasi web di VPS dengan cPanel, antarmuka Akses SSH cPanel di bawah bagian Keamanan menyediakan GUI untuk membuat dan mengelola pasangan kunci — berguna bagi pengembang yang tidak nyaman dengan baris perintah tetapi masih memerlukan akses yang aman.

Jika Anda menjalankan beban kerja intensif GPU di infrastruktur GPU hosting, autentikasi kunci SSH sangat penting karena instans ini sering menjalankan pekerjaan tanpa pengawasan yang berjalan lama. Kredensial yang dikompromikan di server GPU dapat mengakibatkan biaya komputasi tidak sah yang signifikan selain eksposur data.

Memadukan penguatan SSH dengan sertifikat SSL yang valid pada layanan yang menghadap web yang berjalan di server yang sama menutup dua vektor serangan paling umum secara bersamaan — akses shell yang tidak terautentikasi dan lalu lintas HTTP yang tidak terenkripsi.

Untuk proyek yang menggunakan web hosting bersama yang juga memerlukan akses SSH, periksa apakah penyedia Anda mendukung injeksi kunci SSH melalui panel hosting, karena lingkungan bersama sering membatasi SSH untuk pengguna tertentu dengan akses shell terbatas.

Rotasi Kunci dan Manajemen Kunci Jangka Panjang

Kunci SSH tidak kedaluwarsa secara otomatis. Tanpa kebijakan rotasi, kunci yang dikompromikan bertahun-tahun lalu mungkin masih memberikan akses. Tetapkan praktik-praktik ini:

• Rotasi kunci setiap tahun atau segera setelah ada kecurigaan kompromi.
• Audit file authorized_keys di semua server secara berkala. Hapus kunci milik mantan karyawan atau layanan yang sudah dinonaktifkan.
• Gunakan kunci terpisah per perangkat — jangan salin kunci privat yang sama ke beberapa laptop atau server. Jika satu perangkat hilang, Anda hanya mencabut kunci tersebut.
• Gunakan kunci terpisah per peran — kunci akses pribadi Anda, kunci deployment CI/CD Anda, dan kunci otomasi backup Anda semuanya harus berbeda.
• Dokumentasikan kepemilikan kunci — pertahankan registri yang memetakan setiap sidik jari kunci publik ke pemiliknya, tujuan, dan tanggal kedaluwarsa.

Untuk menampilkan sidik jari kunci untuk audit:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Daftar Periksa Keputusan Teknis

Gunakan matriks ini sebelum menyelesaikan pengaturan kunci SSH Anda:

• Algoritma: Gunakan Ed25519 kecuali terhubung ke sistem yang lebih lama dari OpenSSH 6.5; gunakan RSA 4096 sebagai cadangan.
• Passphrase: Selalu tetapkan satu pada kunci privat yang digunakan oleh manusia; kunci layanan yang digunakan oleh otomasi dapat mengabaikannya jika disimpan dalam manajer rahasia.
• Metode penerapan: Gunakan ssh-copy-id untuk pengaturan interaktif; gunakan manajemen konfigurasi (Ansible, Puppet) untuk penerapan armada.
• Verifikasi izin: Konfirmasi 700 pada ~/.ssh/, 600 pada authorized_keys, dan kepemilikan yang benar sebelum menonaktifkan autentikasi kata sandi.
• Uji sebelum mengunci: Selalu verifikasi login kunci di sesi terminal terpisah sebelum menetapkan PasswordAuthentication no.
• Validasi konfigurasi daemon: Jalankan sshd -t sebelum memulai ulang layanan SSH untuk menangkap kesalahan sintaks.
• Nonaktifkan autentikasi kata sandi: Tetapkan PasswordAuthentication no dan ChallengeResponseAuthentication no bersama-sama — satu saja tidak cukup pada sistem yang mengaktifkan PAM.
• Kebijakan login root: Lebih suka PermitRootLogin prohibit-password daripada PermitRootLogin yes; migrasikan ke pengguna sudo non-root dan tetapkan PermitRootLogin no sebagai status akhir yang diperkuat.
• Rotasi kunci: Jadwalkan rotasi tahunan; cabut segera saat perangkat hilang atau perubahan personel.
• Audit: Secara berkala jalankan grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys untuk meninjau semua kunci yang diotorisasi di seluruh sistem.

FAQ

Bisakah saya menambahkan beberapa kunci SSH ke server yang sama?

Ya. Setiap baris di ~/.ssh/authorized_keys mewakili satu kunci publik yang diotorisasi. Anda dapat menambahkan sebanyak mungkin kunci yang diperlukan — satu per baris. Ini memungkinkan beberapa administrator atau beberapa perangkat untuk mengautentikasi secara independen, dan Anda dapat mencabut kunci tunggal mana pun dengan menghapus barisnya tanpa mempengaruhi yang lain.

Apa yang terjadi jika saya kehilangan kunci privat setelah menonaktifkan autentikasi kata sandi?

Anda akan terkunci dari SSH. Pemulihan memerlukan akses ke server melalui metode out-of-band: konsol web penyedia hosting Anda, VNC, atau lingkungan boot rescue/recovery. Dari sana Anda dapat mengaktifkan kembali autentikasi kata sandi atau menambahkan kunci publik baru. Inilah mengapa menjaga kredensial akses konsol tetap aman dan terpisah sangatlah penting.

Apakah Ed25519 didukung di semua server?

Ed25519 memerlukan OpenSSH 6.5 atau lebih baru, dirilis pada Januari 2014. Server mana pun yang menjalankan distribusi Linux modern (Ubuntu 18.04+, Debian 9+, CentOS 7+, Rocky Linux 8+) mendukungnya. Satu-satunya skenario yang memerlukan RSA adalah terhubung ke sistem lama yang benar-benar usang atau perangkat tertanam dengan build OpenSSH yang sudah ketinggalan zaman.

Apakah menambahkan kunci SSH secara otomatis menonaktifkan login kata sandi?

Tidak. Menambahkan kunci ke authorized_keys mengaktifkan login berbasis kunci tetapi tidak menonaktifkan autentikasi kata sandi. Anda harus secara eksplisit menetapkan PasswordAuthentication no di /etc/ssh/sshd_config dan memulai ulang daemon SSH untuk memberlakukan akses hanya dengan kunci.

Bisakah saya menggunakan pasangan kunci SSH yang sama untuk beberapa server?

Secara teknis ya, tetapi tidak direkomendasikan untuk lingkungan produksi. Menggunakan satu kunci di banyak server berarti mengkompromikan satu kunci privat memberikan akses ke semuanya. Praktik yang lebih baik adalah menggunakan kunci per perangkat (satu kunci per workstation atau laptop) sehingga kehilangan perangkat hanya memerlukan pencabutan kunci tersebut di seluruh armada server Anda, bukan mengganti kunci di mana-mana secara bersamaan.