Cara Mengelola SSH Key dengan Benar

Cara kerja SSH key

SSH key adalah sepasang file: private key yang tetap berada di perangkat Anda dan public key yang Anda salin ke setiap server yang ingin Anda akses. Saat Anda terhubung, server menggunakan public key untuk mengirimkan tantangan yang hanya dapat dijawab oleh private key yang sesuai. Private key tidak pernah meninggalkan perangkat Anda, sehingga tidak ada rahasia yang dikirim melalui jaringan, dan server yang disusupi tidak memiliki data berguna untuk dicuri. Itulah alasan mengapa key lebih baik daripada password. Mengelola SSH key dengan baik bergantung pada empat kebiasaan: satu key untuk setiap perangkat, izin file yang diminta oleh sshd, file ~/.ssh/config agar Anda tidak perlu mengetik opsi secara manual, dan mengetahui cara menghapus key saat laptop hilang.

Panduan ini membahas setiap kebiasaan pada Ubuntu 24.04, meskipun hampir semua hal di sini berlaku untuk server Linux apa pun dan OpenSSH versi terbaru.

Satu poin terminologi sebelum memulai, karena hal ini mencegah kesalahan fatal. Public key tidak bersifat rahasia. Anda dapat menempelkannya ke dalam tiket, mengirimnya melalui email, atau mempublikasikannya, dan tidak ada orang yang dapat masuk menggunakan key tersebut. Private key adalah rahasia. Siapa pun yang menyalin file tersebut, dan mengetahui passphrase-nya jika ada, akan dianggap sebagai Anda oleh server Anda.

Buat kunci: ed25519 adalah pilihan default yang tepat

Pada komputer Anda sendiri, bukan pada server, jalankan:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 menentukan tipe kunci. Ed25519 adalah default modern: kuncinya pendek, cepat, dan didukung oleh setiap rilis OpenSSH sejak 2014. Gunakan ssh-keygen -t rsa -b 4096 hanya jika Anda harus terhubung dengan perangkat lama yang tidak mendukung ed25519. -C "laptop" mengatur komentar. Komentar tidak memiliki fungsi kriptografi, tetapi ini adalah cara Anda mengenali kunci ini di dalam file authorized_keys server dua tahun mendatang, jadi beri nama perangkat tempat kunci tersebut disimpan.

ssh-keygen menanyakan lokasi penyimpanan kunci. Terima nilai default, ~/.ssh/id_ed25519. Program kemudian meminta passphrase. Tetapkan passphrase; bagian passphrase di bawah menjelaskan mengapa hal ini tidak membebani Anda dalam penggunaan sehari-hari. Anda akan mendapatkan dua file: ~/.ssh/id_ed25519 adalah kunci privat, dan ~/.ssh/id_ed25519.pub adalah kunci publik. Lihat bagian publiknya:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Isinya hanya satu baris: tipe kunci, materi kunci, dan komentar Anda. Baris itulah yang akan disimpan di server Anda.

Satu kunci per perangkat, bukan satu per server

Pertanyaan pertama yang muncul: apakah saya butuh kunci baru untuk setiap server? Tidak. Buatlah satu kunci untuk setiap perangkat yang Anda gunakan untuk mengetik, dan masukkan satu kunci publik tersebut ke setiap server yang ingin diakses perangkat tersebut. Kunci tersebut mengidentifikasi perangkat. File authorized_keys pada setiap server adalah daftar perangkat yang diizinkan masuk.

Ini adalah model yang dapat diskalakan, sedangkan alternatif lainnya gagal dengan cara yang dapat diprediksi. Satu kunci per server berarti sebuah laptop dengan dua puluh server akan menyimpan dua puluh kunci privat, dan Anda akan kesulitan membedakan mana yang mana. Menggunakan satu kunci untuk semua perangkat Anda jauh lebih buruk: jika laptop dicuri, Anda tidak dapat mencabut akses laptop tersebut tanpa mengunci akses desktop Anda juga, karena keduanya memiliki kunci privat yang sama. Anda harus mengganti kunci di semua tempat dan mendistribusikannya kembali ke setiap perangkat secara bersamaan.

Dengan satu kunci per perangkat, laptop yang hilang hanya memakan biaya satu baris per server: hapus baris laptop tersebut dari authorized_keys, dan perangkat lainnya tetap berfungsi. Komentar yang Anda atur dengan -C akan memudahkan pencarian baris tersebut.

Aturan di balik model ini: kunci privat dibuat pada sebuah perangkat dan berakhir bersama perangkat tersebut. Jangan pernah menyalin kunci privat ke mesin kedua, dan jangan pernah mengunggahnya ke server. Ketika perangkat baru membutuhkan akses, buatlah kunci baru di perangkat tersebut.

Masukkan kunci publik ke server

Cara termudah adalah menggunakan ssh-copy-id, yang disertakan dalam OpenSSH:

ssh-copy-id matt@10.0.0.10

Perintah ini masuk menggunakan metode yang masih aktif, biasanya kata sandi, menambahkan kunci publik Anda ke ~/.ssh/authorized_keys di server, serta membuat direktori dan file dengan izin yang benar jika belum ada. Uji dengan membuka sesi SSH baru: server harus mengizinkan Anda masuk tanpa meminta kata sandi akun. Jika kunci Anda memiliki passphrase, mesin Anda mungkin akan memintanya; perintah tersebut bersifat lokal dan bukan kata sandi server.

Jika login dengan kata sandi sudah dinonaktifkan, ssh-copy-id tidak dapat masuk, sehingga Anda harus menambahkan baris tersebut secara manual. Masuk melalui sesi yang masih aktif atau konsol web penyedia layanan Anda, lalu jalankan perintah ini di server:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Tempelkan kunci publik asli Anda di dalam tanda kutip, yaitu satu baris lengkap dari id_ed25519.pub. authorized_keys menggunakan satu kunci publik per baris, dan itulah seluruh basis data aksesnya: menambahkan perangkat berarti menambahkan baris, dan mencabut akses perangkat berarti menghapus baris. Pada server baru, langkah ini harus dilakukan dalam 10 menit pertama pada VPS baru, tepat sebelum Anda menonaktifkan login dengan kata sandi.

Izin yang menyebabkan kegagalan login menggunakan key

Ini adalah penyebab paling umum kegagalan login menggunakan key, dan kegagalan ini terjadi secara diam-diam dari sisi klien. sshd berjalan dengan StrictModes yes secara default pada Ubuntu 24.04, yang berarti sshd menolak menggunakan file authorized_keys yang dapat diedit oleh pengguna lain. Jika file, direktori ~/.ssh, atau direktori home Anda dapat ditulis oleh siapa pun selain Anda, sshd akan mengabaikan key Anda dan beralih meminta kata sandi, tanpa penjelasan pada sisi klien. (OpenSSH pada Ubuntu hanya menoleransi satu kasus khusus: file yang dapat ditulis oleh grup privat Anda sendiri, di mana tidak ada orang lain yang tergabung di dalamnya. Jangan mengandalkan hal ini; gunakan mode di bawah ini.) Penyebabnya hanya muncul dalam log server:

sudo grep 'Authentication refused' /var/log/auth.log

Pada image minimal tanpa rsyslog, tidak ada auth.log; baris yang sama tersimpan di journal: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

Solusinya adalah dua perubahan izin dan satu pemeriksaan kepemilikan, jalankan di server sebagai pengguna yang terdampak:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

Aturan yang harus diingat: 700 pada direktori .ssh, 600 pada semua isi di dalamnya. Angka yang sama berlaku pada komputer Anda sendiri, karena klien juga melakukan pengecekan. Private key yang dapat dibaca oleh pengguna lain membuat ssh menolak key tersebut sepenuhnya, dan kali ini error akan muncul secara jelas:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 memperbaikinya.

~/.ssh/config: berhenti mengetik opsi secara manual

File ~/.ssh/config pada komputer Anda memberikan nama singkat untuk setiap server dan menyimpan opsi yang sering Anda ketik. Buat file ini dengan izin 600 dan tambahkan blok Host untuk setiap server:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Sekarang ssh web1 menggantikan ssh -p 22 matt@10.0.0.10, dan nama singkat yang sama dapat digunakan di scp, rsync, dan git karena semuanya membaca file ini. HostName adalah alamat asli, User menghemat pengetikan nama akun, dan IdentityFile menentukan kunci mana yang akan digunakan.

IdentitiesOnly yes perlu dijelaskan karena dapat memperbaiki kegagalan yang membingungkan. Saat agent Anda menyimpan beberapa kunci, client akan menawarkan kunci tersebut satu per satu, dan server menghitung setiap tawaran sebagai upaya yang gagal. Jika terlalu banyak kunci yang dimuat, Anda akan mendapatkan Received disconnect: Too many authentication failures sebelum kunci yang benar sempat dicoba. IdentitiesOnly yes membuat client hanya menawarkan kunci yang terdaftar di IdentityFile, sehingga kegagalan tersebut tidak akan terjadi.

Passphrase dan ssh-agent

Passphrase mengenkripsi file kunci privat di dalam disk. Tanpa passphrase, siapa pun yang menyalin file tersebut dapat langsung menggunakannya; dengan passphrase, file yang dicuri tidak berguna sampai passphrase berhasil ditebak. Untuk kunci pada laptop, ini adalah perlindungan yang Anda butuhkan, karena laptop dapat dicuri dan cadangan data laptop dapat bocor.

Alasan mengapa passphrase tidak membebani kinerja secara praktis adalah ssh-agent. Agent menyimpan kunci yang telah didekripsi di dalam memori, sehingga Anda hanya perlu mengetik passphrase satu kali per sesi login dan setiap koneksi berikutnya akan berlangsung instan. Sebagian besar distribusi Linux desktop dan macOS sudah menjalankan agent secara otomatis. Masukkan kunci Anda ke dalam agent dengan:

ssh-add ~/.ssh/id_ed25519

ssh-add -l menampilkan daftar kunci yang saat ini disimpan oleh agent. Satu peringatan: agent forwarding (ssh -A) memungkinkan server jarak jauh menggunakan agent Anda untuk autentikasi lebih lanjut selama Anda terhubung, jadi hanya aktifkan fitur ini pada server yang Anda percayai sepenuhnya, dan biarkan tetap nonaktif secara default.

Rotasi dan pencabutan: simulasi laptop hilang

Mencabut SSH key biasa hanyalah menghapus baris kuncinya dari authorized_keys pada setiap server yang memilikinya. Tidak ada otoritas sertifikat yang perlu diberitahu dan tidak ada tanggal kedaluwarsa yang perlu ditunggu. Segera setelah baris tersebut dihapus, login baru dengan kunci tersebut akan gagal.

Jalankan simulasi ini sekarang, selagi bukan dalam keadaan darurat. Pilih sebuah server, buka ~/.ssh/authorized_keys, dan temukan kunci tersebut melalui komentarnya. Hapus baris tersebut menggunakan editor, atau filter berdasarkan komentar:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Kemudian konfirmasi dari perangkat yang baru saja dicabut bahwa login kini gagal, dan dari perangkat lain bahwa login masih berfungsi. Perhatikan satu detail: menghapus kunci tidak menutup sesi yang sudah terbuka, karena kunci hanya diperiksa saat login. Jika Anda mencabut akses perangkat yang dicuri, periksa juga who pada server dan akhiri sesi yang tidak Anda kenali.

Rotasi adalah operasi yang sama dengan urutan berbeda: buat kunci baru pada perangkat, instal dengan ssh-copy-id, konfirmasi kunci baru dapat login, lalu hapus baris lama. Lakukan ini saat perangkat berpindah tangan, saat kunci mungkin telah terekspos, atau saat seseorang keluar dari tim. Melakukan ini secara manual pada dua server tidak masalah; pada dua puluh server, Anda memerlukan otomatisasi, dan mengelola banyak server Linux menunjukkan cara menerapkan status authorized_keys yang sama ke seluruh armada.

Apa yang tidak boleh dilakukan

• Jangan gunakan satu private key untuk semua perangkat Anda. Hal ini membuat pencabutan akses perangkat yang dicuri menjadi mustahil tanpa mengganti kunci di seluruh perangkat.

• Jangan melakukan commit private key ke repositori git, meskipun repositori tersebut bersifat privat. Pemindai otomatis memantau repositori publik dan mencoba kunci yang bocor dalam hitungan menit setelah push, dan repositori yang diubah menjadi publik di kemudian hari akan membocorkan seluruh riwayatnya.

• Jangan mengunggah private key laptop Anda ke server agar server tersebut dapat menjangkau server lain. Buatlah kunci terpisah di dalam server itu sendiri, dan berikan otorisasi pada kunci tersebut hanya di tempat yang dibutuhkan.

• Jangan menempelkan (paste) private key ke dalam chat, email, atau tiket. Public key, yaitu file .pub, adalah satu-satunya bagian yang boleh dibagikan.

Setelah kunci Anda dapat melakukan login dengan andal, lakukan langkah berikutnya dengan menonaktifkan autentikasi kata sandi. Hal ini dilakukan agar upaya penebakan kata sandi secara terus-menerus terhadap server Anda tidak dapat berhasil. Konfigurasi siap pakai untuk hal tersebut tersedia di SSH hardening on a VPS.

FAQ

Bagaimana cara kerja SSH key tanpa mengirimkan kata sandi?

Server menyimpan public key Anda di ~/.ssh/authorized_keys. Saat login, server mengirimkan tantangan (challenge), client Anda menandatangani tantangan tersebut dengan private key, dan server memverifikasi tanda tangan tersebut dengan public key. Private key tidak pernah meninggalkan perangkat Anda, sehingga tidak ada data yang dapat disadap saat transmisi dan tidak ada data yang dapat dicuri dari server untuk digunakan kembali. Server yang dibobol hanya akan membocorkan public key, yang tidak dapat digunakan untuk login di tempat lain.

Haruskah saya menggunakan SSH key yang sama untuk semua server saya?

Menggunakan satu key untuk banyak server diperbolehkan, selama key tersebut tetap berada di satu perangkat tunggal. Aturannya adalah satu key per perangkat, bukan satu per server: public key laptop Anda harus ada di setiap server yang membutuhkan laptop tersebut, dan desktop Anda memiliki key sendiri. Hal ini memudahkan proses pencabutan (revocation), karena kehilangan perangkat hanya berarti menghapus satu baris identitas dari setiap server, dan perangkat lainnya tetap berfungsi.

Izin (permissions) apa yang harus dimiliki direktori .ssh dan authorized_keys?

Atur 700 pada ~/.ssh dan 600 pada authorized_keys serta pada setiap private key, dengan kepemilikan oleh akun yang menggunakannya. sshd berjalan dengan StrictModes yes secara default, sehingga jika file atau direktori home dapat ditulis oleh orang lain selain Anda, sshd akan mengabaikan key Anda secara diam-diam, dan satu-satunya jejak adalah Authentication refused: bad ownership or modes pada log auth atau journal server.

Bagaimana cara menghapus SSH key dari server?

Hapus baris key tersebut dari ~/.ssh/authorized_keys pada akun yang telah diizinkan. Temukan baris yang tepat melalui komentarnya, yaitu label setelah materi key. Login baru dengan key tersebut akan langsung gagal, tetapi sesi yang sudah terbuka akan tetap terbuka, jadi akhiri juga sesi aktif untuk perangkat tersebut jika perangkat tersebut dicuri. Ulangi langkah ini pada setiap server tempat key tersebut disalin.

Apakah saya perlu passphrase pada SSH key saya?

Untuk key pada laptop atau desktop, ya. Passphrase mengenkripsi file key, sehingga salinan yang dicuri atau bocor tidak berguna jika berdiri sendiri, dan ssh-agent berarti Anda cukup mengetiknya satu kali per sesi, bukan pada setiap koneksi. Key yang digunakan oleh otomatisasi tanpa pengawasan (unattended automation) pada server biasanya tidak memiliki passphrase karena tidak ada manusia yang mengetikkannya; lindungi key tersebut dengan membatasi hak akses akun target.