Its not the username that needs to match, its the principal. You can allow any principal for the root user, for example.

You can define principals when allowing a CA via authorized_keys, or you can configure allowed principals globally using sshd_config directives like AuthorizedPrincipals* .

Many years ago, I did all of this with an LDAP system. Public keys were generated by the user and entered into LDAP (or you could auto-generate keys, etc). Users were authenticated with their ssh key (stored in ldap, password based access was restricted). Authorization for access to each host was also in LDAP, as was sudoer status (as a group setting).

It was actually quite an elegant setup. You would still need to setup a CA for generating local certificates for TLS connections to LDAPS, but the auth was handled all in the LDAP server.

I think the main downside would be trying to have the authentication overhead on a single server (the ldap server) when you are dealing with many hosts. Over a handful of systems, it’s great. But it doesn’t scale when you’re taking thousands of hosts (or cloud vms that spin up/down).

In most circumstances, you want these two things (user is authorized on the system, user can be identified and authenticated) to be different. Having a process that creates the user on system in order to authorize them to login is pretty similar to all your other configuration management tasks.

I imagine it's a matter of automating the certificate insertion on the target servers when it's updated on the user's account in the LDAP server. In other words, it depends entirely on your systems and how far your administration is willing to go to automate it.