Poll HN: Do you use SSH certificates (not mere public-key authentication)?

We use an AWS KMS asymmetric key for the CA keys, they're cheap and avoids exposing the private key material in an any way.

For signing SSH certificates, we run a small service (prototype code dump at https://github.com/pardot/sshsigner) that uses this key to sign short lived certificates. Auth to the service is via OIDC issued ID tokens.

On the client side we have a custom SSH agent that uses an ephemeral in-memory private key. The agent manages the OIDC web flow and calling out to the service for signing on demand. This lets us keep the cert duration small and scoped, and allows us to force re-auth for sudo etc. via the web flow.

We also do a similar thing for host keys, IAM auth the instances and sign certificates.

Altogether works well, provides a nice user experience, and keeps long-lived/leakable creds out of out environment.

@jeroenhd Mea-culpa, had a choice of two smallstep bookmarks and I copy/pasted the wrong one ! Now corrected.

We looked into them once at work for our "conventional" SSH infrastructure, but immediately rammed into the wall that a certificate can sign a key, but you can't have a full PKI infrastructure like SSL where certs can sign certs that can sign keys. Without the ability to delegate, the logistics of needing to create an absolutely centralized authority to do the useful things we wanted to do within the organization raised the cost of "first value" too high for us to fuss over. So for large-ish organizations (~1000 affected employees) we had a hard time justifying any effort put into it versus the established infrastructures for key management that already exist.

On the other side, as a personal user of SSH with basically one person to worry about, the effort of setting up a certificate seems like just a waste versus the existing key-based infrastructure; I don't understand at all what attack it would prevent or what convenience it would provide for the cost of learning it.

A general principle is you get good at what you do a lot, and you aren't good at what you do rarely. Key-based management has its issues, but people have been doing it for a while and they're good at it. Not necessarily "great" and not necessarily "unable to be improved", but they're good at it. People understand it and know how to use it. Nobody uses certificates, so nobody understands how they work or what to do with them, and they have the weakness I cited above. So, even though in a perfect world certificates may be superior, in the world we live in now, the competition between the existing polished infrastructure for pure key-based management is pretty good, even if you think it's a polished turd, and the infrastructure for SSH certs is pretty bad, even if you think it's an uncut diamond in the rough. It's difficult to look at that situation and honestly choose to proceed with the certificates.

As others point out, the cloud services are proceeding in other directions as well which will probably continue to make using SSH certificates directly a very difficult choice to practically justify.

I recently got SmartCard HSM (also available as Nitrokey HSM 1 and 2 I think), but didn't get around to setting it up yet. For personal use it does seem like an overkill, when FIDO2 security keys are much more convenient.

I store my authorized_keys in DNS TXT records, that are DNSSEC signed, with a validating resolver on the box. I then just use "/usr/bin/hesinfo %u ssh" as my AuthorizedKeysCommand in OpenSSH.

I wrote a little tool that allowed you to "#include" other DNS records etc, but "hesinfo" is generally easily installable/available so it's just easier.