Regaining Access to DigitalOcean Droplets

This one is about the day I locked myself out of my own servers, and the calm way back in. I've refreshed it because the control panel has moved on since I first wrote it, and modern Ubuntu changed one detail that trips people up.

What actually went wrong

I'd reinstalled the OS on my main machine; in doing that, I wiped my SSH keys.

Quick demystify: an SSH key is a matched pair of files. The public half lives on the server, the private half stays on your machine, and when the two match up the server lets you in without a password. It's a good deal more secure than a password, right up until you delete the private half by accident. Then you've got a public key sitting on a server with no private key anywhere to match it.

So my services were all up and running happily, I just couldn't get onto the boxes to touch anything. Not a great place to be.

Why does losing one key lock you out completely?

Because password login is switched off by default. When you create a Droplet (DigitalOcean's word for a virtual server) with an SSH key attached, it disables password authentication for you, on purpose, because keys are the safer option. That's the right default. But it does mean the key is your only way in, so if the key's gone, so is your access.

The fix is to get back in through a side door, turn password login on just long enough to add a fresh key, then shut the side door again.

The short version

1. Reset the Droplet's root password from the control panel.
2. Log in through the Recovery Console with that password.
3. Turn password authentication on in the SSH config, and restart SSH.
4. SSH back in, add a new key, then turn password authentication off again.

Now the same thing in detail.

Step 1: Reset the root password

In the control panel, open the Droplet and go to the Settings tab. Scroll to Reset root password and click Reset Root. DigitalOcean emails you a temporary password.

One thing worth knowing before you try: a few distributions manage their root password internally and can't be reset this way (AlmaLinux, Rocky, recent Fedora, FreeBSD). If that's you, you'll see a note saying as much in that same section, and the route back is to snapshot the Droplet and redeploy to a fresh one instead. For the usual Ubuntu, Debian and CentOS boxes, the reset works fine.

Step 2: Get in through the Recovery Console

Still on the Settings tab, find the Recovery console section and click Launch Console. This is the out-of-band console, meaning it reaches the server directly even when the network or SSH itself is down, which is exactly the situation we're in. It's clunky next to the normal Droplet Console (copy and paste is fiddly), but it works when nothing else will.

Click into the console and press Enter so the login prompt has focus. Log in as root, enter the temporary password from the email, and you'll be asked to set a new root password straight away. Set it, and you're in.

Step 3: Turn password login back on

Open the SSH config. This is the file the SSH service reads to decide who's allowed in, and how:

nano /etc/ssh/sshd_config

Find this line and change no to yes:

PasswordAuthentication yes

Here's the bit that's new since I first wrote this, and the reason plenty of people do everything right and still can't log in. On Ubuntu 22.04 and up, and Debian 12 and up, the provider drops a second config file in alongside the main one:

/etc/ssh/sshd_config.d/50-cloud-init.conf

That drop-in is read last, so it overrides the main config. It usually carries its own PasswordAuthentication no, which quietly cancels out the change you just made. So set it to yes in there too (or just delete that line from the drop-in):

nano /etc/ssh/sshd_config.d/50-cloud-init.conf

SSH only reads its config when it starts, so restart it to pick up the change. The command depends on the OS:

# Modern Ubuntu and Debian
systemctl restart ssh

# CentOS 7+, Fedora, most RHEL-family
systemctl restart sshd

(The old service ssh restart still works on ancient boxes, but on anything current, use systemctl.)

Step 4: Add a fresh key and lock it back down

Password login is on now, so from your own machine you can push a new public key straight up:

ssh-copy-id root@your.droplet.ip

If you'd rather do it by hand, paste your public key onto the end of ~/.ssh/authorized_keys on the server, and get the permissions right or SSH will silently ignore it:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Open a fresh connection and confirm the key actually works before you change anything else. Once you're happy it does, go back and set password authentication off again (in both files this time), and restart SSH:

PasswordAuthentication no

That leaves you exactly where you started, keys only, with a working key you actually hold.

Why keys only, rather than leaving passwords on?

It's tempting, after all that, to just leave password login on so you never get locked out again. I'd steer away from it. A password is one guessable string away from letting anyone in from anywhere. A key won't authenticate unless the matching private half is sitting on the machine trying to connect, so even if someone learns your password, there's no key on their end to let them through.

The lockout I described is the price of that safety, and it's a fair price, as long as you keep a backup of your private key somewhere sensible. Which, these days, I do.