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

91–100 of 161 posts

Re: We need better support for SSH host certificates

#91

Post by sokoloff »

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…

You give your public key (typically into ~/.ssh/authorized_keys) and then prove you have access to the matching private key as the essential part of the challenge. You always keep the private key.

Re: We need better support for SSH host certificates

#92

Post by [deleted] »

ShroudedNight wrote: post #64
midasuni wrote: post #39

Earlier quoted context omitted.

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.

[deleted]

Re: We need better support for SSH host certificates

#93

Post by Macha »

0xedd wrote: post #50
hamburglar wrote: post #37

Earlier quoted context omitted.

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.

because both of you narrow visioned the scenario to what you do daily. it is a common use case to ssh from a jump server, use ssh based CLI tools and debugging. the issue stems from windows users who are coupled to GUIs. the behavior pattern increases IT and DevOps costs unnecessarily. an alternative example: our org solves the issue with TOTP, required every 8 hours for any operation; from ssh/git CLI based actions…

The -J parameter to say will transparently use a jump server and doesn't require the ssh key being on the third party server. I can't speak for tooling on step-ca but my employers in house tooling works similarly and loads the short lived signed cert into your ssh-agent so once you do the initial auth you can do whatever SSH things.

Re: We need better support for SSH host certificates

#94

Post by fellerts »

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?

I suppose this could be solved by using the first server as an SSH jump host -- see SSH(1) for the -J flag. Useful e.g. when the target server requires public key authentication and you don't want to copy the key to the jump host. Not sure it would work in this scenario though.

Re: We need better support for SSH host certificates

#95

Post by jwilk »

mjg59 wrote: post #42
bawolff wrote: post #33

Earlier quoted context omitted.

The usual counter-argument for https, is that the eggs are already in that basket since anyone with control of dns can just get a new certificate. For ssh that doesn't really apply as clearly though.

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.

> or to compromise DNS in multiple independent locations to serve consistent false answers to the probes

Do all CAs implement multi-prespective validation these days? Let's Encrypt implemented that only in 2020 and they believed they were the first ones:

https://letsencrypt.org/2020/02/19/multi-perspective-validat...

Re: We need better support for SSH host certificates

#96

Post by matja »

j16sdiz wrote: post #49
9dev wrote: post #34

Earlier quoted context omitted.

I don’t believe in the forbidden fruit ideology. If it’s stupid and works well, it isn’t stupid. People have been using DNS for all kinds of configuration for decades now, with great success. So what, other than a pedantic and grumpy programmer’s perspective, should keep us from using DNS for configuration records?

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.

Re: We need better support for SSH host certificates

#97

Post by lbriner »

I think the comments just make another proof that the OP assertion was correct and also that we live in a Wild West industry. One day, I hope there will be a much more standardised way of doing things properly, perhaps caveated with "more secure + more work" vs "Simple and OK secure".

At the moment, there are too many strong opinions about 100 different "best" ways to do things leaving most of the rest of us just using whatever is easiest to find on Google rather than what the industry has discussed and approved.

Re: We need better support for SSH host certificates

#98

Post by gpderetta »

michaelt wrote: post #65
gpderetta wrote: post #46

Earlier quoted context omitted.

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.

Having to interact with the browser every time I need to ssh to a machine would be extremely painful.

If key forwarding works, that might be workable.

I'm extremely wary of non-standard ssh login processes as they tend to break basic scripting and tooling.

Re: We need better support for SSH host certificates

#99

Post by counttheforks »

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…

How do you get the browser to open? Does it work on all operating systems and ssh clients, such as Android's JuiceSSH?

Re: We need better support for SSH host certificates

#100

Post by Reitet00 »

fmajid wrote: post #76
OrvalWintermute wrote: post #12

Earlier quoted context omitted.

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.

Yeah. Actually ssh agent speaks PKCS#11 (both client and server) so it's possible to interface with the hardware token quite easily. I'm using that to store my client key in TPM for example.
Post reply on HN