How to secure a VPS. Without locking yourself out.

Three things. Five minutes. They turn every mistake in this guide from a disaster into an inconvenience.

1. Open your web console once

Every LiteKeep server has a web console on its page in your account. It works even when SSH doesn’t: it’s like plugging a screen into the server. Open it now, before you need it, and check that you can log in there.

2. Take a snapshot

Take one from the server’s Snapshots tab. If you break something badly, you can roll the whole server back in minutes.

3. Keep your first session open

The SSH window you’re logged in with right now is your lifeline. Don’t close it until the very last test passes. Changes to SSH don’t kick out a session that’s already connected, so this window keeps working even if a setting goes wrong.

Every step in this guide fits into this sequence. The two highlighted boxes are tests. You don’t move past them until they pass.

Why this order? Because each step only takes something away after you’ve proven its replacement works. A new user before root goes away. A firewall rule for SSH before the firewall goes up. A working key before passwords go off.

Generate your exact commands

Pick your system, choose a username, tick what you need. The plan updates as you type. It handles the Ubuntu 24.04 SSH change for you, and it warns you if you pick a username the bots already guess.

No server yet? Deploy a Lite 2, paste this plan in its first minute online, and you start hardened instead of catching up. It bills by the hour, so a practice run costs cents.

Prefer to understand each step before you run it? Good instinct. The next five chapters walk through them one at a time.

Start with every update available:

apt update && apt full-upgrade -y

Then make sure the next fix installs itself. On Ubuntu Server, unattended-upgrades is installed by default and applies security updates automatically. Some images ship without it, so check. On Debian, you usually need to switch it on:

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Then prove it runs. We’ve seen a server with it switched on and its timers masked, so it had never installed anything. Our unattended upgrades tutorial has a one-paste checker.

Confirm it’s on:

cat /etc/apt/apt.conf.d/20auto-upgrades

You want to see both lines set to "1".

Why this matters: a real example

In July 2024, a serious flaw in OpenSSH known as regreSSHion (CVE-2024-6387) let attackers run code on a server without logging in. Ubuntu 22.04 and 24.04 were affected. Fixed packages shipped on 1 July 2024, and servers with automatic security updates picked them up on their own.

Servers without them waited for someone to remember.

Create an SSH key on your computer

An SSH key is a pair of files: a private one that never leaves your computer, and a public one you give to the server. There’s nothing to guess. macOS and Linux include the tool, and on Windows 10 and 11 it’s a built-in optional feature (our Windows walkthrough checks and installs it):

ssh-keygen -t ed25519

Press Enter to accept the location, then set a passphrase. Your public key is the file ending in .pub.

Create your own user on the server

Pick a username bots don’t guess. On our server, admin was tried 411 times, ubuntu 342 times and user 206 times. Then give it sudo:

adduser maria
usermod -aG sudo maria

Give your user the key

If you already log in as root with a key, copy it across. If you log in with a password, run ssh-copy-id maria@your-server-ip from a Mac or Linux computer instead. Windows has no ssh-copy-id; use the one-line PowerShell copy from our tutorial.

install -d -m 700 -o maria -g maria /home/maria/.ssh
cp /root/.ssh/authorized_keys /home/maria/.ssh/
chown maria:maria /home/maria/.ssh/authorized_keys
chmod 600 /home/maria/.ssh/authorized_keys

Test gate 1

Open a new terminal on your computer. Keep the old one open. Then:

ssh maria@your-server-ip
sudo whoami

If it prints root, you have a working way in that doesn’t need root or a password. If it doesn’t, stop here and fix it from your first session.

Don’t edit the main SSH config file. Create your own small file instead:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers maria
EOF

Why the “00-” in the name? Ubuntu’s main config reads every file in that folder, in alphabetical order. And for SSH, the first value it reads for a setting is the one it uses. A file starting with 00 is read first, so your settings win over anything another tool drops in later.

Now check before you apply. This one command catches typos that would stop SSH from starting:

sudo sshd -t

No output means no errors. Then apply it:

sudo systemctl restart ssh

And confirm what SSH is really using, after every file has been read:

sudo sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowusers) '

Test gate 2

New terminal again. Your key should get you in. Root should be refused:

ssh maria@your-server-ip
ssh root@your-server-ip

The second one must fail with Permission denied (publickey). If both behave, you can finally close that first session.

Want a safety net that undoes a bad change by itself, and a checker for your live settings? Our SSH hardening tutorial has both, with the before-and-after numbers from our own server.

Ubuntu 24.04 vs 22.04: the change most guides miss

Since Ubuntu 22.10, SSH starts through systemd socket activation. For most settings nothing changes. For the port, it does:

Should you change the SSH port?

It’s optional. A new port makes your logs much quieter, because most bots only knock on port 22. It doesn’t stop anyone who scans properly. Keys stop attackers. A port change just stops noise. If you do it, allow the new port in the firewall first, test it, and only then close 22. The generator in Chapter 2 does this in the right order.

Ubuntu’s firewall tool is ufw, and it starts out disabled. Set it up in this order:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable

Only add the web line if the server runs websites. When ufw warns that enabling it may disrupt SSH, answer y. You already allowed port 22, so your session survives.

Check the result:

sudo ufw status verbose

On LiteKeep, DDoS filtering at the network edge is included with every Lite. Floods are dealt with before they reach your server, so ufw only has to decide which doors are open.

We read the logs of one of our own servers from the moment it first booted. No addresses were kept, just counts.

Look at the usernames. admin, ubuntu, user, test, postgres. These bots don’t know anything about you. They try the same list on every server on the internet.

That’s exactly why the steps in this guide work so well. With passwords off, every one of those 14,526 guesses was guaranteed to fail.

So why add fail2ban?

fail2ban watches your logs and blocks addresses that keep failing. It doesn’t make weak passwords safe. What it does is cut the noise.

On our server, after we switched fail2ban on, failed attempts in the log fell from an average of 324 an hour to 23. You can see the drop in the chart at the top of this guide.

sudo apt install -y fail2ban python3-systemd
sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
EOF
sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban

Back up somewhere else

A snapshot lives with your server. If the account, the location or the disk has a bad day, so does the snapshot. A real backup lives somewhere else: another server, ideally in another country. A Vault in a second location works well for this.

And a backup you’ve never restored is a hope, not a backup. Once a month, restore one file. Once a quarter, restore the whole thing to a test server.

Check your work

Run through this list after hardening, and again whenever you change something:

If you get locked out

Open your server’s web console in your LiteKeep account, log in, and undo the last change. Removing your SSH file and restarting puts SSH back to its defaults:

rm /etc/ssh/sshd_config.d/00-hardening.conf
systemctl restart ssh
ufw disable

Fix the mistake, then go through the steps again, testing as you go.

If you think you’ve been hacked

Don’t try to clean a compromised server. You can’t be sure you found everything.

1. Cut it off. Stop the server or block its traffic, but keep the disk for evidence.
2. Change every secret it held. SSH keys, API keys, database and hosting passwords.
3. Build a fresh server and harden it with this guide before anything else.
4. Restore your data from a backup made before the break-in.
5. Find the way in so it doesn’t happen twice.

Quick answers

How long does all this take? About 30 minutes the first time, less with the generator.

Does a VPS come with a firewall? LiteKeep filters DDoS traffic at the network edge on every Lite. That stops floods, not logins, so set up ufw yourself too.

Is a VPS more secure than shared hosting? It can be, because nobody else runs code on your system. But you’re responsible for the security, which is what this guide is for.