Live data from Hacker News

We need better support for SSH host certificates

mjg59.dreamwidth.org

51–60 of 161 posts

Re: We need better support for SSH host certificates

#51

Another problem with SSH is that people remove the key check completly in automations since some services just rotates the keys without telling. Or for being lazy.

That's also solved with host CA. You can rotate the host keys, add new machines/keys however you want, and all that matters is whether the host keys are signed with a trusted CA, when you setup automation to trust that CA.

Re: We need better support for SSH host certificates

#52

Since the blog author didn't mention it, or doesn't know about it, fun fact, you can store host keys in DNS (make sure to use DNSSEC too of course!) https://en.wikipedia.org/wiki/SSHFP_record Of course this has its own challenges, but if you automate your DNS, this can be neat! Cheers!

FWIW, many people regretted using DNSSEC. So take it with a grain of salt.

Re: We need better support for SSH host certificates

#53
post #42
post #33

Earlier quoted context omitted.

The usual counter-argument for https, is that the eggs are already in that basket since anyone with control of dns can just get a new certificate. For ssh that doesn't really apply as clearly though.

Getting a cert requires someone to either compromise the primary DNS server for the domain, or to compromise DNS in multiple independent locations to serve consistent false answers to the probes. It's true that much of the TLS ecosystem is somewhat bound to DNS being trustworthy, but not to the same extent that SSHFP is.

That also shows up on Certificate Transparency logs.

Re: We need better support for SSH host certificates

#55
post #33

Earlier quoted context omitted.

As far as I can tell, DNS-based authentication puts all the trust eggs in the DNS root basket, and then again, in the TLD basket. This seems incredibly brittle and fraught with peril. Am I missing something?

The usual counter-argument for https, is that the eggs are already in that basket since anyone with control of dns can just get a new certificate. For ssh that doesn't really apply as clearly though.

> For ssh that doesn't really apply as clearly though.

Do you think that DNS-based proof of ownership is not something that CAs would use for SSH certification?

Re: We need better support for SSH host certificates

#57

Since the blog author didn't mention it, or doesn't know about it, fun fact, you can store host keys in DNS (make sure to use DNSSEC too of course!) https://en.wikipedia.org/wiki/SSHFP_record Of course this has its own challenges, but if you automate your DNS, this can be neat! Cheers!

I’d been wanting to use this for a while, but support is lacking for most DNS providers. Maybe it should go the way of SPF and reuse TXT instead. CloudFlare added support in 2018: https://blog.cloudflare.com/additional-record-types-availabl... AWS still doesn’t support it: http://web.archive.org/web/20210429183447/https://forums.aws... Namecheap doesn’t: https://www.namecheap.com/support/knowledgebase/article.aspx...…

It specifically needed to be its own record as the record requires DNSSEC to verify that the returned SSH key is trusted. Using TXT would be ridiculously insecure as it cannot force the DNSSEC verification step that SSHFP as a unique record gives.

Definitely annoying, but does ensure that the returned SSH key is always correct and not from a forged record.

Re: We need better support for SSH host certificates

#58
post #8

Yes! SSH certificates are awesome, both for host- and client-verification. Avoiding Trust on First Use is potentially a big benefit, but the workflow improvements for developers, and especially non-technical people, is a huge win too. At work, we switched to Step CA [1] about 2 years ago. The workflow for our developers looks like: 1. `ssh client-hosts-01` 2. Browser window opens prompting for AzureAD login 3. SSH co…

GitHub does have support for SSH CAs, but it's an Enterprise feature: https://docs.github.com/en/enterprise-cloud@latest/organizat...

Re: We need better support for SSH host certificates

#59

Since the blog author didn't mention it, or doesn't know about it, fun fact, you can store host keys in DNS (make sure to use DNSSEC too of course!) https://en.wikipedia.org/wiki/SSHFP_record Of course this has its own challenges, but if you automate your DNS, this can be neat! Cheers!

A comment mentions it[0] (I'll repeat here for ease) > SSHFP: > https://www.rfc-editor.org/rfc/rfc4255 >> Re SSHFP: >> Regarding DNS as a database for keys... Please stop this madness. >> DNS isn't a database. >> It's not a configuration store. >> It was meant and should be used only for name resolution. [0] https://mjg59.dreamwidth.org/65874.html?thread=2106450#cmt21...

MX records don't fit into the "only for name resolution" mantra either but no one has advocated that we stop using those have they? That also ignores all of the other record types that aren't just for name resolution too.

Re: We need better support for SSH host certificates

#60
post #8

Yes! SSH certificates are awesome, both for host- and client-verification. Avoiding Trust on First Use is potentially a big benefit, but the workflow improvements for developers, and especially non-technical people, is a huge win too. At work, we switched to Step CA [1] about 2 years ago. The workflow for our developers looks like: 1. `ssh client-hosts-01` 2. Browser window opens prompting for AzureAD login 3. SSH co…

GitHub does have support for SSH CAs, but it's an Enterprise feature: https://docs.github.com/en/enterprise-cloud@latest/organizat...

That's very interesting, thank you for linking!
Post reply on HN