Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need better support for SSH host certificates

mjg59.dreamwidth.org

Post reply on HN
Print view View original

21–30 of 161 posts

Re: We need better support for SSH host certificates

#21

Post by captn3m0 »

purpleidea wrote: post #19

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...

GCP doesn’t: https://cloud.google.com/dns/docs/records

Azure doesn’t: https://learn.microsoft.com/en-us/azure/dns/dns-zones-record...

Re: We need better support for SSH host certificates

#22

Post by v7n »

rhco wrote: 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…

That is also the flow for Tailscale SSH

https://tailscale.com/kb/1193/tailscale-ssh/

Re: We need better support for SSH host certificates

#23

Post by [deleted] »

rhco wrote: 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…

[deleted]

Re: We need better support for SSH host certificates

#24

Post by ShroudedNight »

xurukefi wrote: post #20
purpleidea wrote: post #19

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!

This is such a nice and pragmatic solution. And yet for some reason people would rather prefer the CA madness we know in the HTTPS ecosystem to be established in the SSH world. I understand that DANE was ahead of its time which is why we settled with CAs for SSL certificates but can we please take a different route this time for SSH?

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?

Re: We need better support for SSH host certificates

#25

Post by deathanatos »

rhco wrote: 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…

> we've verified the host key (and not just TOFU'd it!),

How.

Specifically, what I cannot determine from their docs is how the VM obtains a host key/cert signed by the CA. How does the CA know the VM is who the VM says it is? (I.e., the bootstrap problem.)

(I assume that you also need your clients to trust the CA … and that has its own issues, but those are mostly human-space ones, to me. In theory, you can hand a dev a laptop pre-initialized with it.)

Re: We need better support for SSH host certificates

#26

Post by mjg59 »

deathanatos wrote: post #25
rhco wrote: 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…

> we've verified the host key (and not just TOFU'd it!), How . Specifically, what I cannot determine from their docs is how the VM obtains a host key/cert signed by the CA. How does the CA know the VM is who the VM says it is? (I.e., the bootstrap problem.) (I assume that you also need your clients to trust the CA … and that has its own issues, but those are mostly human-space ones, to me. In theory, you can hand a d…

I can't say in the general sense, but with GCP you can retrieve the EKpub of a VM's TPM via the control plane, and then use https://github.com/google/go-attestation to verify that an application key is associated with that TPM and hence that VM

Re: We need better support for SSH host certificates

#27

Post by godelski »

purpleidea wrote: post #19

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...

Re: We need better support for SSH host certificates

#28

Post by tjoff »

rhco wrote: 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…

If you are in the terminal and don't have access to a browser?

Re: We need better support for SSH host certificates

#29

Post by bawolff »

godelski wrote: post #27
purpleidea wrote: post #19

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...

>> DNS isn't a database.

>> It's not a configuration store.

Its quite literally both those things.

There may be practical reasons to question storing high value keys in dns. But not being a database of configuration info isn't one of them.

Re: We need better support for SSH host certificates

#30

Post by mjg59 »

purpleidea wrote: post #19

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!

SSH's key management in general doesn't depend on DNS being trustworthy, and I'm not sure that solving it by asserting that DNS is trustworthy is a great thing.
Post reply on HN