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

101–110 of 161 posts

Re: We need better support for SSH host certificates

#101

Post by lxgr »

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.

If TLS/HTTPS supported self-signed client certificates I could sympathize a bit more with this viewpoint.

As it is, I‘d argue that straightforward protocol layer client public key authentication is one of the biggest benefits of using SSH, although I do wish X509/PKI server authentication could optionally be used with it.

Re: We need better support for SSH host certificates

#102

Post by zomgwat »

gpderetta wrote: post #46
hnlmorg wrote: post #32

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

You really never ssh from one remote server to another?

SSHing from one remote server to another won’t be possible in a lot of environments due to network segmentation. For example, it shouldn’t be possible to hop from one host to another via SSH in a prod network supporting a SaaS service. Network access controls in that type of environment should limit network access to only what’s needed for the services to run.

Re: We need better support for SSH host certificates

#103

Post by lxgr »

SuperSandro2000 wrote: post #69

Part of the problem is also that ssh has host key rotation support but openssh client has it turned off by default

At least on macOS and Debian it is on by default:

> UpdateHostKeys is enabled by default if the user has not overridden the default UserKnownHostsFile setting and has not enabled VerifyHostKeyDNS, otherwise UpdateHostKeys will be set to no.

It's not that useful for actual key rotations, though; the use case seems to be more geared towards switching to newer key types (e.g. adding an Ed25529 key seamlessly) than replacing a potentially compromised key. At least I couldn't find a straightforward way for the OpenSSH sshd to actually provide two keys of the same type to my client.

All in all, I‘m not a fan of the feature – it seems to complicate key security for pretty marginal benefits.

That said, it did auto-upgrade the Github key for me as far as I can tell!

Re: We need better support for SSH host certificates

#104

Post by the8472 »

lucideer wrote: post #85
simiones wrote: post #82

Earlier quoted context omitted.

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 connection is accepted How is that simple, compared to `ssh -i .ssh/my-cert.rsa someone@destination --> connection is accepted, here's your prompt` ?

The former is discoverable: it doesn't require developers having ANY knowledge of command switches (no matter how basic) nor following a set of out-of-band instructions; the "how to" is included within the workflow.

The server could display that info when a user tries to log in via interactive authentication.

Re: We need better support for SSH host certificates

#105

Post by the8472 »

rfoo wrote: post #48
gpderetta wrote: post #46

Earlier quoted context omitted.

You really never ssh from one remote server to another?

Not GP, but: I do, however when I do this I make sure the certificate is signed with permit-agent-forwarding and demand people just forward their ssh agent on their laptops. This also discourages people from leaving their SSH private key on a server just for ssh-ing into other servers in CRON instead of using a proper machine-key.

Agent forwarding has its own security issues, you're exposing all your credentials to the remote.

It's better to configure jump hosts in your local ssh config.

Re: We need better support for SSH host certificates

#106

Post by Aeolun »

simiones wrote: post #82
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…

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 connection is accepted How is that simple, compared to `ssh -i .ssh/my-cert.rsa someone@destination --> connection is accepted, here's your prompt` ?

This is simple because it doesn’t require you to take any specific actions to make new/different hosts accessible.

If you deactivate someone in AD, poof, all their access is magically gone, instead of having to remove their public key from every server.

Re: We need better support for SSH host certificates

#107

Post by eythian »

matja wrote: post #96
j16sdiz wrote: post #49

Earlier quoted context omitted.

1. DNS is insecure.... DNSSEC, despite all the effort goes it, still does not work in most TLD and registers. 2. Cache. People are caching DNS aggressively. Often more aggressive than what the TTL allows. You don't want to save the fingerprint in a stale, insecure database like that.

DNS is only as stale as the cache that you trust. If the cache is not adhering to DNS standards then it is probably not one you should be trusting. Nothing is stopping a DNS client contacting the authoritative nameservers without a cache, or using your own cache that implements the standard correctly.

This is pushing the problem out to an edge that can't really deal with it, i.e. everyone outside a controlled environment. Most people don't know anything about how their DNS cache behaves, and the server-side (where ideally the security posture should be controlled from as much as possible) can't have any influence over it.

If you start using other ways of using DNS, then you might as well not use DNS and instead develop something more suited to the purpose.

Re: We need better support for SSH host certificates

#108

Post by dane-pgp »

lozenge wrote: post #53
mjg59 wrote: post #42

Earlier quoted context omitted.

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.

People used HTTPS before there were Certificate Transparency logs, so there's no reason why those couldn't be run for DNSSEC too.

https://datatracker.ietf.org/doc/html/draft-zhang-trans-ct-d...

https://www.huque.com/2014/07/30/dnssec-key-trans.html

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg...

Re: We need better support for SSH host certificates

#109

Post by throwawaaarrgh »

lxgr wrote: post #101
throwaway892238 wrote: post #16

Earlier quoted context omitted.

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

If TLS/HTTPS supported self-signed client certificates I could sympathize a bit more with this viewpoint. As it is, I‘d argue that straightforward protocol layer client public key authentication is one of the biggest benefits of using SSH, although I do wish X509/PKI server authentication could optionally be used with it.

> straightforward protocol layer client public key authentication is one of the biggest benefits of using SSH

I disagree, it seems not straightforward at all.

First as a user you have to generate a key. You need to install software and look up a manual. Then you have to give a server admin your public key, which for many users is often confused for the private key and thus defeats the purpose. Then when you connect to the server you have to manually validate the host fingerprint, which again requires more commands and documentation.

The alternative (in HTTPS) is to use Let's Encrypt on the server, and enable HTTP Basic authentication from either a web server or a reverse proxy. The admin gives the user their login and the client just connects.

With those two features you get 1) strong encryption that your user does not need to manually validate, and 2) a non-bruteforceable authentication token. Not only that, but it's compatible with a thousand other applications and modifiable in a million ways.

Re: We need better support for SSH host certificates

#110

Post by calvinmorrison »

misnome wrote: post #87
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…

One thing I've never understood about SSH certificates for client identification - it looks like it causes the requirement that _at some point_ ssh private keys and the certificate private key need to both be in the same place? And if this is the case, then doesn't that imply that you need to have a service where users upload their private key? Which would mean you have one single point of attack/DOS/failure that nee…

Also - key forwarding. Private key is on your local, you can forward it through ssh so you can hop around from your next destination
Post reply on HN