OKAY, KIDDIES, LESSON TIME
ssh key file authentication is very primitive. it is suitable primarily for individuals with small, decentralized networks. i only use it as a backup and i'm getting ready to remove it entirely from my network. there are a number of alternatives you can and should be using if you're running an actual organization.
the simplest and most obvious is Kerberos. even if you don't use LDAP (if you have more than one or two hosts, you should use LDAP), you can use Kerberos. it gets a bad rep, probably because AD is a dumpsterfire and the MIT Kerberos interface is kind of confusing, but once you get the basics down it's very easy to understand and use. you can create all sorts of versatile setups with just Kerberos alone. if you only need centralized password management and SSO, *not* centralized identity management, use Kerberos. all anyone needs to do to SSH in is run "kinit", type their password, and then they can ssh into any server they're authorized for without typing any more passwords, and the authentication ticket automatically expires after a configurable period of time, so even if it's compromised somehow there's only a short window where it can be used.
if you also need centralized identity management, you should use LDAP. i'm only familiar with OpenLDAP myself, and while it's a bit of a dumpsterfire it does work, and it has some very powerful features i've had to exploit to essentially use it as an interface for authentication frameworks that don't speak Postgres, like NSS. 389 Directory Server is less powerful but from what i hear it's much less unpleasant to work with than OpenLDAP. LDAP is scary at first (the "lightweight" part is a historical inside joke) but even on my own without any help or professional support i've been able to use it to set up very complex and powerful directory systems, and i'm just some random chick. don't let its reputation scare you away from doing things right.
however, if you really need to use SSH keys, there are ALSO ways to do this that are much safer, cleaner, and harder to hack than just keeping text files with lists of allowed keys on every individual host (let alone trying to "centralize" the config with configuration file management software). OpenSSH has a little-known configuration directive called "authorizedkeyscommand" which allows you to get the list of allowed keys and users by running a command instead of reading a file. you can go completely wild here; my plan for COMINTERN is to write a program in PGC to access the central authentication database, read a list of SSH keys bound for each user with shell access, and emit that in a form OpenSSH can understand. this effectively means that with a click of a button on our web interface you'll be able to add or remove users from the system, email, irc, and a number of other services simultaneously AND add as many SSH keys as you want for them, and this will take immediate effect.
of course, since it's just can arbitrary command, you can use any logic you like here. it's great. there's really no reason to be using the authorized keys file if you need centralized auth management. there's especially no reason to be using the authorizedkeys2 file because GOOD GRIEF. you should disable both of those entirely in your sshd_config and use authorizedkeyscommand to query your user database (whether that's LDAP, Postgres, Heimdal, or just a text file on a web server somewhere) instead.
don't do what the Matrix dipshits did.