SSH

Keamanan Siber / 24 Sep 2026 / 5 min read

SSHFP Mengikat Fingerprint Host Key SSH ke DNSSEC

Klien SSH harus menentukan apakah host key yang diberikan server memang milik host yang dituju. Key yang sudah tersimpan dapat menjadi referensi pada koneksi berikutnya, tetapi koneksi pertama memerlukan dasar autentikasi lain. SSHFP menempatkan fingerprint public host key SSH di DNS agar klien dapat membandingkan key dari server dengan data yang diperoleh melalui jalur terpisah. Record DNS itu sendiri bukan trust anchor. RFC 4255 mengaitkan verifikasi SSHFP tepercaya dengan data DNS yang terautentikasi. DNSSEC melindungi jalur lookup dan memungkinkan klien pemvalidasi membedakan data bertanda tangan dari jawaban DNS yang tidak terautentikasi. Properti keamanan yang berguna berasal dari kombinasi tersebut: SSH menyediakan host key, SSHFP membawa fingerprint-nya, dan DNSSEC mengautentikasi record DNS yang dipakai untuk perbandingan.

Keamanan Siber SSH

Keamanan Siber / 23 Sep 2026 / 4 min read

SSHFP Mempublikasikan Fingerprint Host Key SSH melalui DNSSEC

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.

Cybersecurity SSH

Keamanan Siber / 23 Sep 2026 / 5 min read

Sertifikat Host OpenSSH Menggantikan Pinning Key per Host

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.

Cybersecurity OpenSSH

Keamanan Siber / 21 Sep 2026 / 6 min read

Verifikasi Host Key SSH Mengikat Koneksi ke Identitas Server

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.

Keamanan Siber SSH

Keamanan Siber / 21 Sep 2026 / 6 min read

Sertifikat SSH Mengikat Identitas ke Principal dan Batasan

Sertifikat SSH Mengikat Identitas ke Principal dan Batasan Public key SSH mentah menjawab pertanyaan yang sempit: apakah client yang terhubung memiliki private key yang berpasangan dengan public key ini? Authorization masih membutuhkan pemetaan lain. Server biasanya menaruh key yang diterima di authorized_keys, sering kali bersama option yang membatasi tindakan key tertentu. Sertifikat OpenSSH menambahkan layer identitas bertanda tangan di sekitar public key. Sertifikat dapat membawa principal, interval validitas, critical option, extension, serial number, dan key identifier. Server yang dikonfigurasi untuk mempercayai signing CA dapat memvalidasi sertifikat tersebut tanpa menyimpan public key mentah milik pemegangnya sebagai entry authorization terpisah.

Cybersecurity SSH

Keamanan Siber / 21 Sep 2026 / 6 min read

Sertifikat SSH Memusatkan Kepercayaan Akses pada Otoritas Penandatangan

Sertifikat SSH Memusatkan Kepercayaan Akses pada Otoritas Penandatangan Akses SSH berbasis public key sering dimulai dengan pemetaan sederhana: taruh public key pengguna di authorized_keys, simpan private key pada pengguna, lalu server menerima pihak yang dapat membuktikan kepemilikan private key pasangannya. Model ini langsung dan efektif, tetapi biaya administrasinya meningkat ketika jumlah pengguna dan host bertambah. Setiap host dapat menjadi lokasi lain tempat status akses harus ditambahkan, diaudit, dan dicabut. Sertifikat OpenSSH mengubah model distribusi tersebut. Certificate authority menandatangani public key SSH dan menyertakan metadata identitas serta policy. Server yang dikonfigurasi untuk mempercayai CA itu dapat menerima sertifikat yang diterbitkannya tanpa menyimpan setiap key pengguna secara lokal. Titik kepercayaan bergeser dari sekumpulan besar key individual menuju sekumpulan lebih kecil otoritas penandatangan beserta policy di sisi server.

Cybersecurity SSH

Keamanan Siber / 20 Sep 2026 / 5 min read

Sertifikat User SSH Mengikat Kepercayaan CA ke Principal

Sertifikat User SSH Mengikat Kepercayaan CA ke Principal Mengelola akses SSH dengan public key individual cukup sederhana pada skala kecil. Setiap server dapat menyimpan daftar key yang diterima dalam authorized_keys. Ketika jumlah orang dan host bertambah, kontrol akses juga menjadi persoalan distribusi key: penambahan, rotasi, dan penghapusan identitas membutuhkan perubahan pada mesin yang mempercayainya. Sertifikat user OpenSSH menawarkan model kepercayaan yang berbeda. Server dapat mempercayai user certification authority (CA), lalu menerima sertifikat user yang ditandatangani CA tersebut ketika sertifikat juga memenuhi policy autentikasi server. Tanda tangan CA hanya menjawab sebagian keputusan. Principal, validity interval, opsi sertifikat, dan konfigurasi server menentukan di mana serta bagaimana key yang ditandatangani dapat digunakan.

Cybersecurity OpenSSH

Keamanan Siber / 19 Sep 2026 / 6 min read

Kontinuitas Host Key SSH Adalah Batas Trust di Sisi Client

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.

Keamanan Siber SSH