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

111–120 of 137 posts

Re: SSH certificates: the better SSH experience

#111

Post by laserlight »

tracker1 wrote: post #55
Stefan-H wrote: post #29

Earlier quoted context omitted.

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 "sec…

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

I can see this happening when a developer is authorized to generate, but not to register. So, they just reuse an already-registered one.

Re: SSH certificates: the better SSH experience

#113

Post by elric »

bombcar wrote: post #84
tacostakohashi wrote: post #65

One constant source of amazement for me is people not using ssh keys / using passwords with ssh. Especially at a BigCo, where there are different environments, with different passwords, and password expiry/rotation/complexity rules. Like, when asking for help, or working together... you say to them "ok, lets ssh to devfoo1234", and they do it, and then type in their password, and maybe get it wrong, then need to rese…

Keys is great for individual use, or for company use if you have centralized key control (and issue one or more keys per user). Often you either end up with one "dev ssh key" for all machines (which is bad) or you end up with people sharing around keys and unidentified keys on machines. Passwords at least are "simple" for people to work with.

> Often you either end up with one "dev ssh key" for all machines (which is bad) or you end up with people sharing around keys and unidentified keys on machines

That hasn't been my experience at all. I've never encountered ssh key sharing in any environment, that would be insane.

We enforced different ssh keys per environment at my previous company: fingerprint of your key would get logged, and if the SIEM detected a reuse of keys across environments (dev, test, prod, etc) you'd get a stern talking to.

Re: SSH certificates: the better SSH experience

#114

Post by elric »

longislandguido wrote: post #46

This discussion is full of schizo solutions to "secure" SSH, most of which make no practical sense or have no technical basis. There really needs to be a definitive best practices guide published by a trusted authority.

Can you give some examples of which suggestions you think are schizo?

Re: SSH certificates: the better SSH experience

#115

Post by anilakar »

blueflow wrote: post #52
TZubiri wrote: post #50

Earlier quoted context omitted.

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.

And when your or someone else's infra down to such a degree that you need SSH access, you do not want to depend on being able to touch that machine first. The same is true with custom AuthorizedKeysCommands that phone home.

Re: SSH certificates: the better SSH experience

#116

Post by functional_dev »

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

maybe it keeps getting rediscovered, becaues a good tooling around it is still missing?

Re: SSH certificates: the better SSH experience

#117

Post by adrian_b »

akerl_ wrote: post #73
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…

> When using certificates, a completely identical procedure must be used. After certificates are generated, like also after SSH keys are generated, the certificates must be copied to the client computer and the server computer through secure channels. That is not the case, and is a major advantage of certificates.

What you say is extremely wrong and this misconception is very dangerous.

When an authenticated connection between a client and a server (or any other 2 computers) is established, before the connection can be initiated both ends must already have a piece of information that has been copied to them through a secure channel, otherwise the authentication is impossible.

The 2 pieces of information may allow direct reciprocal authentication, i.e. the client may have the server certificate and the server may have the client certificate.

It is also possible to have indirect authentication, e.g. the server sends the server certificate to the client and the client sends the client certificate to the server during the initiation of the connection.

However, for indirect authentication, both the client and the server must had been previously paired with a server hosting the certification authority.

This means that the root certificate of the CA must have been transferred through secure channels to the client and to the server, and also that the client certificate and the server certificate must have been transferred through secure channels to the CA for signing and then back to the client and the server.

So setting up the computers for indirect authentication through certificates requires significantly more transfers through secure channels than setting them up for direct authentication.

The advantage of indirect authentication appears in an organization with a great number of computers, where indirect authentication reduces the number of secure pairings that must be done from N*(N-1)/2 to N.

However this has nothing to do with certificates. Indirect authentication can be done without certificates, like in Kerberos, or like in SSH if you have a management computer that you pair by copying the public_keys with every computer in the network. Later, whenever you want to enable some client to connect to a SSH server you use the management computer to copy securely the corresponding public_keys between the server and the client.

So no, there is no advantage of certificates related to reducing the number of transfers that must be done through secure side channels, like copying through a portable memory.

Certificates provide other features, like temporary validity and revocation, which can be useful in an enterprise context.

Re: SSH certificates: the better SSH experience

#118

Post by akerl_ »

adrian_b wrote: post #117
akerl_ wrote: post #73

Earlier quoted context omitted.

> When using certificates, a completely identical procedure must be used. After certificates are generated, like also after SSH keys are generated, the certificates must be copied to the client computer and the server computer through secure channels. That is not the case, and is a major advantage of certificates.

What you say is extremely wrong and this misconception is very dangerous. When an authenticated connection between a client and a server (or any other 2 computers) is established, before the connection can be initiated both ends must already have a piece of information that has been copied to them through a secure channel, otherwise the authentication is impossible. The 2 pieces of information may allow direct recipr…

What misconception? You essentially admit that I'm right in this comment but surround it with a bunch of other unrelated words.

If you use SSH certificates, then you have to put the SSH CA cert on each server once, and you have to give signed certs back to each client once each time you sign a cert (which can be once per client or once per connection or anywhere in between).

You do not have to copy anything new to each server when you sign new client certs. Likewise if you sign host keys, you don't have to copy a new host key to your client when you add a new server.

Sure, you could get the same kind of trust relationships with other tools. But SSH certificates provide them and are an advantage of SSH certificates over traditional SSH public key auth.

It honestly feels like you're just dropping this thread into an LLM and asking it to write a disagreeing response.

Re: SSH certificates: the better SSH experience

#119

Post by gnufx »

floating-io wrote: post #106
gnufx wrote: post #67

Earlier quoted context omitted.

If you mean using OIDC, in that space there's at least https://github.com/EOSC-synergy/ssh-oidc , https://dianagudu.github.io/mccli/ and OpenPubkey-ssh discussed in https://news.ycombinator.com/item?id=43470906 (which might mention more). How does SSSD support help with SSH authN? I know you can now get Kerberos tickets from FreeIPA using OIDC(?), but I forget if SSSD is involved.

Can't really speak to the point of the guy you're replying to, but the FreeIPA implementation via SSSD does more than just Kerberos tickets. Actually, I think the Kerberos based stuff as it relates to SSH is GSSAPI as part of sshd itself and has little to do with sssd, though I could be wrong. That said... If I'm remembering things correctly (and it's been a looong while since I've played with this), FreeIPA's client…

Yes, FreeIPA is Kerberos+LDAP+X.509 CA, and GSSAPI is in OpenSSH (normally with the key exchange patch). SSSD is a local mechanism, not network authentication. I mentioned authorized keys distribution mechanisms elsewhere, but I was thinking authentication (c.f. OIDC), not authorization.

Re: SSH certificates: the better SSH experience

#120

Post by akerl_ »

Terr_ wrote: post #103
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…

> secure channel, e.g. either by using a USB memory Aside: We need a "safely dumb" storage plug standard. Right now the flexibility of USB is a double-edged sword, any USB device could potentially be malicious, waiting for the right moment to send keystrokes as a keyboard etc. Or use the same plug for everything, but support a "passive storage only" that can be enforced by a special adapter or cable.

Assuming you’re not just soliciting random thumb drives from strangers… this doesn’t feel like an actual risk.

When you’re getting things from strangers, use any of the myriad ways to send files over a network, where HTTP / your browser are the safe dumb plug.

Post reply on HN