I know people do this, but I can't get my head around it. SSH is end-to-end secure even if the entire DNS hierarchy is corrupted. The DNSSEC PKI is controlled at its roots by governments, and one level of branches down by a set of companies not known for integrity and especially strong security practices. Why would you give any of these entities any influence over your authorized keys?

DNSSEC is top-down securing chain, DNSCrypt bottom-up. Each has their pros and cons. Relying on your government to keep you secure can be a valuable factor, depending on your threat model.

Ok, these are words, but again I'm not talking about DNS security here, I'm talking about SSH key distribution. Why would you elect to have your key distribution controlled by the DNS PKI? What's the upside? The downside is, an actor with control over the DNS PKI (there are many of those; see, for instance, every DOJ seizure of a domain) gets a degree of control over your SSH authorized keys. Seems... bad?

Agreed completely. The threat model for DNSSEC is vast; why would you diminish the security of a perfectly good end-to-end model in SSH keys or certificates, as long as you control 100% of that infrastructure.

Introducing any outside actors at all objectively diminishes the security of the whole model by becoming another link in the chain, even if that link isn't necessarily the weakest (and I certainly believe it would be, because both DNSSEC and the public Certificate Authority industry are object lessons for the abject failure of highly centralized global, government-wide, or even just company-wide security), but simply increasing any of the surface area is enough to decrease the security of the system.

You'd have to compromise not only the root keys just to get into my infrastructure, but sign all the zones from there downwards, and intercept all DNS traffic leaving that server in the first place. That's secure enough for me.

This method puts a lot of reliance on DNSSEC working and trusting that it is preventing spoofing. I personally wouldn't rely on this in production, there are too many stories about DNSSEC cutovers rendering the domain unresolvable for hours+. Imagine not being able to get to your servers too...!

My DNS zones are not hosted on those servers, Google Cloud DNS does the dnssec signing, and there is a breakglass key installed on there too that when used automatically sends alerts out.

Hesiod, now there’s a name I haven’t heard in a long time

https://en.m.wikipedia.org/wiki/Hesiod_(name_service)

Is there some way I can purchase you a pint?

It would be rude of me to decline such an offer ;)

Please write a blog on this

A blog on this.

And I may well do. But it's probably not the best idea to do this on a larger scale, there are valid reasons why this is not a good thing to recommend -- if you miss one part (DNSSEC signing, or running a local validating resolver) you can end up with a vulnerable system.

I would love a HOWTO link.

Also, can the DNS server be public facing? Any issues with the authorized keys being public (AFAICT there isnt but i am not a security expert)?

There are none. In fact yours is already public: https://github.com/bshep.keys

There is technically one minor one, which really isn't one - but you should be aware of.

Someone can take your authorized keys and add them to a box they control, and trick you into logging in.

However, this would trigger the "new host" warning SSH gives you, and you can minimize this by minimizing which hosts you allow your private keys to be used on.

And if someone is so actively trying to attack you they probably have more direct methods available.

What? How? What does putting my authorized keys file on another host do in terms of tricking me to log in? Authorized keys only matters on the host you are using when you type `ssh <some.host>`. The ssh client compares the public key of the remote host to the list in your `authorized_keys` file and, only if there is a match, skips serving you TOFU.

EDIT: I mixed up authorized_keys and known_hosts. But, the remote server doesn't need your authorized_keys file to grant you access so not sure the visibility of authorized_keys matters.

You’re thinking of known_hosts, not authorized_keys.

You are right, I am. Now I understand the DNSSEC setup.

Known_hosts can also be put in DNSSEC, using the SSHFP DNS record. OpenSSH understands that out of the box.

This wouldn't matter anyway because the server can just give you access regardless of the auth provided.

I know you can restrict the methods on the client (and which keys you use) but can the client determine the host actually used it?

The remote host can do:

    fn authorized(peer: ClientConnection) -> bool {
      return true;
    }

Use `ssh -vv` and you'll see which methods are proposed and used.

Unless your keys are generated with low entropy (like the Debian CVE-2008-0166), publishing the public key file should not be an issue; that's from a cryptographic pov.

& as bombcar said, obviously if you ignore "unknown host" warnings, you can be tricked into logging into an attacker-controlled machine.

Often key files also contain "user@host" for the user&host the key was generated by&on. This identifier is then leaked, and you might want to avoid that. On my personal (and very objective! /s) paranoia scale this a 8/10. I'd definitely point it out to a customer during a pentest, but wouldn't really care if they "fixed" this (most of the time there is a lot of stuff that's more serious than knowing that the devops person is 'bro2000@jims-laptop').

SSHFP records largely solves the host key problem, but yes, the user is the weak point in the chain there.

A public key can be an identifier. Depending on what other information you share online or if a key is reused on GitHub it can be used to identify other places you visit and other artifacts associated with you. If your goal is anonymity then keeping you public keys secret or not attached to other personal information like a domain name is ideal. Almost all registrars are going to have a way to reveal your true identity.

doesn't this approach run into caching problems?

With a short TTL I imagine it's quite workable.

My TTL is lower than most people's SSH certificate validity duration, for sure :)

Yes. Hesiod is safer than DNS TXT once secured by DNSSEC, because I envision mass blocking of DNS TXT in the near future.

Good luck with that. DNS TXT records are used for a lot of infrastructure right now, from DMARC/SPF/DKIM to DNS-01 validation through LetsEncrypt afaik.

Yes, and that too will change … again.

Hesiod uses txt records. I am using IN class records too, as I do not have a DNS provider that supports HS class... But that's fine, it works!

What is the benefit?

I think,

1) You don't have to ssh-copy-id to new boxes, which is nice.

2) You can de-auth a key for all machines by changing the DNS record. This would depend on some propagation time but perhaps you can point the resolver at your nameserver directly which would avoid that.

You could simply choose a short TTL, or your tool could check for e.g. "some-name._sshkeys.whatever.tld" as well as "_revoked.some-name._sshkeys.whatever.tld" to handle revocation instantly

You could also just stick it behind a https GET and probably skip a bunch of bother.

Now you've just moved your authentication to the SSL PKI.

In that case, use the SSL certs directly. You'd have add support OpenSSH of course, or just convert the certificates to SSH format, but it would be architecturally much simpler.

As to the original question here, the benefit compared to other PKI alternatives (including the SSH PKI in the original question) is that revocation is much easier.

a fine bit of wizardry, thanks for sharing.