Centralized management system for SSH keys?
Solution 1:
Key pairs should be generated by the user.
The user retains the private half - you should never see it. If you have someone's private key in a form where you can read/use it you're doing security wrong.
The public half is given to you (by whatever mechanism you'd like: Web form, email, give-it-to-me-on-a-CD), to be centralized however you want. Some places store the public keys in LDAP. Others push out authorized_keys files using their deployment system.
In my environment users who need shell access give me their public keys. These keys are added to our LDAP system, and sshd consults the public key(s) listed for each user to authenticate them, by way of the LDAP Public Key patch.
When someone needs to add an additional key or revoke an existing key they let an admin know, and we take care of it. Eventually as we scale I will implement a system that lets people rotate their own public keys.
Each of our sites has a pair of LDAP servers, synchronized to our master with LDAP replication, which keeps the data consistent (and accessible) at each location.
Everything I have described can be done with open-source software. There are also commercial products that do the same thing.
You need to research the available options more thoroughly and decide which one(s) suit your environment best. If you have further (more specific) questions we can probably be more helpful.
Solution 2:
Keypairs ought not be generated anywhere but on each user's computer. Private keys are named as such for a reason.
That said, I could see a use case for some sort of centralized repository of users' public keys. One option would be to store public keys in OpenLDAP - recent versions of OpenSSH can read keys out of LDAP.
Solution 3:
There are plenty of ways of doing this. LDAP key storage has been mentioned a couple of times, and I've done that and it works, as far as it does. LDAP has it's own management curiosities, though, which take some learninating.
I'm a big fan of simple, robust servers that have minimal external network dependencies for simple things like authenticating administrators, so I lean towards a far more robust SSH key distribution strategy -- I have the configuration management system take care of it. Everyone's public key is kept in the configuration management system, and wherever the person needs to be able to login, their key is added. The config system also knows to remove keys that aren't specified, so when someone leaves or their key changes, it's a simple matter of removing the key configuration and on the next config system run, the key is removed.
Solution 4:
There's a lot of great commercial and open source solutions, such as Userify[1] (where I work), Universal Key Manager[2], SSH Key Box[3], etc. It depends on what your needs are and if you are looking for something that centralizes management while decentralizing operation (so that your servers don't rely on a central authority to log in... in that case, you might not be able to log into any of your servers, if, say, your LDAP server is down!)
https://userify.com
https://www.ssh.com/products/universal-ssh-key-manager/
https://www.sshkeybox.com
See also this Slant discussion:
https://www.slant.co/topics/8010/~managers-for-ssh-keys