Kontinuitas Host Key SSH Adalah Batas Trust di Sisi Client

Koneksi SSH dapat menegosiasikan enkripsi yang kuat tetapi tetap mengautentikasi server yang salah. Enkripsi melindungi transport setelah key exchange membentuk konteks kriptografinya; enkripsi tidak secara mandiri menyatakan bahwa server key tersebut milik host yang memang dituju client. Keputusan identitas itu berada pada verifikasi host key.

Pada banyak client interaktif, artefak yang terlihat adalah entri known_hosts. Properti keamanan yang lebih mendasar adalah kontinuitas: client memerlukan dasar tepercaya untuk menerima sebuah host key saat ini dan untuk menentukan apakah key yang berbeda di kemudian hari merupakan rotasi yang sah atau endpoint yang tidak diharapkan.

Host key mengautentikasi server key, bukan hostname secara mandiri

Selama SSH key exchange, server membuktikan kepemilikan private key yang sesuai dengan host public key dengan menandatangani data pertukaran. Pertukaran yang dihasilkan mengikat sesi yang dinegosiasikan ke key tersebut. Client masih memerlukan aturan independen untuk menentukan apakah public key itu dapat diterima bagi tujuan yang hendak dihubungi.

Asosiasi host key yang tersimpan menyediakan salah satu aturan tersebut. Pada koneksi pertama, client dapat meminta operator menerima fingerprint yang disajikan lalu menyimpannya. Koneksi berikutnya dapat membandingkan key yang disajikan dengan nilai yang telah tersimpan.

Model ini umum disebut trust on first use. Kondisi keamanannya mudah terlewat: observasi pertama yang diterima menjadi titik acuan. Jika penyerang dapat mengganti server saat penerimaan awal dan operator menyetujui fingerprint pengganti, pemeriksaan kontinuitas berikutnya dapat mempertahankan asosiasi yang salah secara konsisten.

Kriptografi tidak gagal pada kondisi itu. Binding identitas awal dibentuk dari observasi yang belum diverifikasi.

Perubahan key bersifat ambigu secara desain

Ketidakcocokan host key tidak menunjukkan satu penyebab tunggal. Server mungkin dibangun ulang, key mungkin dirotasi, DNS mungkin mengarahkan nama ke sistem lain, layanan dengan load balancing mungkin memiliki host key yang tidak konsisten, sebuah alamat mungkin dialokasikan ulang, atau intermediary mungkin menyajikan endpoint berbeda.

Intersepsi aktif juga merupakan salah satu kemungkinan.

Karena itu, menonaktifkan error ketidakcocokan mengubah pemeriksaan identitas menjadi enkripsi tanpa autentikasi server yang dapat diandalkan. Sebaliknya, menganggap setiap perubahan key sebagai bukti serangan juga melebihkan informasi yang tersedia. Ketidakcocokan hanya membuktikan bahwa binding sebelumnya di sisi client tidak lagi cocok dengan key yang disajikan; penyelesaian perbedaan tersebut memerlukan sumber informasi identitas tepercaya lainnya.

Perbedaan ini penting secara operasional. Proses deployment yang merotasi host key tanpa mendistribusikan status trust baru dapat membiasakan operator melewati peringatan. Ketika bypass menjadi kebiasaan, kontrol masih ada di perangkat lunak tetapi tidak lagi membentuk batas yang dapat diandalkan.

Rotasi memerlukan jalur yang terautentikasi

Rotasi host key bukan sekadar pembuatan key. Rotasi adalah migrasi trust di sisi client.

Salah satu pendekatan mendistribusikan host key yang diharapkan melalui sistem konfigurasi yang autentisitasnya telah ditetapkan. Pendekatan lain memublikasikan record SSHFP dan mengandalkan validasi DNSSEC pada model deployment yang memperlakukan rantai tersebut sebagai otoritatif. OpenSSH juga mendukung mekanisme protokol yang dapat membantu client memperoleh host key tambahan dari server yang sudah diautentikasi menggunakan key tepercaya.

Setiap metode memiliki root of trust berbeda. Tidak satu pun membuat key yang baru diamati menjadi identitas valid hanya karena server menyajikannya.

Rotasi bertahap dapat mempertahankan kontinuitas dengan memperkenalkan key baru saat key lama yang tepercaya masih valid, memberi kesempatan client mencatat key tambahan, lalu menghentikan key lama setelah populasi berpindah. Prosedur tepatnya bergantung pada kemampuan client dan infrastruktur, tetapi invariannya tetap: otorisasi pengganti harus melewati kanal yang sudah dipercaya untuk keputusan tersebut.

Menghapus baris known_hosts yang lama lalu menerima key berikutnya secara interaktif mungkin memulihkan konektivitas. Tindakan itu sendiri tidak mengautentikasi key pengganti.

Alias host dan penggunaan ulang alamat memperumit binding

Objek yang disimpan client adalah asosiasi antara identifier tujuan dan satu atau beberapa key yang dapat diterima. Infrastruktur dapat membuat asosiasi itu kurang langsung daripada yang terlihat.

Sebuah hostname dapat berada di depan beberapa server. Satu server dapat merespons melalui beberapa nama. Alamat IP dapat digunakan ulang. Bastion host dan proxy command dapat mengubah rute jaringan sementara tujuan SSH logis tetap sama. Container dan virtual machine berumur pendek dapat mewarisi nama yang bertahan lebih lama daripada instance individual.

Pola tersebut tidak membuat pemeriksaan host key menjadi usang. Pola tersebut menjadikan model identitas sebagai pilihan arsitektural.

Jika sebuah layanan dirancang untuk menyajikan satu identitas SSH logis pada sebuah pool, provisioning host key harus sesuai dengan model tersebut. Jika setiap mesin dimaksudkan memiliki identitas berbeda, client memerlukan nama stabil atau pemetaan lain yang dapat mempertahankan perbedaan itu. Penggunaan ulang label tujuan untuk sistem yang tidak berkaitan mengurangi makna kontinuitas karena perubahan key dapat menjadi perilaku lifecycle normal, bukan kejadian identitas yang luar biasa.

Masalah yang sama muncul pada otomasi. CI runner yang selalu dimulai dengan trust database kosong tidak memiliki kontinuitas dari observasi sebelumnya. Mengisi expected key dari sumber konfigurasi terlindungi membentuk jalur trust yang berbeda dan biasanya lebih jelas dibanding mengambil key dari target tepat sebelum koneksi lalu mempercayai nilai yang baru diambil tersebut.

Fingerprint adalah bahan pembanding, bukan provenance

Fingerprint adalah representasi ringkas dari public key. Nilai ini berguna karena operator dapat membandingkan nilai pendek yang diperoleh melalui kanal terpisah tanpa memindahkan seluruh key.

Fingerprint tidak menyatakan asal key. Menampilkan fingerprint dari koneksi tanpa autentikasi yang juga memasok key tidak menciptakan verifikasi independen. Keamanan berasal dari perbandingan nilai tersebut dengan referensi yang diperoleh melalui kanal dengan integritas yang sesuai untuk keputusan itu.

Hal ini juga memengaruhi dokumentasi operasional. Fingerprint yang disalin ke ticket, catatan deployment, repository konfigurasi, atau console hanya dapat menjadi referensi sejauh sistem yang membawanya dipercaya dan akses untuk mengubahnya dikendalikan. Memindahkan string antar sistem mengubah jalur trust walaupun nilai kriptografinya tetap sama.

Kebijakan client menentukan apakah verifikasi menjadi enforcement

Implementasi SSH menyediakan kontrol kebijakan untuk host key yang belum dikenal dan yang berubah. Nama serta default persisnya bergantung pada implementasi, sehingga analisis keamanan perlu membedakan autentikasi protokol dari kebijakan client.

Kebijakan ketat dapat menolak tujuan yang key-nya belum diotorisasi. Kebijakan interaktif dapat mengizinkan seseorang membentuk binding baru. Kebijakan permisif dapat menerima key dengan verifikasi persisten yang minim atau tanpa verifikasi tersebut. Semuanya masih dapat menggunakan transport SSH terenkripsi.

Hal ini sangat penting untuk job tanpa operator. Tidak ada orang yang tersedia untuk membandingkan fingerprint, sehingga identitas yang diharapkan harus tersedia sebelum koneksi melalui konfigurasi, provisioning image, kebijakan sertifikat, SSHFP berbasis DNSSEC bila sesuai, atau mekanisme terautentikasi lainnya.

Host certificate menyediakan model lain. Alih-alih mendistribusikan setiap host public key ke setiap client, client dapat mempercayai host certificate authority dan menerima host certificate yang memenuhi kebijakan identitas terkonfigurasi. Ini menggeser batas operasional menuju perlindungan CA key, penerbitan sertifikat, penamaan principal, validity period, dan konfigurasi trust client. Model ini mengurangi distribusi key per host tetapi tidak menghapus kebutuhan atas trust anchor yang terautentikasi.

Enkripsi dan identitas server tetap merupakan properti terpisah

Verifikasi host key SSH mudah dianggap sebagai gangguan di sekitar kanal terenkripsi yang sudah aman. Pandangan itu membalik ketergantungannya. Sesi terenkripsi berguna untuk administrasi rahasia hanya ketika client juga dapat menetapkan bahwa peer kriptografinya merupakan server yang dapat diterima untuk tujuan yang dimaksud.

Kontrol yang bertahan bukan pesan peringatan atau format file known_hosts. Kontrol tersebut adalah transisi terautentikasi dari satu status identitas server yang diterima ke status berikutnya. Sistem yang membuat transisi ini eksplisit dapat merotasi key, membangun ulang host, dan mengotomatiskan koneksi tanpa menjadikan setiap perubahan identitas sebagai pengecualian manual.