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

31–40 of 161 posts

Re: We need better support for SSH host certificates

#31

Post by Datagenerator »

throwaway892238 wrote: post #16
pyrolistical wrote: post #6

Seems like a pretty way to solve this by having ssh clients check the TLS of the host and then fetch the public key in a well know sub path. But the hard part is getting everybody to support this. We need to start somewhere. Maybe GitHub can use this bad publicity and turn this into one good

> Seems like a pretty way to solve this by having ssh clients check the TLS of the host If you're doing TLS then you might as well do HTTPS. GitHub already supports HTTPS and way more features for it than SSH, and HTTPS works over more networks than SSH does. Continuing to use SSH is literally just being obsessed with a backwards old protocol for nostalgia reasons.

Corporate networks will happily do DPI on TLS, no so much with SSH. So this 'error' of GitHub might be intentional in order to mold everything into something which they can monitor.

Re: We need better support for SSH host certificates

#32

Post by hnlmorg »

tjoff wrote: post #28
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?

Not the OP but if anyone doesn’t have access to a browser in my org then I can safely say they’re not accessing from a company laptop and thus should be denied access.

Re: We need better support for SSH host certificates

#33

Post by bawolff »

ShroudedNight wrote: post #24
xurukefi wrote: post #20

Earlier quoted context omitted.

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?

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.

Re: We need better support for SSH host certificates

#34

Post by 9dev »

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

I don’t believe in the forbidden fruit ideology. If it’s stupid and works well, it isn’t stupid.

People have been using DNS for all kinds of configuration for decades now, with great success. So what, other than a pedantic and grumpy programmer’s perspective, should keep us from using DNS for configuration records?

Re: We need better support for SSH host certificates

#35

Post by aorth »

OrvalWintermute wrote: post #10

I've always thought of SSH host certificates as somewhat of an abomination and maybe I am in the minority because the better solution was always about making SSH speak x509 properly https://roumenpetrov.info/secsh/index.html Roumen has been regularly updating this for a pretty long time now.

Can't view this site on mobile. Constantly refreshing and redirecting to itself on Firefox / Android...

Re: We need better support for SSH host certificates

#36

Post by V-eHGsd_ »

9dev wrote: post #34
godelski wrote: post #27

Earlier quoted context omitted.

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

I don’t believe in the forbidden fruit ideology. If it’s stupid and works well, it isn’t stupid. People have been using DNS for all kinds of configuration for decades now, with great success. So what, other than a pedantic and grumpy programmer’s perspective, should keep us from using DNS for configuration records?

i'm reminded of theo deraadt's answer when asked in a /. ama about firewall on a floppy.

> I must say that I am not a fan of these floppy-based routers. Essentially, you are taking one of the most unreliable pieces of storage known to man, and trying to build security infrastructure on it. That's madness.

dns is not the foundation upon which you want to build your secure infrastructure.

Re: We need better support for SSH host certificates

#37

Post by hamburglar »

hnlmorg wrote: post #32
tjoff wrote: post #28

Earlier quoted context omitted.

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

Not the OP but if anyone doesn’t have access to a browser in my org then I can safely say they’re not accessing from a company laptop and thus should be denied access.

Not sure why you'd get downvoted for this comment. This is likely very applicable for many orgs that have operator workstation standards -- they're some kind of window/osx/linux box with a defined/enforced endpoint protection measures, and they all have a browser. Any device I can imagine ssh'ing from that doesn't have a browser is definitely out of policy.

Re: We need better support for SSH host certificates

#38

Post by runeks »

throwaway892238 wrote: post #16
pyrolistical wrote: post #6

Seems like a pretty way to solve this by having ssh clients check the TLS of the host and then fetch the public key in a well know sub path. But the hard part is getting everybody to support this. We need to start somewhere. Maybe GitHub can use this bad publicity and turn this into one good

> Seems like a pretty way to solve this by having ssh clients check the TLS of the host If you're doing TLS then you might as well do HTTPS. GitHub already supports HTTPS and way more features for it than SSH, and HTTPS works over more networks than SSH does. Continuing to use SSH is literally just being obsessed with a backwards old protocol for nostalgia reasons.

> Continuing to use SSH is literally just being obsessed with a backwards old protocol for nostalgia reasons.

Honest question:

Client authorization (for private repos) is an important feature of SSH.

How does this work with HTTPS?

EDIT: I just remembered the existence of TLS client certificate authentication. I wonder if it's possible to use an SSH client key for this (making the server accept a self-signed client certificate from the list of keys in authorized_keys).

Re: We need better support for SSH host certificates

#39

Post by midasuni »

ShroudedNight wrote: post #24
xurukefi wrote: post #20

Earlier quoted context omitted.

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?

How do you authenticate the certificate issuing? Public CAs tend to use DNS (either host or dns txt records) to authenticate.
Post reply on HN