Live data from Hacker News

We need better support for SSH host certificates

mjg59.dreamwidth.org

11–20 of 161 posts

Re: We need better support for SSH host certificates

#11

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.

SSH host certificates as somewhat of an abomination

Many would say x509 is the real abomination.

Re: We need better support for SSH host certificates

#12

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.

SSH host certificates as somewhat of an abomination Many would say x509 is the real abomination.

I might not disagree with you there.

However, for all its warts, x509 due to hardware implementations, seems a great deal more secure than sitting on the FS SSH host certificates.

Re: We need better support for SSH host certificates

#13
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…

I like this solution, thanks for sharing. Just need to swap it with my own OIDC compliant federated authentication server.

Re: We need better support for SSH host certificates

#14
No, you need to abolish SSH. It's an incredibly limiting protocol that does not support modern computing needs. Hacks and add-ons solve some but never all of its many problems.

Wire-level network protocols like Wireguard are somewhat useful, but largely a large step away from the modern best practices. We need more Zero Trust, Federated Identity, Fine-grained Access Control, and Least Privilege. Those solutions exist, but they are almost always for-pay, because SSH is always used as the default option, and so no more effort is put into better security practices.

And even without putting any real effort into a better protocol, you can just implement on top of HTTPS. Look at HTTPS+Git, compared to SSH+Git. First and foremost, this RSA key leak bullshit just wouldn't happen. Even if the TLS key on the server got leaked (and why the hell would it?! it gets generated automatically by Let's Encrypt), revoking and issuing a new one happens automatically for the client with no fraught extra options, and nobody's client configuration by default disables validating the certs! Then there's the fact that you can use a variety of AuthN+Z options, it goes over standard ports, and most providers give more fine-grained access control for it.

Nerds love SSH. But it is literally worse than the alternatives, and is in practice often not used in a secure manner. Kill your darlings and use something demonstrably better.

Re: We need better support for SSH host certificates

#15

No, you need to abolish SSH. It's an incredibly limiting protocol that does not support modern computing needs. Hacks and add-ons solve some but never all of its many problems. Wire-level network protocols like Wireguard are somewhat useful, but largely a large step away from the modern best practices. We need more Zero Trust, Federated Identity, Fine-grained Access Control, and Least Privilege. Those solutions exist…

> you need to abolish SSH. It's an incredibly limiting protocol that does not support modern computing needs

Yes! Please invent something else, and leave SSH alone.

Re: We need better support for SSH host certificates

#16

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.

Re: We need better support for SSH host certificates

#17
post #15

No, you need to abolish SSH. It's an incredibly limiting protocol that does not support modern computing needs. Hacks and add-ons solve some but never all of its many problems. Wire-level network protocols like Wireguard are somewhat useful, but largely a large step away from the modern best practices. We need more Zero Trust, Federated Identity, Fine-grained Access Control, and Least Privilege. Those solutions exist…

> you need to abolish SSH. It's an incredibly limiting protocol that does not support modern computing needs Yes! Please invent something else, and leave SSH alone.

I meant the protocol, not the program. A secure shell is still useful, but the old protocol is like a unix neckbeard that doesn't wanna learn containers. (And while we're on the subject, SSHD should support an HTTPS port and either serve a javascript client or accept websocket connections, because it is 2023 and that's what everyone wants anyway)

Re: We need better support for SSH host certificates

#18
post #15

Earlier quoted context omitted.

> you need to abolish SSH. It's an incredibly limiting protocol that does not support modern computing needs Yes! Please invent something else, and leave SSH alone.

I meant the protocol, not the program. A secure shell is still useful, but the old protocol is like a unix neckbeard that doesn't wanna learn containers. (And while we're on the subject, SSHD should support an HTTPS port and either serve a javascript client or accept websocket connections, because it is 2023 and that's what everyone wants anyway)

You may need to do some more research. SSHD can run on an HTTP port, but why bundle a web server and additional protocols into something? There are web based ssh clients - https://github.com/billchurch/webssh2 - simple google search.

Plenty of "neckbeards" understand containers and probably understand the underlying technologies (cgroups, etc) as well as comparable (or historical) approaches (jails, zones, etc) better than most.

But, because something doesn't cater to your whims, must complicate things that actually work.

Re: We need better support for SSH host certificates

#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!

Re: We need better support for SSH host certificates

#20

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?
Post reply on HN