<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Autentikasi Host on Nalar</title>
    <link>https://nalar.dev/id/tags/autentikasi-host/</link>
    <description>Recent content in Autentikasi Host on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Wed, 23 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/autentikasi-host/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Sertifikat Host OpenSSH Menggantikan Pinning Key per Host</title>
      <link>https://nalar.dev/id/sertifikat-host-openssh-menggantikan-pinning-key-per-host/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/sertifikat-host-openssh-menggantikan-pinning-key-per-host/</guid>
      <description>&lt;h1 id=&#34;sertifikat-host-openssh-menggantikan-pinning-key-per-host&#34;&gt;Sertifikat Host OpenSSH Menggantikan Pinning Key per Host&lt;/h1&gt;&#xA;&lt;p&gt;Autentikasi host SSH melindungi client agar tidak diam-diam menerima key server berbeda untuk nama yang hendak dituju. Model &lt;code&gt;known_hosts&lt;/code&gt; 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.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SSHFP Mempublikasikan Fingerprint Host Key SSH melalui DNSSEC</title>
      <link>https://nalar.dev/id/sshfp-mempublikasikan-fingerprint-host-key-ssh-melalui-dnssec/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/sshfp-mempublikasikan-fingerprint-host-key-ssh-melalui-dnssec/</guid>
      <description>&lt;h1 id=&#34;sshfp-mempublikasikan-fingerprint-host-key-ssh-melalui-dnssec&#34;&gt;SSHFP Mempublikasikan Fingerprint Host Key SSH melalui DNSSEC&lt;/h1&gt;&#xA;&lt;p&gt;Client SSH memerlukan dasar tepercaya untuk menentukan apakah host key server benar-benar milik host yang dituju. Entri lokal &lt;code&gt;known_hosts&lt;/code&gt; menyediakan dasar tersebut setelah sebuah key diterima, tetapi koneksi pertama tetap memerlukan jalur verifikasi jika key belum diprovisikan sebelumnya.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
