Sertifikat Host OpenSSH Menggantikan Pinning Key per Host
Autentikasi host SSH melindungi client agar tidak diam-diam menerima key server berbeda untuk nama yang hendak dituju. Model known_hosts yang umum dapat melakukan pinning key secara langsung ke sebuah host. Model ini sederhana, tetapi pengoperasiannya pada fleet besar menimbulkan masalah distribusi: host baru memerlukan entri tepercaya, rotasi key terencana mengubah pin, dan entri lama dapat bertahan setelah infrastruktur berubah.
Sertifikat host OpenSSH memindahkan keputusan trust itu satu tingkat ke atas. Client dapat mempercayai certificate authority (CA) host, sedangkan server menyajikan sertifikat host yang ditandatangani CA tersebut. Client tetap memvalidasi host key, tetapi penerimaan bergantung pada signature sertifikat, identitas host, interval validitas, dan semantik sertifikat, bukan pin jangka panjang yang terpisah untuk setiap server.
Sertifikat host menandatangani public host key
Sertifikat OpenSSH bukan sertifikat X.509. Formatnya adalah format sertifikat OpenSSH yang membawa public key beserta metadata bertanda tangan. Untuk autentikasi host, sertifikat ditandai sebagai sertifikat host dan dapat memuat satu atau beberapa principal valid yang mewakili identitas host.
CA menandatangani public host key; CA tidak memerlukan private host key. Server tetap menyimpan private host key miliknya dan menyajikan sertifikat yang sesuai selama SSH key exchange. Client yang dikonfigurasi untuk mempercayai CA penerbit dapat memvalidasi signature sertifikat terhadap CA key tersebut.
Pemisahan ini penting secara operasional. CA key menjadi trust anchor, sedangkan setiap server tetap memegang private host key sendiri. CA tidak perlu menyimpan salinan private key server hanya untuk menerbitkan sertifikat host.
Principal mengikat sertifikat ke identitas host
Signature CA yang valid saja tidak cukup untuk membuat satu sertifikat host mewakili semua hostname. Sertifikat host membawa principal, dan verifikasi client membandingkan identitas tujuan dengan nama yang diizinkan sertifikat berdasarkan aturan sertifikat host OpenSSH.
Sertifikat yang diterbitkan untuk db01.example.net tidak seharusnya menjadi otorisasi bagi host yang tidak terkait hanya karena keduanya dapat memakai sertifikat dari CA tepercaya yang sama. Kumpulan principal bertanda tangan mempersempit identitas yang dapat diwakili sertifikat tersebut.
Karena itu, kebijakan penerbitan menjadi bagian dari batas keamanan. Otomasi yang meminta atau menandatangani sertifikat memerlukan input nama principal yang terkendali. Kumpulan principal yang luas memperbesar kumpulan nama yang dapat menerima host key beserta sertifikatnya jika material tersebut jatuh ke pihak yang tidak berwenang.
Record @cert-authority menetapkan trust CA host
Client OpenSSH dapat menempatkan marker @cert-authority di known_hosts. Pattern pada record tersebut menentukan hostname tempat CA key yang tercantum dipercaya untuk mengesahkan host key.
Secara konseptual, relasi trust tersebut seperti berikut:
pattern known_hosts
|
@cert-authority -> public key CA host
|
+-> memverifikasi sertifikat host
|
+-> principal cocok dengan tujuanPattern hostname dan principal sertifikat memiliki peran berbeda. Pattern known_hosts membatasi tempat client menerima sebuah CA sebagai authority. Principal pada sertifikat membatasi identitas yang diotorisasi CA untuk host key tertentu. Kedua pemeriksaan tersebut mempersempit penerimaan.
Karena itu, entri CA global harus dibuat secara sengaja. Mempercayai satu CA untuk namespace yang luas memberi CA tersebut wewenang menerbitkan sertifikat host dalam cakupan yang dikonfigurasi.
Interval validitas mengubah rotasi menjadi proses penerbitan
Sertifikat OpenSSH memuat batas validitas. Client menolak sertifikat di luar interval yang berlaku ketika validasi sertifikat diterapkan. Masa berlaku yang lebih pendek dapat mengurangi ketergantungan pada distribusi pin host key pengganti selama rotasi rutin, karena sertifikat baru dapat mengikat key pengganti ke identitas host yang sama.
Hal itu tidak menghapus pekerjaan lifecycle. Penerbitan harus selesai sebelum sertifikat aktif kedaluwarsa, server harus memuat sertifikat yang dituju beserta private key yang cocok, dan clock perlu cukup selaras untuk pemeriksaan validitas. Sertifikat yang belum valid atau sudah kedaluwarsa dapat membuat layanan SSH yang sehat gagal pada autentikasi host.
Masa berlaku sertifikat juga tidak mencabut key yang terkompromi secara seketika. Kedaluwarsa memberi batas waktu pada penerimaan sertifikat normal, tetapi respons insiden dapat memerlukan kontrol pencabutan terpisah dan penggantian credential yang terdampak.
Pencabutan tetap menjadi kontrol terpisah
OpenSSH mendukung penanganan revoked key melalui mekanisme seperti revoked keys file yang dikonfigurasi pada client. Deployment sertifikat tidak seharusnya menganggap masa berlaku singkat mencakup setiap jendela kompromi.
Objek yang ditolak juga perlu ditentukan dengan tepat. Operator mungkin perlu menolak host key tertentu, sertifikat tertentu, atau trust yang berakar pada sebuah CA, bergantung pada insiden. Menghapus atau mengganti CA trust anchor berdampak jauh lebih luas daripada mengganti satu sertifikat server.
Asimetri tersebut menjadi alasan untuk melindungi private key CA host lebih kuat daripada host key server biasa. CA key yang terkompromi dapat memungkinkan sertifikat host tanpa otorisasi di tempat client mempercayai CA itu dan sertifikat yang dihasilkan memenuhi pemeriksaan lainnya.
Cakupan CA membatasi blast radius
Satu CA host untuk setiap environment mudah dioperasikan, tetapi membentuk trust domain yang besar. CA terpisah atau record trust client dengan cakupan sempit dapat mengurangi wewenang yang melekat pada satu signing key.
Sebagai contoh, fleet production dan development dapat memakai trust anchor berbeda. Konfigurasi client juga dapat membatasi CA pada namespace hostname yang dituju, bukan menerimanya untuk destination sembarang. Batas yang tepat mengikuti kepemilikan administratif dan kebutuhan containment saat terjadi kegagalan, bukan sekadar kemudahan penerbitan sertifikat.
Akses signing CA juga memerlukan disiplin yang sama. Issuer otomatis sebaiknya mengautentikasi request, membatasi principal yang diizinkan, membatasi masa berlaku sertifikat sesuai kebijakan, dan menjaga jalur penerbitan yang dapat diaudit. Sertifikat host menyederhanakan distribusi trust pada client; mekanisme ini tidak membuat signing tanpa batas menjadi aman.
Sertifikat host tidak menggantikan autentikasi user
Sertifikat host mengautentikasi sisi server pada koneksi SSH. Sertifikat ini tidak dengan sendirinya memberi otorisasi kepada seseorang atau workload untuk login. Autentikasi user tetap merupakan tahap terpisah dan dapat memakai password, public key, sertifikat user, credential berbasis hardware, atau mekanisme lain yang didukung deployment.
OpenSSH juga mendukung sertifikat user, tetapi sertifikat host dan user memiliki tipe sertifikat serta peran kebijakan yang berbeda. Menganggap CA host tepercaya sebagai CA user akan mencampurkan dua keputusan trust yang berbeda dan tidak boleh diasumsikan hanya karena kedua sisi mendukung sertifikat.
Trust anchor menjadi konfigurasi client yang bertahan lama
Pinning per host menjadikan setiap host key sebagai record trust client yang bertahan lama. Sertifikat host mengubah CA public key beserta cakupan hostname-nya menjadi konfigurasi yang bertahan, sementara sertifikat host individual dapat dirotasi di bawah batas tersebut.
Trade-off keamanannya spesifik. Perubahan fleet lebih mudah dioperasikan karena client tidak memerlukan pin baru untuk setiap penggantian host key yang sah. Sebagai gantinya, private key CA dan kebijakan penerbitan menjadi kontrol bernilai lebih tinggi. Penetapan principal yang ketat, validitas terbatas, trust CA yang memiliki cakupan, signing key yang terlindungi, dan prosedur pencabutan eksplisit menjaga sentralisasi tersebut agar tidak berubah menjadi wewenang tanpa batas.