Cara Mengunggah SSH Public Key ke VPS yang Sudah Ada

Kunci publik SSH adalah kredensial kriptografi yang disimpan di ~/.ssh/authorized_keys pada server jarak jauh yang memberikan akses kepada klien mana pun yang memegang kunci privat yang sesuai — tanpa mengirimkan kata sandi melalui jaringan. Mengunggah kunci publik Anda ke VPS yang sudah ada menggantikan atau melengkapi autentikasi berbasis kata sandi dengan kriptografi asimetris, menghilangkan permukaan serangan yang dieksploitasi oleh kampanye brute-force dan credential-stuffing.

Panduan ini mencakup setiap tahap proses: pembuatan kunci, metode unggah manual dan otomatis, penguatan izin, penyetelan sshd_config, manajemen multi-kunci, dan mode kegagalan umum yang sering menjebak bahkan administrator berpengalaman sekalipun.

Mengapa Autentikasi Kunci SSH Lebih Unggul dari Kata Sandi

Sebelum menyentuh satu perintah pun, ada baiknya memahami mekanisme kriptografinya. Saat Anda mengautentikasi dengan pasangan kunci, server mengeluarkan tantangan yang dienkripsi dengan kunci publik Anda. Hanya pemegang kunci privat yang cocok yang dapat mendekripsi dan menandatangani respons tersebut. Tidak ada rahasia yang pernah dikirimkan — bandingkan ini dengan autentikasi kata sandi, di mana kredensial itu sendiri berpindah melalui jaringan (meskipun dibungkus TLS).

Kesimpulan praktisnya: pada lingkungan VPS Hosting mana pun yang terekspos ke internet publik, kunci SSH bukan sekadar penguatan opsional — melainkan standar dasar.

Prasyarat

• VPS yang sudah ada dan dapat dijangkau melalui SSH (login dengan kata sandi atau kunci yang sudah ada saat ini berfungsi)
• Mesin lokal yang menjalankan Linux, macOS, atau Windows dengan OpenSSH atau PuTTY
• Hak istimewa yang cukup pada VPS untuk menulis ke direktori home pengguna target
• Kenyamanan dasar dengan terminal dan editor teks seperti nano atau vim

Langkah 1: Buat Pasangan Kunci SSH

Jika Anda sudah memiliki pasangan kunci di ~/.ssh/id_ed25519 atau ~/.ssh/id_rsa, lewati bagian ini. Jika tidak, buat sekarang.

Memilih Algoritma yang Tepat

Ed25519 adalah standar modern. Gunakan RSA 4096 hanya saat terhubung ke server lama yang tidak mendukung Ed25519.

Buat pasangan kunci Ed25519:

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

Buat pasangan kunci RSA 4096 (sistem lama):

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

Selama pembuatan kunci, Anda akan diminta untuk memasukkan jalur penyimpanan dan passphrase opsional. Menerima jalur default (~/.ssh/id_ed25519) sudah cukup untuk sebagian besar pengguna. Selalu tetapkan passphrase — ini mengenkripsi kunci privat di disk menggunakan AES-256, sehingga laptop yang dicuri tidak secara otomatis berarti server yang dikompromikan.

Proses ini menghasilkan dua file:

~/.ssh/id_ed25519 — kunci privat Anda. Jangan pernah membagikan ini, jangan pernah menyalinnya ke server, jangan pernah memasukkannya ke version control.
~/.ssh/id_ed25519.pub — kunci publik Anda. Ini aman untuk didistribusikan secara bebas.

Tampilkan kunci publik agar dapat Anda salin:
cat ~/.ssh/id_ed25519.pub
Outputnya akan terlihat seperti:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com
Salin seluruh string satu baris termasuk awalan algoritma dan komentar di akhir.
Langkah 2: Masuk ke VPS Anda
Hubungkan ke VPS menggunakan metode autentikasi Anda saat ini:
ssh root@your_vps_ip
Ganti your_vps_ip dengan alamat IPv4 atau IPv6 aktual server Anda. Jika Anda mengelola akun pengguna non-root, ganti root dengan nama pengguna yang sesuai. Pada Dedicated Servers di mana Anda mungkin memiliki beberapa akun pengguna, selalu utamakan penerapan kunci ke pengguna non-root dan gunakan sudo untuk eskalasi hak istimewa.
Langkah 3: Siapkan Direktori .ssh
Setelah masuk, verifikasi atau buat direktori .ssh untuk pengguna target:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
Izin 700 (rwx------) bersifat wajib. OpenSSH akan diam-diam menolak menggunakan authorized_keys jika direktori .ssh dapat ditulis oleh grup atau semua orang. Ini adalah salah satu alasan paling umum mengapa autentikasi kunci gagal setelah pengaturan yang sebenarnya sudah benar.
Langkah 4: Tambahkan Kunci Publik ke authorized_keys
Metode A: Tempel Manual (Universal)
Buka atau buat file authorized_keys:
nano ~/.ssh/authorized_keys
Tempel kunci publik Anda pada baris baru. Setiap baris dalam file ini mewakili satu kunci yang diotorisasi. Simpan dengan Ctrl+X, lalu Y, lalu Enter.
Tetapkan izin yang benar:
chmod 600 ~/.ssh/authorized_keys
Izin 600 (rw-------) memastikan hanya pemilik file yang dapat membaca atau menulisnya. OpenSSH memberlakukan ini secara ketat.
Metode B: ssh-copy-id (Direkomendasikan untuk Kecepatan)
Jika mesin lokal Anda memiliki ssh-copy-id yang tersedia (standar di Linux dan macOS), perintah tunggal ini menangani pembuatan direktori, penambahan kunci, dan pengaturan izin secara otomatis:
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip
Anda akan diminta memasukkan kata sandi SSH saat ini sekali. Setelah itu, login berbasis kunci aktif. Flag -i secara eksplisit menentukan kunci publik mana yang akan diunggah, mencegah pengunggahan kunci yang salah secara tidak sengaja.
Metode C: One-Liner melalui cat dan Pipe (Dapat Diotomatisasi)
Berguna dalam pipeline otomatisasi atau ketika ssh-copy-id tidak tersedia:
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"
Pendekatan ini aman secara idempoten dalam artian bahwa ia menambahkan daripada menimpa, sehingga kunci yang sudah diotorisasi tetap terjaga.
Langkah 5: Verifikasi Kepemilikan File yang Benar
Jebakan yang sering diabaikan: jika Anda membuat direktori .ssh atau file authorized_keys sebagai root saat menyiapkan akun pengguna lain, kepemilikannya akan salah dan SSH akan menolak kunci tersebut secara diam-diam.
Periksa kepemilikan:
ls -la ~/.ssh/
Output harus menampilkan nama pengguna target sebagai pemilik dan grup untuk direktori maupun file:
drwx------ 2 alice alice 4096 Jan 15 10:00 .ssh
-rw------- 1 alice alice  571 Jan 15 10:00 .ssh/authorized_keys
Jika kepemilikan salah, perbaiki (jalankan sebagai root):
chown -R alice:alice /home/alice/.ssh
Langkah 6: Uji Login Kunci SSH
Keluar dari sesi saat ini:
exit
Hubungkan kembali menggunakan spesifikasi kunci eksplisit untuk mengonfirmasi pengaturan:
ssh -i ~/.ssh/id_ed25519 root@your_vps_ip
Jika login berhasil tanpa prompt kata sandi (atau hanya meminta passphrase kunci lokal Anda), konfigurasi sudah benar. Jika masih meminta kata sandi server, lanjutkan ke bagian pemecahan masalah di bawah.
Langkah 7: Perkuat Konfigurasi SSH Daemon
Setelah login berbasis kunci dikonfirmasi berfungsi, nonaktifkan autentikasi kata sandi untuk sepenuhnya menghilangkan vektor serangan brute-force kata sandi.
Buka file konfigurasi SSH daemon:
nano /etc/ssh/sshd_config
Temukan dan tetapkan direktif berikut. Jika sebuah baris dikomentari dengan #, hapus # dan tetapkan nilainya:
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes
Catatan tentang PermitRootLogin prohibit-password: pengaturan ini mengizinkan login root secara eksklusif melalui kunci, memblokir akses root berbasis kata sandi sambil tetap mengizinkan sesi root yang terautentikasi dengan kunci. Untuk penguatan maksimal, tetapkan ke no dan gunakan pengguna non-root dengan sudo.
Pada beberapa distribusi, file konfigurasi drop-in sekunder mungkin menimpa pengaturan Anda. Periksa adanya penimpaan:
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
Jika ada file di direktori tersebut yang menetapkan PasswordAuthentication yes, edit atau hapus file tersebut.
Validasi sintaks konfigurasi sebelum memulai ulang:
sshd -t
Output yang bersih (tanpa kesalahan) berarti aman untuk memuat ulang. Terapkan perubahan:
systemctl restart sshd
Peringatan penting: Jangan tutup sesi SSH Anda yang ada sebelum membuka terminal kedua dan mengonfirmasi bahwa Anda masih dapat login dengan kunci Anda. Memulai ulang sshd dengan file yang salah dikonfigurasi atau sebelum kunci Anda berfungsi akan mengunci Anda. Sebagian besar VPS Control Panels menyediakan konsol darurat (akses KVM/VNC) untuk pemulihan, tetapi jauh lebih baik untuk menghindari situasi tersebut sepenuhnya.
Langkah 8: Kelola Beberapa Kunci dan Server dengan ~/.ssh/config
Saat mengelola beberapa server — umum di lingkungan staging/production atau saat mengelola beberapa Dedicated Servers — file konfigurasi klien SSH menghilangkan kebutuhan untuk mengingat alamat IP, nama pengguna, dan jalur kunci.
Buat atau edit ~/.ssh/config di mesin lokal Anda:
nano ~/.ssh/config
Contoh konfigurasi untuk beberapa host:
Host production-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host staging-vps
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    Port 2222

Host legacy-server
    HostName 203.0.113.30
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    PubkeyAcceptedKeyTypes +ssh-rsa
Tetapkan izin yang benar pada file konfigurasi:
chmod 600 ~/.ssh/config
Anda sekarang dapat terhubung dengan alias yang bersih:
ssh production-vps
ssh staging-vps
Direktif PubkeyAcceptedKeyTypes +ssh-rsa pada entri lama itu penting: klien OpenSSH yang lebih baru (8.8+) menonaktifkan RSA-SHA1 secara default. Tanpa penimpaan ini, koneksi ke server yang lebih lama akan gagal dengan kesalahan “no matching host key type” yang membingungkan.
Pemecahan Masalah: Mengapa Autentikasi Kunci SSH Gagal
Bahkan dengan pengaturan yang benar, beberapa faktor lingkungan dapat menyebabkan autentikasi kunci diam-diam kembali ke prompt kata sandi:
Izin salah pada .ssh atau authorized_keys:
Jalankan ls -la ~/.ssh/ di server. Direktori harus 700 dan file harus 600. Izin yang lebih longgar menyebabkan OpenSSH mengabaikan file tersebut.
Ketidakcocokan konteks SELinux atau AppArmor:
Pada sistem RHEL/CentOS/AlmaLinux dengan SELinux yang diberlakukan, file authorized_keys mungkin memiliki konteks keamanan yang salah. Pulihkan dengan:
restorecon -Rv ~/.ssh
Direktori home pengguna yang salah:
Jika direktori home pengguna tidak hanya dapat ditulis oleh pemiliknya, SSH akan menolak autentikasi kunci. Periksa dengan:
ls -ld ~
Direktori home itu sendiri tidak boleh dapat ditulis oleh grup atau semua orang.
Direktif AuthorizedKeysFile menunjuk ke tempat lain:
Beberapa distribusi mengonfigurasi AuthorizedKeysFile untuk menggunakan jalur non-standar (misalnya, /etc/ssh/authorized_keys/%u). Verifikasi pengaturan aktif:
sshd -T | grep authorizedkeysfile
Beberapa kunci dan konflik ssh-agent:
Jika ssh-agent berjalan dengan beberapa kunci yang dimuat, server mungkin menolak koneksi setelah terlalu banyak percobaan kunci yang gagal sebelum mencoba yang benar. Gunakan -i untuk menentukan kunci secara eksplisit, atau konfigurasikan IdentitiesOnly yes di ~/.ssh/config.
Firewall atau fail2ban memblokir IP Anda:
Jika Anda sebelumnya telah gagal beberapa kali percobaan login, aturan fail2ban atau ufw/iptables mungkin telah sementara melarang IP Anda. Periksa dengan:
fail2ban-client status sshd
Merotasi dan Mencabut Kunci SSH
Rotasi kunci adalah praktik kebersihan keamanan yang sering diabaikan. Untuk mencabut kunci tertentu, buka ~/.ssh/authorized_keys di server dan hapus baris yang sesuai. Setiap baris adalah satu kunci — menghapusnya segera mencabut akses bagi pemegang kunci privat tersebut tanpa memengaruhi kunci yang diotorisasi lainnya.
Untuk tujuan audit, gunakan komentar yang berbeda pada setiap kunci (bagian setelah materi kunci, misalnya, alice@workstation-2024) sehingga Anda dapat mengidentifikasi kunci mana yang milik orang atau perangkat mana. Ketika seorang karyawan pergi atau perangkat dinonaktifkan, temukan kunci mereka berdasarkan komentar dan hapus.
Untuk merotasi kunci Anda sendiri, buat pasangan baru, tambahkan kunci publik baru ke authorized_keys, verifikasi bahwa login berfungsi dengan kunci baru, lalu hapus entri kunci lama.
Daftar Periksa Poin-Poin Praktis

Buat kunci Ed25519 secara default; gunakan RSA 4096 hanya untuk kompatibilitas server lama
Selalu lindungi kunci privat Anda dengan passphrase yang kuat
Gunakan ssh-copy-id untuk penerapan kunci yang cepat dan bebas kesalahan jika memungkinkan
Verifikasi izin direktori .ssh adalah 700 dan authorized_keys adalah 600

FAQ

Bisakah saya menambahkan beberapa kunci publik SSH ke akun pengguna VPS yang sama?

Ya. Setiap baris dalam ~/.ssh/authorized_keys adalah kunci yang diotorisasi secara independen. Tambahkan satu kunci per baris. Ini adalah pendekatan standar untuk memberikan akses kepada beberapa administrator atau dari beberapa perangkat — setiap orang atau perangkat memegang kunci privat yang unik, dan pencabutan dilakukan per baris.

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

Anda akan terkunci dari SSH. Pemulihan memerlukan penggunaan akses konsol out-of-band dari penyedia hosting Anda (KVM/VNC), yang tersedia melalui sebagian besar panel kontrol VPS Hosting. Dari konsol, aktifkan kembali PasswordAuthentication yes di /etc/ssh/sshd_config, mulai ulang sshd, dan unggah kunci baru. Inilah mengapa menguji login kunci sebelum menonaktifkan kata sandi adalah hal yang tidak bisa ditawar.

Apakah Ed25519 didukung di semua server?

Ed25519 memerlukan OpenSSH 6.5 atau yang lebih baru (dirilis 2014). Distribusi Linux modern mana pun — Ubuntu 18.04+, Debian 9+, CentOS 7+, AlmaLinux 8+ — mendukungnya secara native. Hanya sistem yang benar-benar kuno yang memerlukan fallback RSA.

Haruskah saya menggunakan pasangan kunci SSH yang sama untuk setiap server yang saya kelola?

Ini memang nyaman secara operasional tetapi menciptakan satu titik kompromi. Praktik yang lebih baik adalah menggunakan satu pasangan kunci per peran atau lingkungan (misalnya, satu kunci untuk server pribadi, satu untuk infrastruktur klien). Ini membatasi dampak jika kunci privat pernah terekspos.

Apakah mengunggah kunci SSH memengaruhi SSL Certificates atau konfigurasi server web saya?

Tidak. Kunci SSH mengatur akses terminal ke sistem operasi dan sepenuhnya terpisah dari sertifikat TLS/SSL yang digunakan oleh server web (Apache, Nginx) untuk HTTPS. Keduanya menggunakan port yang berbeda (22 vs. 443), format kunci yang berbeda, dan rantai kepercayaan yang berbeda. Mengubah satu tidak berpengaruh sama sekali pada yang lain.