SSH: one authorized_keys for multiple service accounts

Question

Is there a way to configure SSH to check a single authorized_keys file for multiple users? I know I can copy the public key into each user's authorized_keys file but for ease of management I'd like an additional authorized_keys file for the administrators that would allow them to login to all the users (or specific groups of users).

Solution 1

You can use the AuthorizedKeysFile directive in /etc/ssh/sshd_config to do this. The defaut location is .ssh/authorized_keys but you could use something which contained an absolute path e.g.

AuthorizedKeysFile /path/to/your/keyfile

the man pages says this

AuthorizedKeysFile

Specifies the file that contains the public keys that can be used for user authentication. AuthorizedKeysFile may contain tokens of the form %T which are substituted during connection setup. The following tokens are defined: %% is replaced by a literal ’%’, %h is replaced by the home directory of the user being authenticated, and %u is replaced by the username of that user. After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user’s home directory. The default is “.ssh/authorized_keys”.

Solution 2

Edit: You should upvote @Iain's answer above. It is complete and accurate. My answer below is geared towards shared private keys - clearly a misunderstanding on my part. I'll leave this answer here, since I consider it a valuable piece of information, just not for this specific question.

---

I don't know your use-case, but I'm tempted to say "you're doing it wrong."

Each user should have their own kepair. That way, when a user leaves, is transferred, promoted to a management role, or anything else that requires revocation of rights, you just revoke that one key. This also makes effective auditing much, much harder.

If you need users to be able to impersonate other users, they should be configured to do so with sudo. Having shared SSH keys is normally not a good idea.

Solution 3

Your administrators should use and appropriate (for your environment) combination of sudo and su.

ssh is not the right tool for this.

Contradictory Edit (Sorry, looks like I suffered from title blindness. Thank you Zoredache):

Put all of the service accounts in the same group, use that group as part of a Match block in sshd_config specify the AuthorisedKeysFile you want them all to use. (The match group is so that all accounts are not effected.) They will, however, no longer have individual AuthorisedKeysFiles. openssh-lpk may allow the individual accounts to have their own keys in addition, but I'm not sure about that.

Solution 4

As of writing of this post, it can be accomplished with this configuration in sshd_config:

AuthorizedKeysFile  .ssh/authorized_keys /etc/ssh/authorized_keys

And making sure /etc/ssh/authorized_keys is readable by at least the user you're trying to login as. If it's chmod 600, readable by root only, it will not work.

chmod 644 /etc/ssh/authorized_keys

Then it will work.

This way no need to consolidate unnecessarily all SSH public keys into one place, and we preserve the natural functionality of looking in ~/.ssh/authorized_keys.

Since the file only contains public keys, we chmod to 644 to make it world-readable but not world-writable. An alternative way would be to create a custom group to expose it slightly less, but regardless, more than one user will always have to have access to this file no matter what we do, so it's unnecessary to make permission too convoluted for this file in this case.

Please note that all users includes root as well, so you should only add yourself to /etc/ssh/authorized_keys on a server you already have root access to.

View more solutions

Comments

[voretaq7]

Can you tell us why you're trying to do this? Or why other tools as described in the answers below wouldn't work for you? ("ease of management" is not a great reason - your admins should have root, or permission to run sudo to execute various tasks, which is pretty easy. What you're proposing breaks logging/accountability which is generally a Bad Thing absent truly excellent reasons...)

[ctlq]

The ssh for the users is really only being used for SFTP subsystem and managing multiple websites. Each website is running under a different user so if one is compromised the rest aren't as well. Keeping all administrators in one authorized_keys file instead of multiple means we have one place to adjust when a person leaves the company. Yes, we will lose out on some accountability but that's already happening by logging into the individual users directly.

[Zoredache]

@voretaq7, assuming he just wants to authorize people to many accounts. If you have LogLevel VERBOSE then you know which key accessed was used to access and perform actions on the system, which may be adequate for logging in some cases.

[Zoredache]

I can understand your desire for a shared authorized_keys file, and I can even see as it be useful and not that bad in some cases. But the better solution though would be to setup the administrator accounts then adjust the permission/acls of the files/directories in question so your administrators have access to all places they need.

[Zoredache]

Related SSH feature request. bugzilla.mindrot.org/show_bug.cgi?id=172

[voretaq7]

@Zoredache true, but do you really want verbose SSH logs everywhere? Yuck :(

[user9517]

@voretaq7: VERBOSE isn't too bad for sshd.

[Zoredache]

Perhaps you are reading it differently, but he asked for a common authorized_keys file, not for shared private keys. The authorized_keys file can have lots of different public keys.

[Zoredache]

I wish SSH permitted multiple AuthorizedKeysFile paths, I was about to suggest this, but then I wondered if he wanted to support individual keys per-account in addition to the administrator keys.

[ctlq]

Thanks lain & Zoredache this will work. Ideally, I'd like the multiple AuthorizedKeysFile option that Zoredache found the feature request for but for the time being this will make things much easier.

[voretaq7]

@ctlq If you go this route and intend to use SSH for interactive shell logins at some point you may want to consider running an alternate SSH daemon on another port so you can still have standard sshd authorized_keys behavior on the one you use for logins. (You may also want to restrict the sftp-daemon to the sftp subsystem only, or apply the same restriction to the keys you're authorizing - just as a bit of security paranoia)