Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
1  
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...) –  voretaq7 Oct 4 '12 at 17:41
2  
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. –  ctlq Oct 4 '12 at 17:59
1  
@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 Oct 4 '12 at 17:59
1  
Related SSH feature request. bugzilla.mindrot.org/show_bug.cgi?id=172 –  Zoredache Oct 4 '12 at 18:20
1  
@voretaq7: VERBOSE isn't too bad for sshd. –  Iain Oct 4 '12 at 21:19
show 2 more comments

3 Answers 3

up vote 10 down vote accepted

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

share|improve this answer
    
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. –  Zoredache Oct 4 '12 at 18:21
    
@Zoredache: then perhaps you could use /etc/keys/%u_AuthorizedKeys to have them all in a centralised directory and one for each user. If the admins share an account but have different keys that should work. –  Iain Oct 4 '12 at 18:23
    
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. –  ctlq Oct 4 '12 at 18:56
1  
@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) –  voretaq7 Oct 4 '12 at 19:15
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 Oct 4 '12 at 17:56
    
It seems I may have misread this question after all. –  MDMarra Oct 4 '12 at 18:00
add comment

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.