Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 5 down vote favorite

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

share|improve this question

2 Answers

up vote 7 down vote accepted

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 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.

share|improve this answer
+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. – thiton Sep 20 '11 at 15:46
Thanks for the feedback! If I'm understanding you correctly. I ought to have neither root nor www-data accessible via an ssh key is that correct? – Gavin Miller Sep 20 '11 at 15:50
1  
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. – voretaq7♦ Sep 20 '11 at 15:51
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? – Gavin Miller Sep 20 '11 at 15:52
@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... – voretaq7♦ Sep 20 '11 at 15:53
show 3 more comments
up vote 7 down vote

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.

share|improve this answer
+1, but I wouldn't set the others bit. Set ownership of the %u files to the user so that this isn't necessary. – Aaron Copley Sep 5 '12 at 18:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.