Consider a generic up-to-date Linux distro hosting a web server. I need three humans to occasionally SSH into the same user account to perform some action that can only be done by that particular user account.

The 'easy way' to do this would be to simply allow SSH by password and to give the username/password combo to all three humans. However, I prefer to disable password logins and to require RSA keys. Is there a way to configure SSH to accept the RSA keys from three different users? I don't want to distribute the same keys to those users as they do log into other servers as well.

  • man authorized_keys
    – ruief
    Apr 14 '13 at 13:05

Yes, you can have multiple keys that are allowed to log into an account. This is a common configuration among users who have multiple trusted machines and keep a separate private key on each one.

This is also a reasonable configuration for a service account that is only meant to access one application. In this situation it is usually combined with a restricted or special-purpose login shell that only allows access to that specific application. For example, gitosis is a gateway to the Git version control system, and handles user authentication by itself, sticking to a joint git account at the unix level. If multiple people can run arbitrary command through this account, you should really give them different unix accounts.

Get the users to send you a public key, and concatenate the public keys together to form the ~/.ssh/authorized_keys file, or equivalently append each public key starting from an empty file.

You can put restrictions on the keys themselves in the authorized_keys file. For example, ssh-rsa AAAA… alice@example.com declares a key with no restrictions, whereas a user who logs in with the following key is only allowed to log in from a specific IP subnet, may not forward ports, and may only run a specific command:

command="/usr/local/bin/restricted-app",from="",no-agent-forwarding,no-port-forwarding,no-x11-forwarding ssh-rsa AAAA… bob@example.com

If you rely on command restrictions, be careful that the command doesn't allow any indirect way to obtain a shell or to edit files in the .ssh directory or any other sensitive location. You may make the account's home directory, the ~/.ssh directory and its contents owned by root and accessible for reading by the user, which would prevent privilege escalation in case the restricted application has a file overwrite vulnerability but no shell escape vulnerability.

Set LogLevel VERBOSE (one step up from the default level INFO) in the server configuration (sshd_config) to log which key was used to log into the account each time.


Have you considered just making 3 users and putting these in a group that can only execute that particular action. This will increase your tracing capability. This is actually the whole point why users and groups are available in an operating system.

If for some reason that is not possible you can still allow them to log in (and not do ANYTHING else) and su to particular user.

There are also other systems like PowerBroker which give an additional shell that logs all command strokes, but for your use-case it's probably massive overkill.

  • Yes, I had considered giving each user their own account but that was rejected by the owner of the box (actually not technically feasible due to an inherent 'feature' of Plesk which they use). I could work around that by giving them all accounts on another server which could then SSH into the machine in question, but that just feels like a chain with too many links.
    – dotancohen
    Apr 12 '13 at 10:22

It is easy to allow several keys to access a given account: simply put all the public keys, one after the other, in the .ssh/authorized_keys file of the target account. Any user controlling one of the corresponding private keys will be able to open a connection to that account.

Ideally, don't generate the keys yourself; have each user generate his own key pair (with ssh-keygen) and send you the resulting .ssh/id_dsa.pub or .ssh/id_rsa.pub (depending on the type of key they generated). You then paste the .pub file contents into the .ssh/authorized_keys (these are text files).

To restrict what these users can do with the account, see @Gilles' answer (that's an important, but orthogonal question).

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.