<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>OpenSSH on Nalar</title>
    <link>https://nalar.dev/id/tags/openssh/</link>
    <description>Recent content in OpenSSH on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Sun, 20 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/openssh/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Sertifikat User SSH Mengikat Kepercayaan CA ke Principal</title>
      <link>https://nalar.dev/id/sertifikat-user-ssh-mengikat-kepercayaan-ca-ke-principal/</link>
      <pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/sertifikat-user-ssh-mengikat-kepercayaan-ca-ke-principal/</guid>
      <description>&lt;h1 id=&#34;sertifikat-user-ssh-mengikat-kepercayaan-ca-ke-principal&#34;&gt;Sertifikat User SSH Mengikat Kepercayaan CA ke Principal&lt;/h1&gt;&#xA;&lt;p&gt;Mengelola akses SSH dengan public key individual cukup sederhana pada skala kecil. Setiap server dapat menyimpan daftar key yang diterima dalam &lt;code&gt;authorized_keys&lt;/code&gt;. Ketika jumlah orang dan host bertambah, kontrol akses juga menjadi persoalan distribusi key: penambahan, rotasi, dan penghapusan identitas membutuhkan perubahan pada mesin yang mempercayainya.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
