Exactly. We'd had discussions about building https://Userify.com (plug!) around SSH certificates, but elected to go with keys instead, because Userify delivers most of the good things around certificates without the jank and insecurity.

It's not that certificates themselves are insecure themselves, it's that the workflows (as the parent points out) are awful. We might still add some automation around that (and I think I saw some competitor tooling out there if you're committed to that path) but I personally feel like it's an answer to the wrong question.

> 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?

It's no different compared to regular SSH private keys. You need to protect it from compromise.

However, it provides you an additional layer of protection, because it does not need to be on the critical path for every SSH connection. My CA is a Nitrokey HSM, for example. I issue myself temporary certs that are valid only for 6 hours for ephemeral private keys.

Yes it is different. SSH CA keys are harder to secure and attackers have a much bigger incentive to steal them.

You can also configure multiple CA for client auth, and on the client side multiple ca to verify host keys.