Is a central location for authorized_keys a good idea?

Question

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.

Comments

[Gert van den Berg]

At least public keys being exposed (read-only) on the internet isn't the biggest risk... (It might allow attackers to see if they can log into the server with a private key that they obtained elsewhere though, but it wouldn't allow them to log in by just obtaining that...) (The serious issues are if there is an id_rsa file in ~/.ssh and they manage to read that)

[thiton]

+1 for the sharing argument. Made short because it took me a moment to realize its implication: There should be no ~www-data/.ssh directory at all, so no security risk by the web browser.

[voretaq7]

Having a ~www-data/.ssh directory isn't a terrible thing (with appropriate permissions it's not a substantial risk), but if you're going to use ~www-data/.ssh it's probably better not to have your webroot be ~www-data (either move the webroot or move www-data's home directory). The differentiation of users is the bigger argument IMHO - I know if I see jsmith log in I know it's John Smith. If I see www-data log in I need to dig more to find out who that was.

[Gavin Miller]

The reason why I needed an ssh key for www-data is that I'm using Beanstalk (SCM & deploy tool) to do the deployments over SFTP. Should I then create a seperate account for Beanstalk to do the ftp'ing? What would be the best solution there?

[voretaq7]

@Gavin - I personally don't think anyone should ever log in to service accounts, and root should never be accessible over the network (Console login only. You should of course have provisions to get into your system and become root though). I have a very high level of paranoia though. If you have a tool (like Beanstalk) that needs access that may justify an exception for the sake of simplicity, but beware the "who did what when?" confusion that can result if the tool isn't robust...

[Gavin Miller]

@voretaq7 I appreciate the high level of paranoia (sign of a good sys admin imho) thanks for the detailed answer!

[Aaron Copley]

+1, but I wouldn't set the others bit. Set ownership of the %u files to the user so that this isn't necessary.

[con-f-use]

The way it is on most systems the AuthorizedKeysFile in /etc/ssh/sshd_config defaults to %h/.ssh/authorized_keys. Here %h is a placeholder for the home directory. What keeps you from setting it to /some/folder/ssh_keys_by_user/%h/ or even /root/ssh_keys/%u. You could even give the respective user write access to his individual file there (and only his) link the file to the standard location (with ln -s /root/ssh_keys_by_user/username /home/username/.ssh/authorized_keys) and not break the aformentioned assumptions.

[voretaq7]

@con-f-use Theoretically, nothing - that's a perfectly viable solution as long as you document it. In this particular case though I don't think the tradeoff of documenting and maintaining something "different" is The Right Thing, especially given the other caveats I raised in my answer.

[bbaassssiiee]

Good solution to the problem that malicious users can add more public keys to their ~/.ssh/authorized_keys granting access to others.

[Luis E.]

I just confirmed that mode 600 for a user's authorized keys file doesn't work; it needs to be mode 644

[DylanYoung]

@bbaassssiiee This ABSOLUTELY DOES NOT solve that issue. They can just share their private key with whomever they want to give access (this possibility can be mitigated of course, but this answer does absolutely zero to mitigate it)

[bbaassssiiee]

@DylanYoung I admit sharing private keys is possible. But with chattr i can revoke write access to authorized_keys files so i can distribute those exclusively, safeguarding a single line in every file too.

[DylanYoung]

@bbaassssiiee It is certainly useful. I just don't want anyone to get the mistaken idea that this will prevent unauthorized access to the machine. You still need legal (NDA, Contract, etc.) or technical (IP restrictions, VPN, etc.) mitigations in place, and preferably both. That said, of course it improves the situation security-wise :)

[timelmer]

PoI: If you are trying to get this to work in a domain environment using the Windows version of SSHD, you may notice that SSHD is complaining about ...authorized_keys/domain\\user not existing. I managed to get around this by creating a subdirectory ...authorized_keys/domain/, and placing the user files under that.