A single server is often used by multiple people and accessed from various devices. In a team setting, every member should have their own SSH key; for individual use, you might need separate configurations for a laptop, a desktop, and a backup machine. If all devices share the same key, the entire server is put at risk should a device be lost or the key compromised.

The best practice is to configure multiple SSH keys on a single VPS—assigning a unique key to each person and each device—to ensure clear access rights and risk isolation. This article provides a step-by-step guide covering everything from key generation and server-side configuration to client-side management and security hardening.

First, understand the concept: `authorized_keys` is a "list of public keys."

The core logic of SSH public key authentication is simple: the `~/.ssh/authorized_keys` file on the server contains a list of authorized public keys, with each key occupying a single line. The client holds the corresponding private key; during login, the server verifies the private key's signature against the public key and grants access if the verification succeeds.

You can store any number of public keys in this file—one per line. You might add a line for each team member or separate lines for the same person using different devices. You can also prepend restrictions to each line—such as limiting source IP addresses or restricting executable commands—to achieve finer-grained access control.

Step 1: Generate multiple key pairs locally

Do not overwrite the default `id_ed25519` key. Generate a separate key for each purpose and include an identifier in the filename.

Work key

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work -C "work@company"

Personal laptop key

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_laptop -C "laptop@home"

Backup device key

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_backup -C "backup@spare"

`-t ed25519` specifies the recommended key type, which is shorter, faster, and more secure than RSA. `-f` specifies the save path, and `-C` adds a comment for easy identification. It is recommended to set a strong passphrase during generation; this ensures that even if the private key file is compromised, an attacker cannot use it without the passphrase.

Step 2: Upload the public key to the server

The most straightforward method is to use `ssh-copy-id` and specify the key file:

ssh-copy-id -i ~/.ssh/id_ed25519_work.pub user@server-IP

If the server has disabled password-based login, you must first log in using an existing valid key and then manually append the public key:

cat ~/.ssh/id_ed25519_laptop.pub | ssh user@server-IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Note the use of `>>` to append, rather than `>` to overwrite. Overwriting would erase all existing public keys, preventing other devices from logging in.

Step 3: Managing multiple public keys on the server

After logging into the server, view the currently authorized public keys:

cat ~/.ssh/authorized_keys

Each line represents a public key. It is recommended to clearly label the purpose in the comment section at the end of each line—for example, `work-laptop`, `home-desktop`, or `ci-deploy`. This makes it immediately obvious who owns a specific key when troubleshooting later.

If multiple people share the same server, a more standard practice is to create a separate system user for each person. Each user maintains their own `~/.ssh/authorized_keys` file within their home directory, ensuring no interference between users. To create a new user and import their public key:

sudo adduser alice

sudo mkdir -p /home/alice/.ssh

sudo cp /tmp/alice.pub /home/alice/.ssh/authorized_keys

sudo chown -R alice:alice /home/alice/.ssh

sudo chmod 700 /home/alice/.ssh

sudo chmod 600 /home/alice/.ssh/authorized_keys

This ensures that "alice" can only log into her own account using her own key and cannot access other users' files, resulting in more robust permission isolation.

Step 4: Client-side configuration to simplify login commands

If you have multiple keys locally, specifying the `-i` parameter every time you log in can be cumbersome. Configure aliases and their corresponding keys for each host in your local `~/.ssh/config` file:

Host jtti-work

HostName server-ip

User alice

IdentityFile ~/.ssh/id_ed25519_work

IdentitiesOnly yes

Host jtti-personal

HostName server-ip

User bob

IdentityFile ~/.ssh/id_ed25519_laptop

IdentitiesOnly yes

`IdentitiesOnly yes` is a crucial setting; it forces SSH to use only the specified key, preventing the client from attempting every local key. This is particularly important when the server limits the number of login attempts.

Once configured, you can simply run `ssh jtti-work` to log in, without needing to remember the IP address or key path.

Step 5: Add restrictions to public keys

You can add options before the public key in the `authorized_keys` file to implement finer-grained control. For example, restrict a key so it can only log in from specific IP addresses:

from="192.168.1.0/24,10.0.0.5" ssh-ed25519 AAAAC3... work@company

Restrict a key so it can only execute a backup command:

command="/usr/local/bin/backup.sh" ssh-ed25519 AAAAC3... backup@spare

These options allow multiple keys on the same server to have different permission boundaries. When deploying keys for automated tasks, restricting them to specific commands ensures that even if a key is compromised, an attacker cannot gain access to a full shell.

Step 6: Verification and troubleshooting

Do not close your current SSH session after adding a new key. Open a new terminal and test the login using the new key:

ssh -i ~/.ssh/id_ed25519_work user@server-ip

If the login fails, troubleshoot in the following order:

Permission issues are the most common cause. On the server, `~/.ssh` must have permissions set to 700, `authorized_keys` to 600, and the home directory must not be 777. If permissions are incorrect, SSH will reject the key outright.

SELinux contexts may block access on RHEL/CentOS-based systems. Run `restorecon -Rv ~/.ssh` to restore the correct security context. The `authorized_keys` file requires one complete public key per line, without extraneous line breaks or spaces. Truncation during copy-pasting from a web page can also cause authentication to fail.

Regarding `sshd_config`, ensure that `PubkeyAuthentication yes` is enabled and that there is no `AuthorizedKeysFile` directive pointing to a different path.

Security Recommendations and Jtti’s Infrastructure Support

Managing multiple keys is more complex than managing a single key, so security practices must evolve accordingly. Regularly audit the `authorized_keys` file to remove public keys belonging to former team members or decommissioned devices. Disable password-based logins and direct root logins, mandating key-based authentication for all users. Assign a unique passphrase to each key to prevent immediate use of the private key should it be stolen.

The stability of the underlying infrastructure is equally critical. Jtti’s cloud servers come with a clean Linux installation by default, allowing users to independently manage their SSH key infrastructure from the very first login. Nodes in Hong Kong and the US utilize premium CN2 GIA lines with optimized direct connectivity across major carriers; this ensures low latency and zero packet loss when managing servers via SSH from within China, providing a smooth and stable experience when switching between devices. All plans feature dedicated IP addresses and exclusive bandwidth, eliminating resource contention common in shared environments. A consistent renewal pricing policy ensures predictable long-term operating costs.

Configuring multiple SSH keys on a VPS is essentially about clearly defining "who can access the system," "where they access it from," and "what actions they can perform." Visit the Jtti official website to explore cloud server solutions designed for team collaboration and multi-device management.