SSH: one authorized_keys for multiple service accounts

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:

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 3:

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.