Dasar-Dasar Pengelolaan Kunci SSH di Ubuntu 24.04

Cara kerja kunci SSH

Kunci SSH terdiri atas sepasang file: kunci privat yang tetap berada di perangkat Anda dan kunci publik yang Anda salin ke setiap server yang ingin Anda akses. Saat Anda terhubung, server menggunakan kunci publik untuk mengirimkan tantangan yang hanya dapat dijawab oleh kunci privat pasangannya. Kunci privat tidak pernah meninggalkan perangkat Anda, sehingga tidak ada rahasia yang dikirim melalui jaringan dan server yang dibobol tidak memiliki sesuatu yang berguna untuk dicuri. Karena itu, kunci lebih aman daripada kata sandi. Pengelolaan kunci SSH yang baik bergantung pada empat kebiasaan: satu kunci untuk setiap perangkat, permission file yang diwajibkan sshd, file ~/.ssh/config agar Anda tidak perlu terus mengetik opsi, serta kemampuan menghapus kunci pada hari ketika laptop hilang.

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

Sebelum mulai, ada satu hal tentang istilah yang perlu dipahami karena dapat mencegah kesalahan nyata. Kunci publik bukan rahasia. Anda dapat menyalinnya ke tiket, mengirimkannya melalui email, atau memublikasikannya, dan tidak seorang pun dapat login hanya dengan kunci tersebut. Kunci privat adalah rahasianya. Siapa pun yang menyalin file itu dan mengetahui passphrase-nya, jika ada, dapat bertindak sebagai Anda di server-server Anda.

Buat kunci: ed25519 adalah pilihan default yang tepat

Jalankan perintah berikut pada komputer Anda sendiri, bukan pada server:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 menentukan jenis kunci. Ed25519 adalah pilihan default modern: kunci ini berukuran pendek, cepat, dan didukung oleh setiap rilis OpenSSH sejak 2014. Gunakan ssh-keygen -t rsa -b 4096 hanya jika Anda harus terhubung ke perangkat lama yang tidak memahami ed25519. -C "laptop" menetapkan komentar. Komentar tidak berfungsi secara kriptografis, tetapi membantu Anda mengenali kunci ini di dalam file authorized_keys pada server dua tahun dari sekarang. Karena itu, beri nama perangkat tempat kunci tersebut disimpan.

ssh-keygen menanyakan lokasi penyimpanan kunci. Terima lokasi default, ~/.ssh/id_ed25519. Setelah itu, perintah akan meminta passphrase. Tetapkan passphrase. Bagian tentang passphrase di bawah menjelaskan alasan passphrase tidak menambah pekerjaan Anda sehari-hari. Anda akan memperoleh dua file: ~/.ssh/id_ed25519 adalah kunci privat, sedangkan ~/.ssh/id_ed25519.pub adalah kunci publik. Tampilkan bagian publiknya:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

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

Satu kunci per perangkat, bukan satu kunci per server

Pertanyaan yang pertama kali diajukan semua orang: apakah saya memerlukan kunci baru untuk setiap server? Tidak. Buat satu kunci untuk setiap perangkat yang Anda gunakan untuk mengetik, lalu pasang kunci publik tersebut pada setiap server yang perlu diakses perangkat itu. Kunci mengidentifikasi perangkat. File authorized_keys pada setiap server berisi daftar perangkat yang diizinkan masuk.

Model ini dapat diskalakan, sedangkan alternatifnya gagal dengan cara yang dapat diperkirakan. Satu kunci per server berarti laptop dengan dua puluh server harus menyimpan dua puluh kunci privat, dan Anda akan kehilangan jejak kunci yang digunakan untuk setiap server. Satu kunci yang dibagikan oleh semua perangkat Anda lebih buruk: ketika laptop dicuri, Anda tidak dapat mencabut akses laptop tanpa sekaligus mengunci akses desktop, karena keduanya menyimpan kunci privat yang sama. Akibatnya, Anda harus mengganti kunci di semua tempat dan mendistribusikannya ke setiap perangkat sekaligus.

Dengan satu kunci per perangkat, kehilangan laptop hanya memerlukan satu perubahan pada setiap server: hapus baris laptop dari authorized_keys, dan perangkat lain tetap dapat digunakan. Komentar yang Anda tetapkan dengan -C memudahkan Anda menemukan baris tersebut.

Aturan yang mendasari model ini: kunci privat dibuat pada suatu perangkat dan berakhir masa gunanya bersama perangkat tersebut. Jangan pernah menyalin kunci privat ke mesin kedua, dan jangan pernah mengunggahnya ke server. Jika perangkat baru memerlukan akses, buat kunci baru pada perangkat tersebut.

Letakkan public key di server

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

ssh-copy-id matt@10.0.0.10

Perintah ini login menggunakan metode yang masih berfungsi, biasanya password, lalu menambahkan public key Anda ke ~/.ssh/authorized_keys di server. Perintah ini juga membuat direktori dan file dengan permission yang benar jika keduanya belum ada. Uji dengan membuka sesi SSH baru. Server seharusnya mengizinkan Anda masuk tanpa meminta password akun. Jika key Anda memiliki passphrase, komputer Anda sendiri mungkin akan meminta passphrase tersebut. Prompt itu berasal dari komputer lokal, bukan password server.

Jika login menggunakan password sudah dinonaktifkan, ssh-copy-id tidak dapat masuk sehingga Anda harus menambahkan baris tersebut secara manual. Login melalui sesi yang masih berfungsi atau konsol web dari provider Anda, lalu jalankan perintah berikut di server:

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

Tempelkan public key Anda yang sebenarnya di dalam tanda kutip. Gunakan seluruh baris tunggal dari id_ed25519.pub. authorized_keys berisi satu public key per baris dan menjadi seluruh basis data akses. Menambahkan perangkat berarti menambahkan satu baris, sedangkan mencabut akses perangkat berarti menghapus satu baris. Pada server baru, langkah ini dilakukan dalam 10 menit pertama pada VPS baru, tepat sebelum Anda menonaktifkan login menggunakan password.

Izin yang menyebabkan login dengan key gagal

Ini adalah penyebab paling umum login dengan key gagal, dan kegagalan ini tidak terlihat dari sisi client. Secara default, sshd berjalan dengan StrictModes yes di Ubuntu 24.04. Artinya, sshd menolak menggunakan file authorized_keys yang dapat diedit oleh pengguna lain. Jika file tersebut, direktori ~/.ssh, atau direktori home Anda dapat ditulisi oleh siapa pun selain Anda, sshd mengabaikan key Anda dan kembali meminta password tanpa memberikan penjelasan kepada client. (OpenSSH Ubuntu secara khusus menoleransi satu kasus terbatas: file yang dapat ditulisi oleh group privat milik Anda sendiri, yang tidak beranggotakan pengguna lain. Jangan mengandalkan perilaku ini. Gunakan mode di bawah.) Alasannya hanya muncul di log server:

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

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

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

Perbaikannya terdiri atas dua perubahan izin dan satu pemeriksaan kepemilikan. Jalankan semuanya di server sebagai pengguna yang terdampak:

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

Aturan yang perlu diingat: 700 pada direktori .ssh, dan 600 pada semua isinya. Angka yang sama berlaku pada komputer Anda sendiri karena client juga melakukan pemeriksaan. Private key yang dapat dibaca oleh pengguna lain menyebabkan ssh menolak key tersebut sepenuhnya. Kali ini, error ditampilkan 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: hentikan pengetikan opsi

File ~/.ssh/config pada komputer Anda memberi setiap server nama singkat dan menyimpan opsi yang sering Anda ketik. Buat file tersebut dengan izin 600, lalu tambahkan satu 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. Nama singkat yang sama berfungsi di scp, rsync, dan git karena semuanya membaca file ini. HostName adalah alamat sebenarnya, User menyimpan nama akun agar tidak perlu diketik, dan IdentityFile menetapkan key yang akan ditawarkan.

IdentitiesOnly yes perlu dijelaskan karena opsi ini mengatasi kegagalan yang membingungkan. Jika agent memuat beberapa key, client menawarkannya satu per satu, dan server menghitung setiap penawaran sebagai percobaan yang gagal. Jika terlalu banyak key yang dimuat, Anda mendapatkan Received disconnect: Too many authentication failures sebelum key yang benar sempat dicoba. IdentitiesOnly yes membuat client hanya menawarkan key yang disebutkan dalam IdentityFile, sehingga kegagalan tersebut tidak dapat terjadi.

Frasa sandi dan ssh-agent

Frasa sandi mengenkripsi file kunci privat di disk. Tanpa frasa sandi, siapa pun yang menyalin file tersebut dapat langsung menggunakannya. Dengan frasa sandi, file yang dicuri tidak berguna sampai frasa sandinya berhasil ditebak. Untuk kunci yang disimpan di laptop, perlindungan ini memang diperlukan karena laptop dapat dicuri dan cadangan laptop dapat bocor.

Alasan frasa sandi tidak menambah beban dalam praktik adalah ssh-agent. Agent menyimpan kunci yang telah didekripsi di memori. Dengan demikian, Anda cukup memasukkan frasa sandi sekali dalam setiap sesi login, dan semua koneksi berikutnya berlangsung secara langsung. Sebagian besar distribusi Linux desktop dan macOS sudah menjalankan agent secara otomatis. Muat kunci ke dalamnya dengan:

ssh-add ~/.ssh/id_ed25519

ssh-add -l menampilkan daftar kunci yang sedang disimpan oleh agent. Perhatikan bahwa agent forwarding (ssh -A) memungkinkan server jarak jauh menggunakan agent Anda untuk melakukan autentikasi ke server lain selama Anda terhubung. Karena itu, aktifkan fitur ini hanya untuk server yang sepenuhnya Anda percayai, dan nonaktifkan secara default.

Rotasi dan pencabutan: prosedur laptop yang hilang

Mencabut SSH key biasa cukup dilakukan dengan menghapus barisnya dari authorized_keys pada setiap server yang memuatnya. Tidak ada certificate authority yang perlu diberi tahu dan tidak ada tanggal kedaluwarsa yang perlu ditunggu. Setelah baris tersebut dihapus, login baru dengan key itu langsung gagal.

Jalankan prosedur ini sekarang, saat belum menjadi keadaan darurat. Pilih sebuah server, buka ~/.ssh/authorized_keys, lalu cari key berdasarkan komentarnya. Hapus baris tersebut dengan editor, atau keluarkan baris itu berdasarkan komentarnya:

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

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

Rotasi menggunakan operasi yang sama, tetapi dengan urutan berbeda: buat key baru pada perangkat, pasang dengan ssh-copy-id, pastikan login dengan key baru berhasil, lalu hapus baris lama. Lakukan ini ketika perangkat berpindah tangan, ketika key mungkin telah terekspos, atau ketika seseorang keluar dari tim. Melakukannya secara manual pada dua server masih wajar. Pada dua puluh server, tugas ini sebaiknya diotomatisasi, dan mengelola beberapa server Linux menjelaskan cara menerapkan status authorized_keys yang sama ke seluruh fleet.

Hal yang harus dihindari

• Jangan gunakan satu private key pada semua perangkat Anda. Tindakan ini membuat pencabutan akses satu perangkat yang dicuri tidak mungkin dilakukan tanpa mengganti key tersebut di semua perangkat.

• Jangan commit private key ke repositori git, meskipun repositori tersebut bersifat privat. Pemindai otomatis memantau repositori publik dan mencoba menggunakan key yang bocor dalam hitungan menit setelah push. Jika repositori kemudian dibuat publik, seluruh riwayatnya akan bocor.

• Jangan upload private key laptop ke server agar server tersebut dapat mengakses server lain. Buat key terpisah langsung di server, lalu berikan otorisasi pada key tersebut hanya di lokasi yang memerlukannya.

• Jangan tempelkan private key ke chat, email, atau tiket. Public key, yaitu file .pub, adalah satu-satunya bagian yang boleh dibagikan.

Setelah key Anda berhasil digunakan untuk login secara andal, lanjutkan dengan menonaktifkan autentikasi password. Dengan demikian, upaya penebakan terus-menerus terhadap server Anda tidak akan berhasil. Konfigurasi drop-in untuk langkah tersebut tersedia di Memperkuat keamanan SSH pada VPS.

FAQ

Bagaimana cara kerja kunci SSH tanpa mengirimkan kata sandi?

Server menyimpan kunci publik Anda di ~/.ssh/authorized_keys. Saat login, server mengirimkan challenge, client Anda menandatangani challenge tersebut dengan kunci privat, lalu server memverifikasi tanda tangan menggunakan kunci publik. Kunci privat tidak pernah meninggalkan perangkat Anda, sehingga tidak ada yang dapat disadap saat transit dan tidak ada kredensial yang dapat digunakan kembali untuk dicuri dari server. Server yang dibobol hanya membocorkan kunci publik, yang tidak dapat digunakan untuk login di mana pun.

Apakah saya harus menggunakan kunci SSH yang sama untuk semua server?

Menggunakan satu kunci di banyak server adalah hal yang benar, selama kunci tersebut tetap berada pada satu perangkat. Aturannya adalah satu kunci per perangkat, bukan satu kunci per server: kunci publik laptop Anda dipasang di setiap server yang perlu diakses oleh laptop tersebut, sedangkan desktop Anda memiliki kuncinya sendiri. Cara ini menyederhanakan pencabutan akses, karena kehilangan satu perangkat berarti Anda hanya perlu menghapus satu baris yang dapat diidentifikasi dari setiap server, sementara perangkat lain tetap dapat digunakan.

Izin apa yang harus dimiliki direktori .ssh dan authorized_keys?

Atur 700 pada ~/.ssh dan 600 pada authorized_keys serta pada setiap kunci privat. Semua itu harus dimiliki oleh akun yang menggunakannya. sshd berjalan dengan StrictModes yes secara default, sehingga file atau direktori home yang dapat ditulis oleh siapa pun selain Anda akan membuat sshd mengabaikan kunci Anda secara diam-diam. Satu-satunya jejaknya adalah Authentication refused: bad ownership or modes dalam auth log atau journal server.

Bagaimana cara menghapus kunci SSH dari server?

Hapus baris kunci tersebut dari ~/.ssh/authorized_keys pada akun yang diberi otorisasi untuk menggunakannya. Temukan baris yang benar berdasarkan komentarnya, yaitu label setelah materi kunci. Login baru dengan kunci tersebut akan langsung gagal, tetapi sesi yang sudah terbuka tetap berjalan. Karena itu, akhiri juga sesi aktif untuk perangkat tersebut jika perangkatnya dicuri. Ulangi langkah ini pada setiap server tempat kunci tersebut disalin.

Apakah kunci SSH saya perlu dilindungi passphrase?

Untuk kunci yang berada di laptop atau desktop, ya. Passphrase mengenkripsi file kunci, sehingga salinan yang dicuri atau bocor tidak dapat digunakan tanpa faktor lain. Selain itu, ssh-agent berarti Anda hanya perlu mengetikkannya sekali per sesi, bukan pada setiap koneksi. Kunci yang digunakan oleh otomatisasi tanpa pengawasan pada server biasanya tidak memiliki passphrase karena tidak ada manusia yang dapat mengetikkannya. Lindungi kunci tersebut dengan membatasi tindakan yang dapat dilakukan oleh akun target.