Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH certificates: the better SSH experience

jpmens.net

Post reply on HN
Print view View original

51–60 of 137 posts

Re: SSH certificates: the better SSH experience

#51

Post by TZubiri »

anyfoo wrote: post #22
kaoD wrote: post #3

Earlier quoted context omitted.

I've known SSH certs for a while but never went through the effort of migrating away from keys. I'm very frustrated about manually managing my SSH keys across my different servers and devices though. I assume you gathered a lot of thoughts over these 15 years. Should I invest in making the switch?

A big problem I have with ssh carts is that they are not universally supported. For me, there is always some device or daemon (for example tinyssh in the initramfs of my gaming pc so that I can unlock it remotely) that only works with “plain old ssh keys”. And if I have to distribute and sync my keys onto a few hosts anyway, it takes away the benefits.

Might actually be a positive instead of a negative. Gaming use-cases should have not any effect on security policies, these should be as separate as possible, different auth mechanisms for your gaming stuff and your professional stuff ensures nothing gets mixed.

Re: SSH certificates: the better SSH experience

#52

Post by blueflow »

TZubiri wrote: post #50
papyDoctor wrote: post #11

Earlier quoted context omitted.

Another useful feature of SSH certificates is that you can sign a user’s public key to grant them access to a remote machine for a limited time and as a specific remote user.

The capacity to grant access as a specific remote user is present without certs as well right? The typical authorized_keys file lives under a user directory and grants access only to that user.

The main advantage of certificates is that you are able to do that from the CA without touching the target machine.

Re: SSH certificates: the better SSH experience

#53

Post by adrian_b »

palata wrote: post #34
adrian_b wrote: post #19

Earlier quoted context omitted.

Certificates provide extra features, like revocation. However, if you do not need the extra features provided by certificates, using SSH-generated keys is strictly equivalent with using certificates and it requires less work. TOFU is neither necessary nor recommended, it is just a convenience feature, to be used when security may be lax. The secure way to use SSH is to never use TOFU but to pair the user and the serv…

> TOFU is neither necessary nor recommended Just to make it clear: this does not mean that it is fine to blindly accept the message on first use. The "secure way" implies copying the server's public key as well, which people generally don't do, right? Which is equivalent to verifying the fingerprint shown with the TOFU message, correct?

Like I have said the secure way requires the secure copying of both keys before the first connection attempt

The server public key must be copied into "known_hosts" on the client, while the client public key must be copied into "authorized_keys" on the server.

When this is the procedure that is always followed, any message shown by SSH about an unknown host means that the connection must be aborted, because the identity of the server is unknown.

You cannot truly verify the "fingerprint" displayed by SSH, unless you simultaneously have access to another computer, where you have a copy of the fingerprint. What is usually meant by "verifying" is that you remember a few digits of the fingerprint, and those match.

You could have copied the fingerprint from the server, to be able to truly verify it, but that does not make sense, because in that case you should have copied the entire key, not just the fingerprint, and you should have installed it in the client.

When you use only authentication with digital signatures, it does not make sense to use any other procedure, because you must make at least one of the two copies anyway, so when copying the client key to the server you can take the server key, to carry it back to the client.

The TOFU method is meant to be used together with password-based authentication, in less secure applications, where no physical access to the server is required for setting up SSH on the client.

By "less secure" I mean for example applications equivalent to HTTPS, where the client is not really authenticated, e.g. when providing a public password allowing read-only access to an SSH server through Internet.

Re: SSH certificates: the better SSH experience

#54

Post by cyberax »

otabdeveloper4 wrote: post #16
kaoD wrote: post #3

Earlier quoted context omitted.

I've known SSH certs for a while but never went through the effort of migrating away from keys. I'm very frustrated about manually managing my SSH keys across my different servers and devices though. I assume you gathered a lot of thoughts over these 15 years. Should I invest in making the switch?

You will have to manage your SSH CA certificates instead of your keys. The workflows SSH CA's are extremely janky and insecure. With some creative use of `AuthorizedKeysCommand` you can make SSH key rotation painless and secure. With SSH certificates you have to go back to the "keys to the kingdom" antipattern and just hope for the best.

> With SSH certificates you have to go back to the "keys to the kingdom" antipattern and just hope for the best.

Whut? This is literally the opposite.

With CA certs you can create short-lived certificates, so you can easily grant access to a system for a short time.

Re: SSH certificates: the better SSH experience

#55

Post by tracker1 »

Stefan-H wrote: post #29
thomashabets2 wrote: post #2

Every couple of months someone re-discovers SSH certificates, and blogs about them. I'm guilty of it too. My blog post from 15 years ago is nowhere near as good as OP's post, but if I though me of 15 years ago lived up to my standards of today, I'd be really disappointed: https://blog.habets.se/2011/07/OpenSSH-certificates.html

I think the scary reality is most people conflate "keys" and "certificates". I have worked with security engineers that I need to remind that we do not use SSH certs, but rather key auth, and they have to think it through to make it click.

I'm consistently amazed how many developers and security professionals don't have a clear understanding how PPK even works conceptually.

Things like deploying dev keys to various production environments, instead of generating/registering them within said environment.

One of the worst recent security examples... You can't get this data over HTTPS from $OtherAgency, it's "not secure" ... then their suggestion is a "secure" read-only account to the other agency's SQL server (which uses the same TLS 1.3 as HTTPS). This is from person in charge of digital security for a government org.

Re: SSH certificates: the better SSH experience

#56

Post by cyberax »

kaoD wrote: post #3
thomashabets2 wrote: post #2

Every couple of months someone re-discovers SSH certificates, and blogs about them. I'm guilty of it too. My blog post from 15 years ago is nowhere near as good as OP's post, but if I though me of 15 years ago lived up to my standards of today, I'd be really disappointed: https://blog.habets.se/2011/07/OpenSSH-certificates.html

I've known SSH certs for a while but never went through the effort of migrating away from keys. I'm very frustrated about manually managing my SSH keys across my different servers and devices though. I assume you gathered a lot of thoughts over these 15 years. Should I invest in making the switch?

It depends on what you want to do. CA certs are easy to manage, you just put the CA key instead of the SSH public key in authorized_keys.

They also provide a way to get hardware-backed security without messing with SSH agent forwarding and crappy USB security devices. You can use an HSM to issue a temporary certificate for your (possibly temporary) public key and use it as normal. The certificate can be valid for just 1 hour, enough to not worry about it leaking.

Re: SSH certificates: the better SSH experience

#57

Post by toast0 »

moviuro wrote: post #43
blipvert wrote: post #33

Earlier quoted context omitted.

Hmm. For user certs you can have the service sign them for, say an hour, so long as you can ssh to your server in that time then there’s no need for any other interaction. Sure you need your signing service to be reasonably available, but that’s easily accomplished. Maybe I misunderstand?

That sounds like a lot of extra steps. How do I validate the authenticity of a signing request? Should my signing machine be able to challenge the requester? (This means that the CA key is on a machine with network access!!) Replacing the distribution of a revocation list with short-lived certificates just creates other problems that are not easier to solve. (Also, 1h is bonkers, even letsencrypt doesn't do it)

1h is bonkers for certs in https, but it's not unreasonable for authorized user certs, if your issuance path is available enough.

IMHO, if you're pushing revocation lists at low latency, you could also push authorized keys updates at low latency.

Re: SSH certificates: the better SSH experience

#58

Post by aquafox »

I work in a corporate setting and the money and time we wasted because of Zscaler and its SSL inspection [1] is beyond your wildest imagination. Whenever I see a "SSL certificate problem: self-signed certificate in certificate chain" error, I know I'm in trouble.

[1] https://www.zscaler.com/resources/security-terms-glossary/wh...

Re: SSH certificates: the better SSH experience

#59

Post by agwa »

bobo56539 wrote: post #20

With the recent wave of npm hacks stealing private keys, I wanted to limit key's lifetimes. I've set up a couple of yubikeys as SSH CAs on hosts I manage. I use them to create short lived certs (say 24h) at the start of the day. This way i only have to enter the yubikey pin once a day. I could not find an easy way to limit maximum certificate lifetime in openssh, except for using the AuthorizedPrincipalCommand, which…

Instead of using a CA, why not set the key's PIN policy to "once" and use an agent (e.g. https://github.com/FiloSottile/yubikey-agent/) that holds an active session to the yubikey? You start the agent at the beginning of the day, enter the PIN once, and then stop the agent at the end of the day.

Re: SSH certificates: the better SSH experience

#60

Post by yason »

Despite the drawbacks of its grassroot nature TOFU goes a looooong way.

With my own machines I can just physically check that the server host key matches what the ssh client sees. Once TOFU looks good I'm all set with that host because I don't change any of the keys ever.

In a no-frills corporate unix environment it's enough to have a list of the internal servers' public keys listed on an internal website, accessible via SSL so it's effectively signed by a known corporate identity. You only need to check this list once to validate carrying out TOFU after which you can trust future connections.

In settings with huge fleet of machines or in a very dynamic environment where new machines are rolled out all the time it probably makes things easier to use certificates. Of course, certificates come with some extra work and some extra features so the amount of benefit depend on the case. But at this scale TOFU is breaking down bad on multiple levels so you can't afford a strong opinion against certificates, really.

I wish web browsers could remember server TLS host keys easily too and at least notify me whenever they change even if they'd still accept the new keys via ~trusted CAs.

Post reply on HN