SSH key management for VPS: generate, distribute, rotate

SSH keys are how you actually log into your VPS. Passwords work but they're a liability, brute-forceable, phishable, leakable through bad password managers. A properly managed SSH key pair is the right default. Here's the full workflow.

Generate your key

If you don't already have one:

$ ssh-keygen -t ed25519 -C "your-email@example.com"
Generating public/private ed25519 key pair.
Enter file in which to save the key (~/.ssh/id_ed25519): [enter]
Enter passphrase: [type a passphrase, twice]

This creates two files:

• ~/.ssh/id_ed25519, the private key. Never leaves your machine, never shared, never committed to git.
• ~/.ssh/id_ed25519.pub, the public key. Safe to share, paste into dashboards, commit to internal docs.

The passphrase is critical. If your laptop is stolen, the encrypted key file is useless without it.

Add it to a new VPS at provision time

In the RareCloud dashboard: Account → SSH keys → Add new. Paste the contents of ~/.ssh/id_ed25519.pub. Give it a name like laptop-2026.

Now when you create a new server, pick this key from the dropdown. RareCloud injects it into /root/.ssh/authorized_keys on first boot. You can SSH in immediately without setting a root password.

Via the CLI:

$ rarecloud server create --ssh-key my-laptop --plan core-vps ...

Via Terraform:

resource "rarecloud_server" "api" {
  ssh_public_key = rarecloud_ssh_key.laptop.public_key
  ...
}

Add a key to an existing VPS

SSH in (using the original key), then append the new public key to ~/.ssh/authorized_keys:

$ echo "ssh-ed25519 AAAA... colleague@laptop" >> ~/.ssh/authorized_keys

That's it. The colleague can now log in. Order in the file doesn't matter; SSH tries every key the client offers against every key in the file.

Manage multiple keys with ~/.ssh/config

If you SSH to several different VPSes with different keys, save yourself the -i ~/.ssh/specific_key flag every time. Edit ~/.ssh/config:

Host prod
    HostName 85.121.241.12
    User root
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

Host staging
    HostName 85.121.241.18
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    IdentitiesOnly yes

Host *.rarecloud.io
    User root
    IdentityFile ~/.ssh/id_ed25519

Then:

$ ssh prod          # uses prod key, root user
$ ssh staging       # uses staging key, deploy user

IdentitiesOnly yes is important when you have many keys: without it, SSH offers every key to the server in turn and can hit a "too many auth failures" rate limit before reaching the right one.

Agent forwarding (carefully)

You're on your laptop, SSHed into a bastion. From the bastion you want to clone a private GitHub repo or SSH onward to a production box, but you'd rather not put your private key on the bastion (which is a shared machine).

Agent forwarding lets the bastion use your local key without it being copied there:

Host bastion
    HostName bastion.example.com
    User admin
    ForwardAgent yes

Now from your laptop:

$ ssh bastion
admin@bastion:~$ git clone git@github.com:org/private-repo.git    # works, uses your laptop's key

Caveat: anyone with root on the bastion can use your forwarded agent for as long as you're connected. Only enable ForwardAgent yes for hosts you fully trust.

Rotate a compromised key

You lost the laptop. The key passphrase will slow the attacker down but not forever. To rotate:

1. Generate a new key on a fresh machine: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_new
2. Add the new public key to every VPS via dashboard or by SSHing in from any other machine that still has access:

   ssh prod 'echo "ssh-ed25519 AAAA...new" >> ~/.ssh/authorized_keys'
   

3. Verify the new key works: ssh -i ~/.ssh/id_ed25519_new prod
4. Then remove the old key:

   ssh prod 'sed -i "/old-key-comment/d" ~/.ssh/authorized_keys'
   

5. Update the SSH key in the dashboard (so future server provisioning uses the new one).
6. Run git remote set-url if you also used the old key for GitHub, and update any CI deploy keys.

Always add the new key before removing the old one. The reverse order locks you out if step 4 fails midway.

Where to go next

• Security checklist, once SSH keys are in order, disable password auth entirely and harden sshd.
• The CLI can manage your registered SSH keys: rarecloud ssh-key list / add / remove.