Situation: A person's machine dies and takes the SSH private key with it
No Certs: They now need to get IT to distribute the public keys to a set of hosts, where the full list is possibly not known by any one person, so for the next week it will be "oh shit, I forgot to ask IT to put the pub key on server-12, so I'll open a ticket and not get any work done for the next few hours"
> They now need to get IT to distribute the public keys to a set of hosts, where the full list is possibly not known by any one person
If the team responsible for server security isn't able to identify all the servers they're responsible for, you've got far bigger problems than SSH certificates are going to solve.
You could just get your authorized keys via an `AuthorizedKeysCommand`. It will make it slower to load but even something as simple as `AuthorizedKeysCommand aws s3 cp s3://myprivatebucket/authorized_keys - | grep USER` will do the trick. Then revocation is just deletion from the file and adding is just addition to the file.
"Situation: A person's machine dies and takes the SSH private key with it"
Not sure I buy that, people take backups. No reason why a CA can't loose its private key if we're presuming backups are not being taken, and then everyone is affected.
If the IT team is treating servers like pets, then this is a problem. If they aren't amateurs, then it's not a problem to update the script and push the configuration out to all of the servers.
The second part is only kind of accurate, because usually the "sign a new key" part is automated as part of some other authorization flow. For instance you can log into your corporate SSO provider, and that can actually provision a short-term (i.e. 1 hour) SSH key that is signed by the CA for you. That short-term key is then used to shell into hosts, and you periodically renew either the key or the SSO session token. There's a bunch of points in the design space you can do to make this transparent. Normally it's all wrapped up in some command that invokes ssh for you; so you just say 'corp-auth ssh username@host' instead of just 'ssh username@host' and it all "Just Works" if you're lucky.
You can also bake some basic rules/policies into the certificate, i.e. the above flow returns a signed certificate that is only valid for SSH'ing into hosts in the 'www' group (not the 'database' group.) So then operations people can add you to groups in some other place (LDAP, Exchange, whatever) and when they add you to the 'database' group, any future short-term SSH keys issued by the central authority allow you to now shell into the 'database' hosts. The hosts themselves can also have some automation to check these permissions are accurate when an SSH login request occurs. So you just file an IT ticket asking to shell into a host or group of hosts, they fiddle with some knobs somewhere, and a few minutes later you're done.
So the actual second part is more like "Get a new laptop and log back in through Okta" or whatever, and you have all the exact same permissions and whatnot you did before. It's easier for both the user and the administrators.
An immediate advantage of this are that keys are easy to immediately audit and revoke (because a central authority issues them so you have a trusted trail). But there are some more subtle advantages; one for example is that you make servers more homogenous and identical. They all just ship some specific sshd_config file, normally identical, rather than each server potentially having a different authorized_keys file; instead the central authority that issues keys is where the mapping of hosts/authorized users is, rather than each server having that knowledge "individually" in its own file. That's easier to understand, track, keep up to date (who has access where?) etc. You can just go modify a single global user and have the permissions flow downwards.
None of this really matters if you only have like 1 or 2 people doing everything, or it's your home network, but once you get above like, 5-10 people, or you have at least one sysadmin, it's actually really useful IMO. Also, to some extent, you can mix and match various parts of the above concepts (e.g. running code on every login request, to add extra authorization checks based on out-of-band information.) You have to decide what's appropriate for you. Read the ssh and sshd man pages and you'd be surprised at what you can do.
Source: I basically implemented my own SSH certificate authority infrastructure (server/client automation) "for fun."
I guess I don't see how this is better than using LDAP or AD authentication on each host?
Also, users tend to hate having to always relogin to SSO; maybe that's because the implementations have poor UX, and maybe there's no secure way around it.
Sure, you can use LDAP or AD or any other number of things to control server authentication as well as mapping some global database of user IDs to accounts. You could also do other things like combine this with a 2FA solution like Duo.
One thing SSH certificates certainly have going for them is that they're actually easy to script and integrate with, and "piecewise" migrate to, in my experience, while using a flow you already are pretty familiar with. I personally didn't use any sort of LDAP or AD setup to back my design; you can implement a custom backend for all this pretty easily yourself. There's nothing inherently confusing about the concept of cryptographic certificate authorities or anything, anymore than public key cryptography itself. It's a relatively natural extension of the SSH design you know already, is my point. Again, the man page is worth reading to understand it all a bit better.
> Also, users tend to hate having to always relogin to SSO; maybe that's because the implementations have poor UX, and maybe there's no secure way around it.
Well, I'll be honest, people who tend to use SSH and would be impacted by this stuff tend to hate lots of things and not always for good reasons. Put another way, listening to developers or whatever about what they hate and what's actually good isn't something I would factor into something like this. SSO is mandatory for very good reasons at any reasonable scale (and by "reasonable" my opinion is you should have it in place at, like, 10+ people.)
Anyway, besides that. There's nothing in theory that prevents you from doing something specific like having the backend refresh the SSO token issued for your SSH certificates every time you log into some server, upto some given interval e.g. logging in at least once a day seems reasonable, but if you login every 5 minutes to a new set of hosts you can refresh the token.
In my case the flow was something like 'my-ssh-ca-wrapper ssh user@bar', which would ask you for a token. I would then get this token by visiting a little webpage I wrote, but in theory it could also just launch the browser itself with xdg-open with a direct link. I just use a password manager to fill out those "SSO" credentials. It isn't ideal or fully integrated but in practice it would only take a few seconds and it's similar enough to corporate SSO setups. But yes, polish is everything for those final few steps. The actual backbone is pretty straightforward, though.
Seems more secure than handing over the security of your servers to a CA?
Managing the authenticated_keys file is trivial and I like simple file based solutions.
I find simpler is often more secure because its easier to understand.
I have had plenty of ssh servers on the Internet even, (on non-22 ports to prevent logs filling) and not had a problem yet AFAIK.
I have also been on call when certs expired gawd knows how many times.