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

131–140 of 161 posts

Re: We need better support for SSH host certificates

#131

Post by shrx »

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` ?

What if you're ssh-ing from a headless client, like a raspberry pi or a VPS?

Re: We need better support for SSH host certificates

#132

Post by bawolff »

gaadd33 wrote: post #59
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...

MX records don't fit into the "only for name resolution" mantra either but no one has advocated that we stop using those have they? That also ignores all of the other record types that aren't just for name resolution too.

Including DKIM which is literally keys in DNS and widely used.

Re: We need better support for SSH host certificates

#133

Post by bawolff »

mbreese wrote: post #130
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.

> You don't want to save the fingerprint in a stale, insecure database like that. I'm trying to figure out how having a stale fingerprint would be an automatic bad thing. Let's assume you have a server with a fingerprint stored in DNS. Something happens and the server's certificate/key needs to change. So now you push out a new key fingerprint to DNS. The failure mode for an out-of-date fingerprint would be to not tr…

I think cache poinsioning is what the person was trying to get at.

But its kind of a strawman because nobody is suggesting putting unauthenticated keys in dns with no dnssec. The suggestion is either using dnssec, or have some sort of CA system.

Re: We need better support for SSH host certificates

#134

Post by mbreese »

mattpallissard wrote: post #121

, I really wish that the kerberos/gssapi folks had packaged everything up nicely for the web people to use. Between keytabs, derived credentials, and cross realm trust it really did solve nearly every authentication situation that people have. I pine for a world in which we had made it more approachable for the people who just wanted to quickly build an application without learning about the underlying infrastructure…

I've been thinking the same thing... all of this has been done before, and will be done again. With LDAP and Kerberos, many of these workflows were possible decades ago. But having servers connected to a centralized auth infrastructure wasn't popular (probably due to automated setups). And if you wanted TLS, you might even be working with an in-house CA with LDAPS (that's how I did it).

Now we're swinging back to recognizing the benefits to some level of centralization in authentication.

From a historical point of view, this all seems very familiar.

Re: We need better support for SSH host certificates

#135

Post by Valien »

Can also use tools like Teleport that handles all of this programatically. Open-Source core as well (github.com/gravitational/teleport).

Source: I work for Teleport so a little biased, but love the fact that more and more orgs are going away from static creds/keys and using short-lived certs and/or passwordless solutions. Spent many years in a production role and wish I had these tools (or was aware of these tools) back then.

Re: We need better support for SSH host certificates

#136

Post by fisian »

philo23 wrote: post #125
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…

This is a bit off topic, but does anyone know how the mechanism that triggers the web page prompt from an ssh connection actually works? Is it some kind of alternate ssh authentication method (like password/publickey) or something entirely out-of-band coming directly from the VPN app intercepting the connection? Ever since I saw it in action with Tailscale I've always wondered how it actually works, and I guess if an…

Smallstep uses ProxyCommand [0]. Not sure how Tailscale does it.

0: https://smallstep.com/docs/ssh/how-it-works

Re: We need better support for SSH host certificates

#137

Post by JohnFen »

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…

Requiring the use of a browser, though, limits the usefulness a bit.

Re: We need better support for SSH host certificates

#138

Post by v7n »

philo23 wrote: post #125
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…

This is a bit off topic, but does anyone know how the mechanism that triggers the web page prompt from an ssh connection actually works? Is it some kind of alternate ssh authentication method (like password/publickey) or something entirely out-of-band coming directly from the VPN app intercepting the connection? Ever since I saw it in action with Tailscale I've always wondered how it actually works, and I guess if an…

OOB: ".. during the SSH protocol’s authentication phase, the Tailscale SSH server already knows who the remote party is and takes over, not requiring the SSH client to provide further proof (using the SSH authentication type none)." https://tailscale.com/kb/1193/tailscale-ssh/#how-does-it-wor...

Re: We need better support for SSH host certificates

#139

Post by gnufx »

mattpallissard wrote: post #121

, I really wish that the kerberos/gssapi folks had packaged everything up nicely for the web people to use. Between keytabs, derived credentials, and cross realm trust it really did solve nearly every authentication situation that people have. I pine for a world in which we had made it more approachable for the people who just wanted to quickly build an application without learning about the underlying infrastructure…

Definitely , particularly as Kerberos provides general single sign-on, rather than the uniform sign-on (just the same credentials for different services) that's typically labelled "SSO". SSH GSSAPI seems pretty simple, assuming you can populate the keytab. Is Kerberos setup really worse than alternatives for Apache (all I know)? However, the SPNEGO mechanism itself is cocked up in some way I've forgotten. One problem is people not wanting to expose the KDC to the WAN -- specifically Active Directory, as I recall Microsoft says. MIT have been doing that for ever and, for instance, Fedora uses FreeIPA over https.

Re: We need better support for SSH host certificates

#140

Post by gnufx »

mbreese wrote: post #134
mattpallissard wrote: post #121

, I really wish that the kerberos/gssapi folks had packaged everything up nicely for the web people to use. Between keytabs, derived credentials, and cross realm trust it really did solve nearly every authentication situation that people have. I pine for a world in which we had made it more approachable for the people who just wanted to quickly build an application without learning about the underlying infrastructure…

I've been thinking the same thing... all of this has been done before, and will be done again. With LDAP and Kerberos, many of these workflows were possible decades ago. But having servers connected to a centralized auth infrastructure wasn't popular (probably due to automated setups). And if you wanted TLS, you might even be working with an in-house CA with LDAPS (that's how I did it). Now we're swinging back to rec…

"I've long ago made up a corollary to Greenspun's tenth rule; any sufficiently complex or mature access regime will re-implement half of kerberos, poorly." -- cduzz, https://news.ycombinator.com/item?id=30798057
Post reply on HN