Using SSH Keys with Multiple Accounts on a Single Remote Server

Why Separate Keys for Each Account Matter

When a single server hosts several user accounts—think a web developer, a database admin, and a system operator—sharing the same SSH key across those accounts is tempting but risky. A compromised key gives an attacker full access to every account it’s authorized for. Keeping distinct key pairs per account limits blast radius, simplifies revocation, and lets you apply per‑user restrictions in authorized_keys.

Generating and Distributing Keys

# On the client, generate a key for the web dev
ssh-keygen -t ed25519 -f ~/.ssh/webdev_id_ed25519 -C "[email protected]"

# For the DB admin
ssh-keygen -t ed25519 -f ~/.ssh/dbadmin_id_ed25519 -C "[email protected]"

I always pick ed25519 because it’s faster and still strong. Store the private keys with chmod 600. Push the public key to the server for each user:

ssh-copy-id -i ~/.ssh/webdev_id_ed25519.pub webdev@server
ssh-copy-id -i ~/.ssh/dbadmin_id_ed25519.pub dbadmin@server

ssh-copy-id appends the key to the target user’s ~/.ssh/authorized_keys. If you want tighter control, you can do it manually:

cat ~/.ssh/webdev_id_ed25519.pub | ssh webdev@server \
    'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

Configuring the Server

On the server, make sure sshd_config allows key authentication and that you’ve disabled password logins for the accounts you want to harden:

PasswordAuthentication no
ChallengeResponseAuthentication no

If you need to keep password access for a particular user, override the global setting with a Match User block:

Match User webdev
    PasswordAuthentication yes

The authorized_keys file can hold per‑key options. For example, restrict the DB admin key to run only psql and block port forwarding:

command="/usr/bin/psql -h localhost",no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ...

Check the OpenSSH manual for full syntax: https://man.openbsd.org/sshd_config.

Client‑Side Convenience

I usually keep a per‑user entry in ~/.ssh/config so I can just type ssh webdev@server without the -i flag:

Host webdev-server
    HostName server.example.com
    User webdev
    IdentityFile ~/.ssh/webdev_id_ed25519
    IdentitiesOnly yes

IdentitiesOnly yes forces the client to use only the listed key, preventing accidental use of a different key that might be loaded in ssh-agent.

If you’re using a passphrase, ssh-agent or the newer keychain helper can cache decrypted keys:

eval "$(keychain --eval --agents ssh webdev_id_ed25519 dbadmin_id_ed25519)"

That keeps your shell tidy while still protecting the private keys.

Security Tips

Key permissions: chmod 600 ~/.ssh/* on both client and server.
Use ssh-keygen -o to store keys in the newer OpenSSH format, which is more resistant to brute‑force attacks.
Rotate keys regularly. A simple script can generate a new pair, copy it to the server, and revoke the old one.
Audit authorized_keys with ssh-keygen -l -f to verify fingerprints.
Disable root login unless you have a dedicated root key and strict restrictions.

Common Pitfalls

Over‑sharing a key – A single key in multiple authorized_keys files defeats isolation.
Leaving PasswordAuthentication yes – Even if you use keys, a password fallback can be exploited.
Using the same key for local and remote access – Keep local user keys separate from remote server keys to avoid cross‑account compromise.
Neglecting key expiration – Keys that never expire can stay valid after a user leaves the organization.

Quick Troubleshooting

Symptom	Likely Cause	Fix
`Permission denied (publickey)`	Wrong key in `authorized_keys`	Verify the public key hash with `ssh-keygen -l -f ~/.ssh/id_ed25519.pub`.
`ssh: connect to host … port 22: Connection refused`	SSH daemon stopped	`systemctl status sshd` and `systemctl start sshd`.
`ssh: no matching host key type found`	Client uses old key type	Update `~/.ssh/config` to `HostKeyAlgorithms +ssh-ed25519`.

By keeping each account’s key separate, configuring per‑user restrictions, and enforcing key‑only authentication, you reduce attack surface while keeping a smooth workflow for multiple users on a single server.

linux ssh hardening