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.