How about something very pragmatic: Use the same key you use for your webserver, which already has a valid SSL cert. Clients first connect to port 443 to get the public key and can verify the certificate. During the SSH handshake, the client then compares the host key with the previously obtained key of the certificate.
We need better support for SSH host certificates
71–80 of 161 posts
Re: We need better support for SSH host certificates
#72I wonder how many thousands (millions?) of man-hours of lost productivity over the world the Github SSH debacle resulted in. Not only for teams to fix the issue in a build pipeline no one touched for several years, but also the lost productivity for teams build/deploy pipelines to break, etc.
Re: We need better support for SSH host certificates
#73I wonder how many thousands (millions?) of man-hours of lost productivity over the world the Github SSH debacle resulted in. Not only for teams to fix the issue in a build pipeline no one touched for several years, but also the lost productivity for teams build/deploy pipelines to break, etc.
It's just a tiny, tiny fraction of the productivity gained by using platforms like Github.
Re: We need better support for SSH host certificates
#74Yes! 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…
Vault also supports both client and server ssh certificates [1]. I use terraform and vault to sign server certificates at creation time.
[1] https://developer.hashicorp.com/vault/docs/secrets/ssh/signe...
Re: We need better support for SSH host certificates
#75SSH doesn’t have a good revocation procedure. Perhaps integrating SSH certificates with OCSP is the way forward.
Re: We need better support for SSH host certificates
#76Earlier quoted context omitted.
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.
OpenSSH supports FIDO keys since 8.2p1 and has supported smart cards via GPG longer.
Re: We need better support for SSH host certificates
#77Since 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?
I'm going to skip the long part, but what you're basically requesting is that everyone must trust the countries operating their ccTLDs. Does that sound reasonable? I don't think so.
Re: We need better support for SSH host certificates
#78Earlier quoted context omitted.
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.
Checkmate!
Re: We need better support for SSH host certificates
#79Anyone else relying on GSSAPI key exchange & authentication instead?
Re: We need better support for SSH host certificates
#80No, 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…
> Then there's the fact that you can use a variety of AuthN+Z options, it goes over standard ports
What's a standard port? AFAIK 22 is a standard port. https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbe...
Are you saying that everything should only go over 443 (=HTTPS)?