Is a central location for authorized_keys a good idea?

I'm in the process of configuring a cloud server to run the following stack: Ruby, Passenger, Apache; under Ubuntu 10.04 (Lucid Lynx).

In the process of wanting to make the server easier to manage I setup RSA keys on root, and www-data so that I can ssh into the server. The thing I didn't like was that www-data's .ssh directory sat in /var/www which is the default directory setup for apache. My worry is that if apache isn't configured properly then the .ssh directory can be exposed.

I came across the solution to move the ~/.ssh/authorized_keys file into a central location by changing AuthorizedKeysFile in /etc/ssh/sshd_config. This comes with 2 pros: A single location for keys, and not having to worry about a bad apache configuration. The single con that I can think of is that now every user is available for login on the server (clearly a double edged sword of the central key file.)

Is there anything that I've missed in this configuration? Have I over exposed myself, or is this a better solution than individual authorized_keys files?

I'm green when it comes to server management, but am totally ready to be called bad names for doing bad things. :D

Solution 1:

All the keys files can be centralized in the same directory and not mixed in the same file.

Simply set up the sshd_config file like this:

AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

On your server:

• www-data keys will be in /etc/ssh/authorized_keys/www-data
• root keys will be in /etc/ssh/authorized_keys/root

Regarding the access rights, these settings are accepted by sshd:

/etc/ssh/authorized_keys is owned by root:root and has mode 755. Key files are owned by root:root and have mode 644.

Other modes may work but I haven't tested them.

Solution 2:

Generally speaking I would not do what you're suggesting. It breaks common assumptions (like ~/.ssh/authorized_keys working for your users, and introduces problems you've already mentioned in your question. If you see glaring problems before implementation it means your solution isn't ideal.

Security-wise I also think it's a TERRIBLE idea to have everybody share a service account: Right now it's just you, and you know you're the one making changes. In 5 years when you have 5 admins you're going to want to know who changed what, and digging through audit logs to see who used what key when is a royal pain.
You are better off having people log in as themselves and use sudo or something similar to escalate their privileges and do whatever they need to do.

If you still want to centralize SSH keys I suggest looking into a deployment system like Puppet or radmind to manage/distribute the authorized_keys files to the appropriate ~user/.ssh/ directories (or hack up a home-grown a solution that SCPs them into place).
As you expand to multiple servers you may want to look in to the LDAP Public Key patch for older versions of OpenSSH (or the AuthorizedKeysCommand directive and an appropriate script in newer version of OpenSSH) as well so you can centralize your users and not have to distribute their keys all over your network, but that's likely to be pretty far down the road for you.