As already mentioned by pulegium, any generic configuration management software like Puppet, Chef, Bcfg2 or cfengine could accomplish the task.
Since the authorized_keys file is not that complicated, you could also use rsync or a (D)SCM like git or hg to manage this file. You have the "master" file on one of your servers and serve it via rsync/git/hg/…. On every other server you run a cron job which periodically retrieves the master copy (if it was changed) and copies it to the correct local location. Heck, this would even work with pure HTTP or FTP.
The bottom line is: Have one "master" copy of your authorized_keys file and update it. Let the "clients" (the computers, which should have the current authorized_keys file) fetch it from your master server and deploy it locally.
You can have as many keys as you desire. It's good practice to use separate private/public key sets for different realms anyway, like one set for your personal use, one for your work, etc.
First, generate two separate keypairs, one for home and one for work:
ssh-keygen -t rsa -f ~/.ssh/id_rsa.home
ssh-keygen -t rsa -f ~/.ssh/id_rsa.work
Next, add an entry to your ~/.ssh/config file to pick the key to use based on the server you connect to:
Host home
Hostname home.example.com
IdentityFile ~/.ssh/id_rsa.home
User <your home acct>
Host work
Hostname work.example.com
IdentityFile ~/.ssh/id_rsa.work
User <your work acct>
Next, append the contents of your id_rsa.work.pub into ~/.ssh/authorized_keys on the work machine, and do the same for the home key on your home machine.
Then when you connect to the home server you use one of the keys, and the work server you use another.
Note you probably want to add both keys to your ssh-agent so you don't have to type your passphrase all the time.
Best Answer
I found this question when trying to answer it myself. After some searching and experimentation, I've found a few other options for this. I'm going to skip the part about distributing keys as an alternative since Matt Simmons covered that. Also, I know there are times when that is not good enough. For example, if you are GitHub and have to store millions of public keys against a single user, continuously updating SSH authorized_keys files and keeping them synchronized across potentially dozens to hundreds of edge boxes is not feasible or desirable.
So,
First of all, RedHat (and variants) have a supported patch for OpenSSH that adds the
AuthorizedKeysCommandandAuthorizedKeysCommandRunAsoptions. The patch has been merged upstream in openssh 6.2. To quote from the man page:In my experiments tonight, I found that out of the box, this doesn't work due to default SELinux policies. You can get around this by turning off SELinux enforcement with
setenforce 0. Since turning of SELinux is probably a bad idea, instead you can generate the correct policy. In my case, that was as simple as attempting to log in with theAuthorizedKeysCommandoption set up in/etc/ssh/sshd_configand then usingaudit2allow -a -M local && semodule -i local.pp. This basically looks through the audit logs and finds things that were prevented and generates exceptions for them. If you are likely to have other stuff in there that might get whitelisted, you should probably learn more aboutaudit2allowto make sure you get the new policies just right.There are other various (probably less tested and trusted) patches out there to add similar functionality. For example there is, openssh-script-auth. You can also find the patch that RedHat used and apply that directly. A quick bout of Googling uncovers https://launchpadlibrarian.net/89063205/openssh-5.3p1-authorized-keys-command.patch and https://launchpadlibrarian.net/105938151/openssh-authorized-keys-command.patch which are based on the RH versions but which have been updated for newer versions of OpenSSH.
Patch OpenSSH to perform key lookups directly from some store (e.g. like GitHub and CodeBaseHQ and others have done). GitHub has not open sourced this patch, to the best of my knowledge, but I know in the past I've come across versions for MySQL and PostgreSQL key lookup. I tried to find them again just now but have not had much luck.
There are also some FUSE-based options. For example there is LPKFuse which lets you serve public keys from LDAP by changing the
AuthorizedKeysFilelocation to one on the LPKFuse filesystem. The LPKFuse FS creates virtual files whose content are backed by fields from a directory server.All in all, I think option #1 is by far the best as it is officially supported by RedHat. Furthermore, it lets you put any logic you like in that script (including talking to a database) in any language you want.