91–100 of 137 posts
Earlier quoted context omitted.
> 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.
And what about the CA?
Life is easier if you can use Kerberos SSO, i.e. GSSAPIAuthentication in OpenSSH. (If we're talking certificates, presumably it is OpenSSH, or does anything else implement them?)
Why would you do that rather than just hooking SSH up to a real IdP with certificates?
You have to manage extra infrastructure for certificates and, as a user, have the friction of firing up a JavaScript-enabled web browser via an additional tool, assuming "real IdP" means using OIDC. Unfortunately that flow is actually needed for remote systems and something like Edugain federation, since Moonshot/IETF ABFAB failed, but at least Shibboleth can use the TGT, and it's not the Globus horror.
Earlier quoted context omitted.
Why would you do that rather than just hooking SSH up to a real IdP with certificates?
I don't want to have to get a special purpose credential when I have a TGT which can work generally, and is at least required for secure remote filesystem access. You have to manage extra infrastructure for certificates and, as a user, have the friction of firing up a JavaScript-enabled web browser via an additional tool, assuming "real IdP" means using OIDC. Unfortunately that flow is actually needed for remote syst…
Setting up Kerberos in 2026 feels somewhat close to malpractice to me.
Earlier quoted context omitted.
Exactly. This is really useful in larger organizations where you may want more complex rules on access. For example, you can easily build "break glass" or 2nd party approved access on demand. You can put whatever logic you need in a CA front-end. You can also make all the certs short-lived (and only store them in ram).
The way I've been doing that is with Shamir Secret Sharing and encrypting keys until glass-breaking is necessary.
What I've done is generate a cert for the host(s) the user needs, for the time-span they need (subject to authorization logic).
Earlier quoted context omitted.
Well, TOFU is really just the model for how the chain of trust is established. In practice there isn’t really trust on first use : there’s verify the key matches what’s expected , or distribute keys out-of-band (including certs). If that verification step isn’t happening, then it’s not TOFU, it’s just blind trust. From an automation/autoscaling angle, the same thing shows up again: 1. either keys are pre-baked / dist…
I agree. I was just wondering if Userify had a solution for distribution the server signatures to the users.
Earlier quoted context omitted.
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.
So I totally agree: if I had to do certificates and didn't have something like Userify, a 1 hour (or even shorter if possible) expiration seems quite worth chasing, especially with suitable highly available configuration. (Of course, TFA doesn't even bother mentioning revocation and expiration, which should give you a clue as to how much fun those are lol)
And for more normal, lower-security requirements or non-HA, 6 or 8 hours or so would probably work and give you plenty of time for even serious system outages before the certs expired.
Not to hard shill or anything (apologies in advance, just skip if you're not interested), but there are two significant security and reliability differences between standard SSH (with or without certificates) and Userify:
1. Userify Cloud updates by default every three minutes, and on-premise Userify Express/Enterprise updates every ten seconds, but it doesn't have to update at all; even if your Userify server goes offline forever, you can still log in because the accounts are standard UNIX accounts (literally created with `useradd`)
2. When accounts are removed, Userify also completely nukes the user account, removes its sudo perms, and totally kill -9 's any tmux/screen/etc sessions (all processes owned by the user are terminated across the entire enterprise within seconds), which is also not something that a certificate expiration would ever do.
Cert revocation (or even expiration)
Sudo roles
User removal and process termination
Is the cert server HA and locked down
How you log in when the cert server is down or under attack (rich target!)
How to easily add Alice to server group A, Bob to B, and Carlos to both A and B, and then to remove them..
The experience might be better right up until you're running it in prod and someone happens to ask about: Cert revocation (or even expiration) Sudo roles User removal and process termination Is the cert server HA and locked down How you log in when the cert server is down or under attack (rich target!) How to easily add Alice to server group A, Bob to B, and Carlos to both A and B, and then to remove them.. (disclaim…
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.
One key technological cause is that PKCS#12 standardizes a format (you've most likely seen it as .PFX files) in which a certificate and its associated private key are bundled. This is in an effort to simplify the software... So you get a situation where the lay person is given a "certificate" but it's not really just the certificate it's a PFX file and so e.g. no they mustn't show it you, it has their private key ins…
The experience might be better right up until you're running it in prod and someone happens to ask about: Cert revocation (or even expiration) Sudo roles User removal and process termination Is the cert server HA and locked down How you log in when the cert server is down or under attack (rich target!) How to easily add Alice to server group A, Bob to B, and Carlos to both A and B, and then to remove them.. (disclaim…