Keamanan Siber

SSH Host Key - Apa yang Sebenarnya Dilindungi Peringatan Koneksi Pertama

Ditulis oleh Adam Muiz Diperbarui: 24 Aug 2026 8 menit baca
SSH Host Key - Apa yang Sebenarnya Dilindungi Peringatan Koneksi Pertama

Koneksi SSH pertama ke sebuah server sering berhenti sejenak sebelum meminta password atau memakai user key. SSH menampilkan fingerprint dan bertanya apakah host tersebut dapat dipercaya. Prompt ini mudah dianggap sekadar penghalang kecil: ketik yes, lanjutkan, lalu lupakan. Namun, keputusan apa yang sebenarnya dibuat pada saat itu?

Pertanyaannya bukan apakah koneksi akan dienkripsi. Pertanyaannya adalah apakah mesin yang menjawab di alamat tersebut benar-benar mesin yang ingin kita hubungi. Perbedaan ini penting di home server maupun jaringan besar. Percakapan yang dienkripsi dengan kuat tetapi dilakukan bersama penyamar tetaplah percakapan bersama penyamar.

Satu Koneksi SSH, Dua Arah Kepercayaan

SSH umumnya melakukan dua autentikasi yang mudah tertukar. Server mengautentikasi dirinya kepada client dengan host key. Setelah itu, client mengautentikasi pengguna kepada server, mungkin dengan password atau user key yang disimpan di ~/.ssh/id_ed25519. Arsitektur protokol SSH dalam RFC 4251 menempatkan autentikasi server di transport layer dan autentikasi pengguna di protokol terpisah di atasnya.

Kedua pemeriksaan ini menjawab pertanyaan yang berbeda:

  • Autentikasi host: Apakah ini server yang diharapkan?
  • Autentikasi pengguna: Apakah pengguna ini diizinkan masuk ke server tersebut?

Memasang public key pengguna di authorized_keys tidak menjawab pertanyaan pertama. Sebaliknya, mengenali host key server tidak memberi pengguna izin untuk login. Kedua arah sama-sama penting.

Apa yang Diwakili Fingerprint

Server SSH memiliki satu atau beberapa pasangan host key. Bagian private tetap berada di server, sedangkan bagian public dapat ditunjukkan kepada client. Saat key exchange, server membuktikan bahwa ia mengendalikan private key yang sesuai. Fingerprint adalah representasi hash yang lebih pendek dari public key tersebut, agar lebih mudah dibandingkan daripada key panjang yang telah di-encode.

OpenSSH saat ini menampilkan fingerprint menggunakan SHA-256 secara default, menurut manual konfigurasi client. Fingerprint yang cocok mendukung kesimpulan yang tepat tetapi terbatas: endpoint dapat memakai private key yang sesuai dengan public host key yang diharapkan. Kecocokan itu tidak membuktikan bahwa sistem operasi bebas kompromi, semua layanan dikonfigurasi dengan aman, atau orang yang mengoperasikan server dapat dipercaya.

Bagian yang masih kurang adalah hubungan antara nama dan key. Kriptografi dapat menunjukkan bahwa private key yang sama tersedia, tetapi client tetap memerlukan alasan tepercaya untuk meyakini bahwa key tersebut memang milik server.example.net.

Koneksi Pertama Memiliki Masalah Bootstrap Kepercayaan

Pada koneksi berikutnya, SSH client dapat membandingkan key yang ditunjukkan dengan key yang telah tersimpan. Pada koneksi pertama, mungkin belum ada nilai tersimpan untuk dibandingkan. Inilah masalah bootstrap kepercayaan: dari mana fingerprint tepercaya yang pertama berasal?

RFC 4251 menjelaskan strategi praktis yang sering disebut trust on first use atau TOFU: terima host key pada koneksi pertama, simpan secara lokal, lalu tolak atau beri peringatan atas perubahan tak terduga pada koneksi berikutnya. Strategi ini berguna karena dapat mendeteksi penyerang yang muncul setelah koneksi tepercaya pertama. Namun, strategi ini sendiri tidak dapat mendeteksi penyerang yang sudah berada di tengah koneksi pertama yang belum diverifikasi. RFC tersebut menyatakan bahwa koneksi seperti ini masih dapat melawan penyadapan pasif, tetapi tetap rentan terhadap serangan man-in-the-middle aktif.

Karena itu, TOFU adalah kompromi, bukan tindakan tanpa arti dan bukan pula bukti. Pada jaringan terisolasi yang jalur serta penetapan alamatnya dikendalikan satu administrator, kompromi tersebut mungkin diterima secara sadar. Di jaringan bandara, provider yang belum dikenal, atau jalur lain yang mungkin disadap, verifikasi independen menjadi lebih berharga.

Alur Koneksi Pertama yang Lebih Baik

Fingerprint yang diharapkan sebaiknya diperoleh melalui jalur yang independen dari koneksi SSH yang sedang diperiksa. Bergantung pada siapa yang mengendalikan server, caranya dapat berupa:

  • membaca fingerprint host key langsung dari console fisik atau console provider milik server;
  • bertanya kepada administrator melalui jalur komunikasi yang sudah diautentikasi; atau
  • memeriksa halaman fingerprint milik operator melalui koneksi HTTPS yang dipercaya secara independen.

Sebagai contoh, GitHub memublikasikan fingerprint SSH host key miliknya agar pengguna dapat membandingkannya dengan nilai yang ditampilkan SSH client. Pola pentingnya bukan nilai fingerprint GitHub saat ini, yang dapat berubah, melainkan pemisahan antara koneksi SSH dan jalur yang memublikasikan identitas yang diharapkan.

Di console server, administrator dapat menampilkan fingerprint public host key Ed25519 dengan:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

sudo mungkin tidak diperlukan jika file public tersebut dapat dibaca. Hal terpenting adalah menjalankan command melalui console atau jalur administratif yang sudah dipercaya, bukan melalui sesi SSH belum terverifikasi yang identitasnya sedang dipertanyakan. Bandingkan algoritma dan fingerprint secara lengkap dengan prompt di client sebelum menerimanya.

Apa yang Diingat known_hosts

Setelah diterima, OpenSSH biasanya mencatat hubungan tersebut di ~/.ssh/known_hosts. Manual OpenSSH client menjelaskan bahwa client memeriksa database ini pada koneksi berikutnya dan memberi peringatan ketika identitas host berubah. Administrator sistem juga dapat mengelola file tingkat sistem di /etc/ssh/ssh_known_hosts.

Sebuah record dapat diperiksa tanpa mencari secara manual di antara baris panjang atau nama yang telah di-hash:

ssh-keygen -F server.example.net

Untuk layanan di port non-default, gunakan format host dan port dengan tanda kurung siku:

ssh-keygen -F '[server.example.net]:2222'

Manual resmi ssh-keygen mendokumentasikan -F untuk menemukan entry, termasuk nama host yang telah di-hash. Hashing nama di known_hosts dapat mengurangi informasi yang terungkap jika file tersebut disalin, tetapi tidak mengubah keputusan autentikasi host yang mendasarinya.

Key yang Berubah Adalah Sinyal, Bukan Vonis

Peringatan perubahan key yang mencolok dirancang untuk menghentikan koneksi. Peringatan itu mungkin menunjukkan upaya penyamaran, gangguan DNS atau routing, maupun jalur lain menuju mesin yang salah. Namun, peringatan yang sama juga dapat muncul setelah instalasi ulang server yang sah, penggantian server, pemulihan image, atau rotasi host key yang disengaja. Peringatan itu sendiri tidak dapat menentukan penjelasan mana yang benar.

Respons yang hati-hati adalah investigasi singkat:

  1. Hentikan koneksi. Jangan masukkan password atau kirim command sensitif selama identitas belum jelas.
  2. Pastikan tujuan. Periksa hostname, alamat IP, port, alias konfigurasi SSH, dan jump host yang terlibat.
  3. Tanyakan apa yang berubah. Cari catatan rebuild atau rotasi, atau hubungi administrator melalui jalur tepercaya yang terpisah.
  4. Dapatkan fingerprint baru secara independen. Gunakan console tepercaya atau sumber lain yang telah diautentikasi.
  5. Bandingkan sebelum mengganti. Hapus hubungan lama hanya setelah identitas baru dan alasan perubahan sama-sama masuk akal.

Setelah verifikasi selesai, OpenSSH dapat menghapus record lama dengan aman meskipun nama host telah di-hash:

ssh-keygen -R server.example.net

Untuk port khusus:

ssh-keygen -R '[server.example.net]:2222'

Menjalankan -R terlebih dahulu dan baru menyelidiki kemudian justru membalik mekanisme keamanannya. Tindakan itu menghilangkan peringatan tanpa menjawab mengapa peringatan tersebut muncul.

Mengapa ssh-keyscan Bukan Verifikasi

ssh-keyscan berguna untuk mengumpulkan public host key, terutama saat menyiapkan file known-hosts untuk banyak mesin:

ssh-keyscan server.example.net

Namun, mengambil key melalui jalur jaringan yang sama tidak mengautentikasi key tersebut. Manual ssh-keyscan secara eksplisit menyatakan bahwa tool ini tidak dapat memverifikasi keaslian key yang diperolehnya. Penyerang yang mampu menyadap scan dapat mengganti key, sama seperti pada koneksi SSH yang belum diverifikasi.

Karena itu, pola umum ssh-keyscan ... >> ~/.ssh/known_hosts belum lengkap sebagai bootstrap keamanan. Pola tersebut mengotomatiskan pengumpulan, bukan kepercayaan. Key yang dikumpulkan masih harus diverifikasi secara independen, kecuali operator secara sadar memilih model yang sejak awal memercayai jalur jaringan tersebut.

Automation Sebaiknya Gagal dengan Jelas

Prompt interaktif memang merepotkan dalam deployment job, container, dan script terjadwal. Menonaktifkan pemeriksaan mungkin membuat pipeline berjalan, tetapi tindakan itu juga menghapus pemeriksaan identitas endpoint yang memunculkan prompt. Pola yang lebih kuat adalah menyediakan file known_hosts yang sudah diverifikasi atau certificate authority host yang tepercaya sebelum job dimulai, lalu membuat identitas yang tidak dikenal atau berubah gagal alih-alih lolos diam-diam.

Untuk home lab kecil, pinning host key satu per satu mungkin masih mudah dipahami dan dikelola. Untuk fleet yang lebih besar atau sering dibangun ulang, RFC 4251 dan manual OpenSSH menjelaskan model lain: percayai sebuah host certificate authority, lalu biarkan server menunjukkan host certificate yang ditandatangani CA tersebut. Cara ini mengurangi jumlah key individual yang harus di-pin oleh client, tetapi memindahkan kepercayaan yang besar kepada CA dan keamanan operasionalnya. Ini adalah arsitektur alternatif, bukan peningkatan tanpa biaya.

Batas dari Kecocokan yang Benar

Verifikasi host key mempersempit satu risiko: terhubung ke endpoint yang tidak diharapkan. Pemeriksaan ini tidak menggantikan patching, access control, perlindungan user key, logging, atau administrasi server yang cermat. Pemeriksaan ini juga tidak membuat server yang telah dikompromikan menjadi aman; penyerang yang mengendalikan server sah mungkin dapat memakai host key sah milik server tersebut.

Ada pula batas manusia. Fingerprint panjang mudah diperiksa secara ceroboh, dan jalur independen itu sendiri mungkin telah dikompromikan. Tujuan yang realistis bukan kepastian sempurna dari satu prompt, melainkan menghindari kebiasaan mengubah pemeriksaan identitas yang bermakna menjadi refleks tanpa berpikir.

Kesimpulan

Prompt fingerprint SSH mengajukan pertanyaan sederhana tetapi penting: server mana yang akan kita percayai? Pada koneksi pertama, jawaban terkuat datang dari membandingkan fingerprint melalui jalur independen. Pada koneksi berikutnya, known_hosts mengubah keputusan awal itu menjadi pemeriksaan kesinambungan identitas.

Ketika key berubah, panik maupun penghapusan otomatis bukanlah diagnosis yang baik. Berhenti, verifikasi tujuan dan alasannya, dapatkan fingerprint baru secara terpisah, lalu perbarui record tersimpan. Jeda singkat ini mempertahankan bagian dari SSH yang tidak dapat diberikan oleh enkripsi saja: keyakinan tentang siapa yang berada di ujung koneksi.

References