Add or replace an SSH key on a running server

To give a new key access to a server that's already running, add its public key to /root/.ssh/authorized_keys on that server, while you can still log in with your current key or password. Then test the new key in a second session before you remove anything.

Your account's keys and a server's keys are separate lists. The keys you save in the panel are copied onto a server when it's created or reinstalled, and nothing after that. Adding a key in the panel doesn't reach servers that are already running, and deleting one there doesn't take it off them. So for a running server, you change the server itself, as below. It's still worth saving the new key in your account too, so your next server gets it.

Before you start#

• Make the new key on the computer that will use it; Use SSH keys instead of a password shows how. You only ever copy the .pub file. Never paste a private key into the panel, a ticket or a chat.
• You need a way in right now: your current key, or a root password. If you have neither, start with Get back into a server you're locked out of instead.

The examples use 203.0.113.42; use your server's address.

Add the new key#

Run this on a computer that can log in to the server today. Point it at the new public key, wherever that file is:

cat ~/.ssh/new_laptop.pub | ssh root@203.0.113.42 "cat >> ~/.ssh/authorized_keys"

In PowerShell on Windows:

type $env:USERPROFILE\.ssh\new_laptop.pub | ssh root@203.0.113.42 "cat >> ~/.ssh/authorized_keys"

>> adds a line to the end of the file; it doesn't replace the keys already there. (On Linux and macOS, ssh-copy-id -i ~/.ssh/new_laptop.pub root@203.0.113.42 does the same thing.)

If you're on the new computer and the old key is somewhere else, you can do the same from the server instead: log in the way you can, open the file with nano /root/.ssh/authorized_keys, paste the new public key as a line of its own at the end, and save.

Test it in a second session#

Keep your current session open. From the computer with the new key, open a new terminal and log in with only that key:

ssh -o IdentitiesOnly=yes -i ~/.ssh/new_laptop root@203.0.113.42

Only carry on once this works. If it doesn't, the old way in still does, so nothing is lost: see Fix "Permission denied".

Remove the old key#

Removing a key is how you cut off a lost laptop or a person who's left. Do it from the session that uses the new key, so you can't lock yourself out.

First list the keys on the server with their fingerprints:

ssh-keygen -lf ~/.ssh/authorized_keys

Each line is one key that can log in as root:

256 SHA256:h4cJsRcy3uNRoKwh/FsukbIdD+CIk5EGy+DdlFzndtY no comment (ED25519)
256 SHA256:6dn6KtcXfi4SC/oUAF3pCV9WCsBeMWlX/afr6xAXQ+U new-laptop (ED25519)

Keys we put on the server when it was built carry no comment, so match them by fingerprint: the panel's keys page shows each saved key's SHA256: fingerprint, and ssh-keygen -lf ~/.ssh/id_ed25519.pub shows the one on a computer you still have.

Then remove the old key by its fingerprint. Put the fingerprint you're removing in OLD, and run this on the server:

OLD="SHA256:h4cJsRcy3uNRoKwh/FsukbIdD+CIk5EGy+DdlFzndtY"
cd ~/.ssh && cp authorized_keys authorized_keys.bak
while IFS= read -r line; do
  printf '%s\n' "$line" | ssh-keygen -lf - 2>/dev/null | grep -qF "$OLD" || printf '%s\n' "$line"
done < authorized_keys.bak > authorized_keys
ssh-keygen -lf authorized_keys

It keeps every line except the one with that fingerprint, writes the result back with the same permissions, and lists what's left. The original stays in authorized_keys.bak until you're sure, then delete it with rm ~/.ssh/authorized_keys.bak.

Finally, from a third terminal, check that the old key no longer gets in: you should see Permission denied (publickey). And delete the old key from your account's keys page in the panel, so it isn't put on servers you create or reinstall later.

Other users and teammates#

The steps above change root's keys. If you log in as another user, the file is that user's ~/.ssh/authorized_keys instead, for example /home/deploy/.ssh/authorized_keys, and the same steps apply.

Removing someone from your team stops their access to the panel, not to your servers: any key of theirs on a server keeps working until you remove it there. When someone leaves, check ssh-keygen -lf on every server they could reach.

If the server took passwords#

A server ordered with a root password and no key still accepts that password over SSH after you add a key. Once your key works, turn password logins off with the SSH hardening checklist.

We tested every command on this page on Rack4 servers running Ubuntu 24.04 and Debian 13 on 6 November 2026, from Linux and from Windows 11 PowerShell.