People talk too much about "certificates" as a good thing, but they're just a means to an end. The two major goals you're trying to solve with SSH:

(1) You want all of your authentication to route through a single point of control where you can enforce group-based access control, MFA, onboarding/offboarding, and audit logging.

(2) You want the actual secrets that allow you access to an SSH server not to live for a long time on anyone's laptop, because it is effectively impossible to ensure that, on a sufficiently large engineering team, nobody's laptop will ever get compromised; there's just too many of them, and developers do weird shit so the machines can't be ruthlessly locked down. You want people to have SSH login secrets for exactly as long as they need them for a specific server, and no longer.

Certificates solve the problem of having dynamic access control to SSH servers without having some weird system that is constantly replacing authorized_keys on all your servers; instead, there's a single root of trust on all the SSH servers (the CA public key) and a single place that mints valid certificates that enforces all the stuff I mentioned in (1) above.

It's worth knowing here that SSH certificates are nothing like X.509 certs; they're far simpler, and you could bang out an implementation of them yourself in a couple hours if you wanted.

Using certificates does not provide anything useful for a small private network, with a single administrator, or where all the users are trusted.

On the other hand, they are useful for large organizations, with needs for differentiated access rights and management rights.

The centralized control over the certification authority allows the delegation of restricted rights to other levels of network administration.

A certificate is just a formatted list of attributes that has been signed by a particular private key. Username, UID, GID, membership in this, privilege for that, good-after date and good-until date, for instance.

Everybody knows the public key associated with that private key, so you can verify that the private key did sign this list of attributes.

An ssh keypair is an actual public/private keypair, but a certificate is just signed and encoded (but not encrypted) formatted data.

If an ssh daemon has knowledge of a public key used to sign a cert, and has been instructed to trust that cert, and all the dates are good, then the ssh daemon can accept that cert as proof of identity and allow a login.

I understand what you mean, thanks for the explanation.

But why would you want to do that? What problem does it solve? Just that you can connect without having a private key yourself? This doesn't sound very safe.

You still need your own private key plus the certificate.

I have n clients, m servers.

On clients, i sign the lokal keypair with the CA key and log-in via certificate. The client-side certificate basically replaces the line in the server-side authorized_keys. The editing stays locally.

On servers, i register the CA key as "Certificates signed by this keypair are trustable", the authorized_keys file stays empty. No further editing required.

During normal daywork, the CA key sits unused and can be shut away.

Key Advantage: I don't need to edit anything on the countless servers anymore.

Because the keys aren't directly coupled to server configurations, but rather indirected through a CA which hosts the only durable key, those "private keys" users have to have can be extremely short-lived, and tailored for each individual access request.

I think people really get into trouble with SSH certificates trying to reason about the properties of certificates versus SSH keys versus passwords. The format isn't the point; making the endpoint keys dynamic is. If you built a secure messaging system that propagated one-time-use SSH keys, it would address the same problem. Nobody will, because certificates are easier and already work, but you could.

The common way of managing ssh keys involves having some central entity that somehow updates the authorized_keys on all relevant hosts, which involves interaction with all the hosts which is somehow triggered by interaction with the user requesting access. With ssh certificates the central trusted node only interacts with the user (by signing the certificate) and does not have to update anything anywhere else.

It solves partly managing authorized_keys files. If you have a team separate keys can be difficult to manage. Shared keys are even worse. Certs can help with this if you properly manage the cert signing server (like hashicorp vault). All of that is currently free and open source. Also can now have short expiry times if desired.

One example also mentioned in the article:

If you connect to a ssh-server for the first time, ssh will give you a warning and let you know that you have to verify the fingerprint of the host key.

This becomes annoying when you connect to many different servers and I would not trust everyone (including me) to do this check correctly every single time.

SSH certificates solve this by having the ssh-host-key be signed in a way that your ssh-client can verify and you only have to add a key-signing-key to you known_hosts once.

Now you have to sign the ssh-host-key but you only have to do it once per server as opposed to having each user having to do it locally on every first connect.

I really like: https://www.abc.net.au/news/2017-09-15/how-encryption-works-...

This is a (quite convoluted) explanation of public key cryptography, that I already understand. My question was about certificates.

For public key cryptography my go to analogy for non-technical people has always been the mailing padlocks example (where the padlock is the public key, and the key to unlock itbis the private key that stays with the sender).