Verifikasi Host Key SSH Mengikat Koneksi ke Identitas Server

SSH mengenkripsi koneksi, tetapi enkripsi saja tidak memastikan endpoint yang dicapai merupakan server yang dituju. Saat key exchange, server membuktikan kepemilikan host private key. Client kemudian harus memutuskan apakah identitas publik yang terkait dapat dipercaya untuk host tersebut.

Keputusan itu merupakan boundary autentikasi host. Jika client menerima host key milik penyerang tanpa dasar trust yang valid, channel yang terbentuk tetap dapat terenkripsi tetapi berakhir pada mesin yang salah. Password, command, forwarded agent, dan data sesi kemudian dapat melintasi boundary yang tidak dimaksudkan operator.

Server membuktikan kepemilikan host key

Server SSH dikonfigurasi dengan satu atau beberapa pasangan host key. Private key tetap berada di server. Saat key exchange, server menandatangani data exchange sehingga client dapat memverifikasi bahwa peer memiliki private key yang sesuai dengan host public key yang disajikan.

Bukti ini belum menetapkan identitas dengan sendirinya. Key baru yang dibuat penyerang dapat menghasilkan signature valid untuk public key miliknya sendiri. Autentikasi muncul ketika proof of possession digabungkan dengan aturan di sisi client yang mengikat key yang dapat diterima ke destination.

Boundary sederhananya:

connect ke server.example
        |
        v
server menyajikan identitas host
        |
        v
client memverifikasi signature key exchange
        |
        v
client memeriksa binding tepercaya
        |
        +-- cocok -> lanjut
        |
        +-- berbeda -> berhenti atau perlu penanganan eksplisit

Exchange kriptografis dan keputusan trust merupakan dua pemeriksaan terpisah, dan keduanya penting.

known_hosts menyimpan binding key langsung

Client OpenSSH umumnya mencatat identitas host dalam known_hosts. Sebuah entry dapat mengaitkan hostname atau address dengan host public key yang diterima.

Koneksi ke host dengan key tersimpan yang cocok dapat dilanjutkan berdasarkan binding tersebut. Key berbeda untuk host yang sama merupakan sinyal penting karena dapat menunjukkan interception, server yang dibangun ulang, rotasi host key, perubahan DNS, atau kesalahan administratif. Client tidak dapat menentukan penjelasan yang benar hanya dari mismatch.

Menghapus entry lama lalu menerima penggantinya tanpa verifikasi independen membuang sinyal keamanan tersebut. Perubahan key yang sah memerlukan jalur terautentikasi untuk mengonfirmasi identitas baru.

Hostname dalam known_hosts dapat di-hash untuk mengurangi pengungkapan langsung jika file terekspos. Hash pada hostname tidak membuat host key menjadi rahasia dan tidak mengubah model verifikasi key.

Kontak pertama memerlukan sumber trust

Binding langsung pada known_hosts memiliki persoalan bootstrap: client yang menghubungi host untuk pertama kali belum memiliki key tersimpan sebagai pembanding.

Trust-on-first-use interaktif dapat meminta operator menerima fingerprint yang disajikan. Keputusan pertama itu kemudian menjadi binding persisten, tetapi kekuatannya bergantung pada jalur yang dipakai untuk memverifikasi fingerprint. Penerimaan tanpa pemeriksaan menjadikan kontak pertama sebagai enrollment tanpa autentikasi.

Pada sistem terkelola, host key atau fingerprint dapat didistribusikan melalui channel konfigurasi tepercaya sebelum koneksi SSH pertama. Dengan cara ini, bootstrap trust berada pada sistem konfigurasi, bukan prompt interaktif.

Fokus utamanya bukan sekadar apakah key tersebut baru. Client harus memiliki dasar terautentikasi untuk mengaitkan key dengan host yang dituju.

Fingerprint membuat key praktis untuk dibandingkan

Host public key berukuran panjang, sehingga client menampilkan fingerprint ringkas yang diturunkan darinya. Fingerprint merupakan identifier untuk perbandingan; nilainya bukan public key pengganti dan tidak perlu dirahasiakan.

Nilai pemeriksaan fingerprint out-of-band bergantung pada independensi channel. Membaca fingerprint dari endpoint belum terverifikasi yang sama dengan pemasok host key SSH tidak menciptakan jalur trust kedua. Portal deployment, inventory konfigurasi, console, atau channel administratif terautentikasi lain dapat menjadi dasar terpisah bila memang dioperasikan untuk tujuan tersebut.

Operator juga perlu membandingkan algorithm dan identitas key yang memang hendak dipercaya. Server dapat menawarkan beberapa algorithm host key, sedangkan binding tersimpan dapat bergantung pada konfigurasi client dan hasil negosiasi.

Host certificate memindahkan trust dari key individual ke CA

SSH host certificate menyediakan model lain. Alih-alih memasang setiap host public key langsung ke setiap client, SSH certificate authority menandatangani host certificate. Client mempercayai CA untuk identitas host tertentu dan memverifikasi bahwa certificate yang disajikan valid bagi destination.

Secara konseptual:

SSH host CA tepercaya
        |
        | menandatangani
        v
host certificate
        |
        +-- host public key
        +-- principals
        +-- validity interval
        |
        v
client memverifikasi certificate dan proof server

Model ini dapat mengurangi distribusi key langsung pada fleet besar. Pada saat yang sama, authority terkonsentrasi pada CA signing key dan proses issuance. Proteksi key tersebut, pembatasan issuance, dan operasi renewal menjadi bagian dari boundary autentikasi host.

SSH host certificate berbeda dari certificate Web PKI publik. Trust anchor, format certificate, principal, dan policy operasionalnya berada dalam sistem trust SSH.

DNS dapat membawa record SSHFP, tetapi validasi tetap penting

DNS mendefinisikan record SSHFP untuk memublikasikan fingerprint host key SSH. Client dapat memakai record tersebut sebagai input verifikasi host key, tetapi response DNS tanpa autentikasi bukan pengganti yang kuat untuk identitas host terautentikasi.

Nilai keamanannya bergantung pada cara data SSHFP diautentikasi dan cara client dikonfigurasi untuk memakainya. DNSSEC dapat menyediakan autentikasi asal data dan integritas untuk data DNS bertanda tangan ketika validation path tersedia. Hal itu tidak membuat setiap client SSH otomatis mempercayai setiap record SSHFP; perilaku client dan policy lokal tetap menentukan penerimaan.

Model ini juga mengaitkan rollover host key dengan state publikasi dan validasi DNS. Fingerprint yang stale atau salah dipublikasikan dapat menyebabkan kegagalan verifikasi walaupun server beroperasi normal.

Rotasi key merupakan transisi trust

Host key pada akhirnya perlu diganti karena policy lifecycle, migrasi server, perubahan algorithm, atau key exposure. Rotasi harus mempertahankan jalur terautentikasi dari state trust lama ke state baru.

Mengganti key server terlebih dahulu lalu meminta semua client mengabaikan warning memperlakukan transisi terkontrol seperti perubahan identitas tanpa penjelasan. Prosedur yang lebih baik mendistribusikan binding baru melalui channel terautentikasi, memakai sistem certificate terkelola, atau memakai fitur protocol dan client yang sesuai dengan model trust deployment.

Saat incident response, perubahan host key yang tidak diperkirakan sebaiknya diperiksa sebelum credential dikirim. Penjelasan yang sah dapat ada, tetapi warning tersebut secara khusus menunjukkan bahwa binding identitas yang sebelumnya tersimpan tidak lagi cocok.

Automation memerlukan bootstrap yang lebih ketat

Job non-interaktif tidak dapat membuat penilaian visual yang bermakna terhadap prompt fingerprint. CI worker, deployment agent, backup job, dan sistem konfigurasi karena itu memerlukan host trust yang sudah dipasang sebelum koneksi atau mekanisme terkelola seperti SSH host certificate.

Menonaktifkan pemeriksaan host key agar automation tidak gagal menghapus autentikasi server dari koneksi SSH. Transport dapat tetap terenkripsi sementara automation kehilangan kepastian tentang server yang menjadi endpoint.

Desain yang tahan lama memperlakukan material identitas host sebagai konfigurasi dengan lifecycle sendiri: pasang melalui channel tepercaya, tinjau perubahan, lakukan rotasi secara sengaja, dan gunakan perilaku fail-closed ketika identitas tidak dapat diverifikasi.

Autentikasi host SSH merupakan persoalan binding, bukan sekadar detail key exchange. Server membuktikan kepemilikan private host key, sedangkan client memutuskan apakah key atau certificate tersebut mewakili destination yang diminta. Koneksi terautentikasi hanya ketika kedua bagian itu bertemu pada trust boundary yang benar-benar dikendalikan deployment.