<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Host Authentication on Nalar</title>
    <link>https://nalar.dev/tags/host-authentication/</link>
    <description>Recent content in Host Authentication on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 23 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/host-authentication/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>OpenSSH Host Certificates Replace Per-Host Key Pinning</title>
      <link>https://nalar.dev/openssh-host-certificates-replace-per-host-key-pinning/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/openssh-host-certificates-replace-per-host-key-pinning/</guid>
      <description>&lt;h1 id=&#34;openssh-host-certificates-replace-per-host-key-pinning&#34;&gt;OpenSSH Host Certificates Replace Per-Host Key Pinning&lt;/h1&gt;&#xA;&lt;p&gt;SSH host authentication protects a client from silently accepting a different server key for a name it intended to reach. The familiar &lt;code&gt;known_hosts&lt;/code&gt; model can pin a key directly to a host. That model is simple, but operating it across a large fleet creates a distribution problem: new hosts need trusted entries, planned key rotation changes pins, and stale entries can survive after infrastructure changes.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SSHFP Publishes SSH Host Key Fingerprints Through DNSSEC</title>
      <link>https://nalar.dev/sshfp-publishes-ssh-host-key-fingerprints-through-dnssec/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/sshfp-publishes-ssh-host-key-fingerprints-through-dnssec/</guid>
      <description>&lt;h1 id=&#34;sshfp-publishes-ssh-host-key-fingerprints-through-dnssec&#34;&gt;SSHFP Publishes SSH Host Key Fingerprints Through DNSSEC&lt;/h1&gt;&#xA;&lt;p&gt;SSH clients need a trustworthy basis for deciding whether a server&amp;rsquo;s host key belongs to the intended host. A local &lt;code&gt;known_hosts&lt;/code&gt; entry supplies that basis after a key has been accepted, but the first connection still needs a verification path if the key was not provisioned in advance.&lt;/p&gt;&#xA;&lt;p&gt;SSHFP moves a host-key fingerprint into DNS. RFC 4255 defines the SSHFP resource record so a client can compare the public key presented by an SSH server with a fingerprint published for that hostname. The security property depends on authenticated DNS data: a matching fingerprint from an unauthenticated DNS answer does not provide the trust condition defined for secure SSHFP verification.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
