30

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

  • 1
    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) – Gert van den Berg Feb 17 '16 at 8:23
52

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.

|improve this answer|||||
  • 3
    +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
  • 1
    Good solution to the problem that malicious users can add more public keys to their ~/.ssh/authorized_keys granting access to others. – bbaassssiiee Feb 5 '16 at 15:47
  • I just confirmed that mode 600 for a user's authorized keys file doesn't work; it needs to be mode 644 – Luis E. Aug 17 '18 at 2:39
  • @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) – DylanYoung Nov 15 '18 at 17:50
  • 1
    @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. – bbaassssiiee Nov 15 '18 at 18:06
15

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.

|improve this answer|||||
  • 1
    +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
  • 1
    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. – con-f-use Jan 24 '13 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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