SSHFP Mempublikasikan Fingerprint Host Key SSH melalui DNSSEC

Client SSH memerlukan dasar tepercaya untuk menentukan apakah host key server benar-benar milik host yang dituju. Entri lokal known_hosts menyediakan dasar tersebut setelah sebuah key diterima, tetapi koneksi pertama tetap memerlukan jalur verifikasi jika key belum diprovisikan sebelumnya.

SSHFP menempatkan fingerprint host key di DNS. RFC 4255 mendefinisikan resource record SSHFP agar client dapat membandingkan public key yang disajikan server SSH dengan fingerprint yang dipublikasikan untuk hostname tersebut. Properti keamanannya bergantung pada data DNS yang terautentikasi: fingerprint yang cocok dari jawaban DNS tanpa autentikasi tidak memenuhi kondisi trust yang ditetapkan untuk verifikasi SSHFP yang aman.

Record SSHFP mengidentifikasi algoritma key dan fingerprint

RDATA SSHFP memiliki tiga field: nomor algoritma public key, nomor tipe fingerprint, dan fingerprint itu sendiri.

host.example. IN SSHFP 4 2 <fingerprint>

Field numerik tersebut adalah identifier protokol, bukan label bebas. Field algoritma public key mengidentifikasi keluarga SSH key yang direpresentasikan record. Tipe fingerprint mengidentifikasi algoritma digest yang dipakai untuk menghasilkan fingerprint tersimpan. RFC 6594 menambahkan SHA-256 sebagai tipe fingerprint SSHFP dan memperluas registry algoritma public key untuk ECDSA.

Verifikasi mengharuskan identifier algoritma dan fingerprint hasil komputasi cocok dengan host key yang disajikan. Digest yang kebetulan sama dengan record untuk algoritma key lain bukan kecocokan valid menurut aturan pemrosesan SSHFP.

DNSSEC mengautentikasi jawaban DNS

Mempublikasikan record SSHFP di DNS biasa yang tidak ditandatangani tidak dengan sendirinya menghasilkan pernyataan host key yang aman. Penyerang yang dapat mengubah response DNS dapat mengganti fingerprint sekaligus mengalihkan jalur jaringan menuju server SSH.

RFC 4255 karena itu mengikat trust pada verifikasi SSHFP dengan autentikasi DNSSEC. Client perlu memvalidasi DNSSEC sendiri atau mengandalkan jalur resolver yang membawa hasil terautentikasi secara cukup aman untuk model trust client tersebut.

Dua operasi ini memiliki fungsi berbeda:

validasi DNSSEC   -> mengautentikasi data DNS SSHFP
perbandingan SSHFP -> mengikat data itu ke host key SSH yang disajikan

Keduanya tidak saling menggantikan. Record valid menurut DNSSEC yang berisi fingerprint salah menghasilkan mismatch. Fingerprint yang cocok tetapi diperoleh tanpa DNS terautentikasi tidak memiliki pernyataan DNS aman yang diperlukan untuk trust otomatis.

OpenSSH mengekspos kebijakan melalui VerifyHostKeyDNS

Client OpenSSH menyediakan VerifyHostKeyDNS untuk pemeriksaan host key berbasis SSHFP. Dengan nilai yes, key yang cocok dengan fingerprint DNS aman dapat dipercaya secara implisit. Dengan ask, informasi kecocokan fingerprint ditampilkan sementara kebijakan konfirmasi host key normal tetap berlaku. Default yang terdokumentasi adalah no.

Host server.example
    VerifyHostKeyDNS yes

Setting ini merupakan pilihan kebijakan client. Publikasi record SSHFP tidak memaksa setiap client SSH untuk membacanya, dan client yang tidak mengaktifkan kebijakan verifikasi kompatibel tetap memakai mekanisme host key yang telah dikonfigurasi.

OpenSSH juga dapat menghasilkan record presentasi SSHFP dari public host key melalui ssh-keygen -r. Pembuatan otomatis mengurangi penanganan digest secara manual, tetapi record yang dihasilkan tetap harus masuk ke authoritative DNS zone melalui jalur administratif tepercaya.

Enrollment menjadi bagian dari batas keamanan

DNSSEC melindungi data DNS setelah data tersebut dimasukkan ke signed zone dan divalidasi client. DNSSEC tidak membuktikan bahwa operator zone menerima host key yang benar sebelum mempublikasikan fingerprint-nya.

Transfer dari pengelolaan host key ke DNS karena itu merupakan tahap enrollment. Jika key tanpa otorisasi dimasukkan ke zone lalu ditandatangani secara benar, DNSSEC akan mengautentikasi state administratif yang keliru tersebut. Otomasi publikasi record SSHFP memerlukan input terautentikasi, otoritas update zone yang terkendali, dan asosiasi yang jelas antara hostname dan host key.

Batas ini serupa dengan sistem enrollment public key lain: validasi kriptografis dapat mempertahankan sebuah pernyataan tanpa membuktikan bahwa pernyataan tersebut benar saat dibuat.

Rotasi memerlukan overlap state DNS dan server yang disengaja

Sebuah host dapat mempublikasikan beberapa record SSHFP. Sifat ini dapat mendukung transisi key dengan mengizinkan fingerprint untuk lebih dari satu host key valid selama periode overlap yang terkendali.

Urutannya tetap penting. Mempublikasikan fingerprint baru sebelum client dapat menjumpai key baru menghindari jendela saat server menyajikan key yang belum ada di DNS terautentikasi. Menghapus fingerprint lama setelah key lama tidak lagi disajikan mempersempit kembali himpunan yang diterima.

Caching DNS menambah batas waktu lain. TTL dan cache resolver dapat mempertahankan RRset bertanda tangan yang lebih lama untuk suatu periode setelah perubahan authoritative. Prosedur rotasi perlu memperhitungkan perilaku propagasi tersebut dan tidak menganggap update authoritative langsung terlihat oleh setiap client.

SSHFP tidak menggantikan keamanan transport SSH

SSHFP berperan pada autentikasi host; mekanisme ini tidak mengenkripsi query DNS, membawa traffic sesi SSH, atau menggantikan SSH key exchange. Setelah host key diterima, mekanisme protokol SSH tetap membangun dan melindungi sesi.

DNSSEC juga menyediakan autentikasi asal data dan integritas untuk data DNS bertanda tangan, bukan kerahasiaan. Deployment yang memerlukan privasi query DNS membutuhkan mekanisme terpisah untuk properti tersebut.

Peran sempit ini berguna karena batasnya eksplisit. SSHFP mempublikasikan fingerprint host key, DNSSEC mengautentikasi pernyataan DNS, dan kebijakan client menentukan apakah kecocokan aman cukup untuk menerima host key. Pemisahan tersebut membuat verifikasi pada kontak pertama bergantung pada jalur trust yang dikelola, bukan prompt yang belum diverifikasi.