Hacker News Reader

Comment by alwillis | Hacker News Reader

> DNSSEC as designed is pretty useless.

Another approach that we analysed in more detail is the distribution of the host key fingerprints via a special resource record. This removes any user interaction, potential human error, or presumed configuration of a user’s device because OpenSSH-client can query the DNS and do the comparison. It only requires the administrator to publish a host’s fingerprints as a set of SSHFP records, which can be securely obtained (DNSSEC). If the latter holds, MITM attacks are mitigated, and overall security is improved. [1]

[1]: "Improving SSH’s security with SSHFP DNS records" - https://blog.apnic.net/2022/12/02/improving-sshs-security-wi...

View on HN

I have never been able to get my head around the idea that the DNS should have anything whatsoever to do with my SSH fleet. The DNS exists to solve the problem of introductions between unaffiliated network endpoints. To a first approximation nobody SSH's to a random server. You don't need any third-party PKI to get optimal SSH security!

Same reason https://sshfp.github.io/sshfp.html exists, anchoring SSH fingerprints to the Web PKI: it's a convenient distribution method. Which helps, because people suck at distributing fingerprints. DNSsec and the Web PKI take an equivalent role here, I'd say.

Alternate solutions I'm aware of would be SSH certificates and querying LDAP. One of the issues with SSH certificates (AFAIK) is that they become rather cumbersome when administrative domains aren't cleanly separated, which is quite common once you're outside rigid and obvious organizational structures that reflect into sysadmin. LDAP has the same scoping issues, except even worse.

> You don't need any third-party PKI to get optimal SSH security!

This is a very binary view on an issue that is all about grimey, squishy user behavior. Sure, if users copy around SSH fingerprints, they don't need this. And either way they don't need it very often. But have you met users? The Web PKI goes to great lengths to avoid people shooting themselves in the foot (on both server and client side), why not look at some options for SSH?

You don't have to distribute fingerprints by hand. SSH already has a built-in PKI that handles this, and it's what most large fleet operators use (it's also the simplest way to connect an SSH fleet to an SSO IdP). SSH certificates, not WebPKI certificates.

> You don't have to distribute fingerprints by hand. SSH already has a built-in PKI that handles this, and it's what most large fleet operators use (it's also the simplest way to connect an SSH fleet to an SSO IdP). SSH certificates, not WebPKI certificates.

I know. I'm discussing them in my post.

If you're replying on posts without reading them in their entirety, that certainly explains some of the communication issues we were having on another post (re. DANE) a while back. I don't think I'm interested in any further exchange with you.

I read your whole post, which ended with "if users copy around fingerprints", which is a problem the built-in SSH PKI that large fleet operators already use solves. I don't think I misconstrued you.

You don't have to keep replying, but I'm going to point out that we have gotten no closer to finding a reason that anyone would even entertain the idea of SSHFP, a system that wires the already perfectly good SSH PKI subsystem into the state-controlled DNS PKI. Why would anybody ever do that?

The op is known to not read and spew propaganda.

SSHFPS is what I should be using in my homelab if it weren't for the awful split-DNS setup I have!

I personally prefer the theoretical advantages of SSH certificates, but those don't have CRL support (let alone an ACME alternative) as far as I know, so that's not exactly perfect either.

I want DNSSEC('s goals and ambitions) to succeed, but having a "trusted" ISP server that sets a "trust me bro" bit is the design flaw that kills the original design.

There's a patch for openssh to use the ldns library and do its own DNSsec validation. A few distros apply it to their packages, though I'm not sure what the current status is. It never got accepted into openssh sadly.

Reply on news.ycombinator.com