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… firstname.lastname@example.org 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="192.0.2.0/24",no-agent-forwarding,no-port-forwarding,no-x11-forwarding ssh-rsa AAAA… email@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.
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.