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

61–70 of 161 posts

Re: We need better support for SSH host certificates

#61

Post by rhco »

deathanatos wrote: post #25
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…

> we've verified the host key (and not just TOFU'd it!), How . Specifically, what I cannot determine from their docs is how the VM obtains a host key/cert signed by the CA. How does the CA know the VM is who the VM says it is? (I.e., the bootstrap problem.) (I assume that you also need your clients to trust the CA … and that has its own issues, but those are mostly human-space ones, to me. In theory, you can hand a d…

StepCA supports quite a few authentication methods, including an "admin provisioner" (basically a passphrase that can be pasted into the CLI tools' stdin).

Because each of our servers are bespoke, we can use the admin provisioner when the server is first being set up (and actually, Ansible handles this part).

I don't have experience with it, but StepCA also has Kubernetes support, and I imagine the control plane could authenticate the pod when a cert needs to be issued or renewed.

Re: We need better support for SSH host certificates

#62

Post by rhco »

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?

The CA CLI tool we use supports a few auth methods, including a passphrase-like one. It likely could be set up with TOTP or a hardware token also. We only use OAuth because it's convenient and secure-enough for our use case.

Re: We need better support for SSH host certificates

#64

Post by ShroudedNight »

midasuni wrote: post #39
ShroudedNight wrote: post #24

Earlier quoted context omitted.

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.

Right now, probably domain validation. But with the TLS infrastructure, if domain validation ends up in disrepute, or if a CA screws around, we can revoke our trust on a subset without needing to replace the system wholesale.

Re: We need better support for SSH host certificates

#65

Post by michaelt »

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?

In general for systems like this, you can open the browser link from a different host.

For example, if I've SSHed from my laptop to Host A to Host B to Host C then need to authenticate a CLI program I'm running on Host C, the program can show a link in the terminal which I can open on my laptop.

Re: We need better support for SSH host certificates

#66

Post by INTPenis »

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.

This is a good point actually. It's kinda funny how even Microsoft's own GUI IDE uses an underlying ssh protocol with ssh keys that the end user doesn't even need to see or know about.

Now that we're mostly using ssh to push source code, or connect to remote systems, why not just use tls instead? Aside from its general availability, feels like inevitable.

Re: We need better support for SSH host certificates

#70

Post by AtNightWeCode »

megous wrote: post #51
AtNightWeCode wrote: post #41

Another problem with SSH is that people remove the key check completly in automations since some services just rotates the keys without telling. Or for being lazy.

That's also solved with host CA. You can rotate the host keys, add new machines/keys however you want, and all that matters is whether the host keys are signed with a trusted CA, when you setup automation to trust that CA.

Yes, that would work.
Post reply on HN