How to Secure a New VPS: A 10-Step Beginner Checklist

Q: I set PasswordAuthentication no, but password logins still work. Why?

On Ubuntu cloud images, a file in /etc/ssh/sshd_config.d/ (often 50-cloud-init.conf) can set it back to yes, and sshd uses the first value it reads. Put your settings in a file named 00-something.conf and confirm with 'sudo sshd -T'.

Q: Does ufw protect Docker containers?

Not by itself. Ports that Docker publishes bypass ufw rules. Bind container ports to 127.0.0.1 (for example 127.0.0.1:3000:8080) and publish them through a reverse proxy such as nginx.

Last updated: 2026-09-24 · By Ovanap Team, authors of Linux from Zero (published by Ovanap, Monine AS)

The short answer: to secure a new Ubuntu VPS, log in with an SSH key, create a regular user with sudo, allow SSH in the ufw firewall before enabling it, then turn off root and password logins in a file under /etc/ssh/sshd_config.d/. Keep automatic security updates on. Do it in that order, with a second SSH session open the whole time, and keep your provider’s web console as the way back.

Key facts

sshd uses the first value it reads for most settings, and Include files are processed in lexical order. That is why a 00- file beats a cloud-init file named 50-… (sshd_config manual).
Ports that Docker publishes bypass ufw. Docker’s documentation says traffic to published container ports “gets diverted before it goes through the ufw firewall settings” (Docker docs).
Ubuntu installs unattended-upgrades by default, and it applies security updates automatically (Ubuntu Server docs).
Ubuntu 26.04 uses sudo-rs as its default sudo (release notes), so the password prompt looks different.
A web console at your provider works even when SSH and the firewall are broken. Treat it as a must-have when choosing a VPS.

A VPS (virtual private server) is a virtual machine you rent in a data center, with its own public IP address and full control for you. A new VPS is reachable from the whole internet within a minute of being created, and automated bots start trying to log in within hours, usually as root. The good news: the protection a beginner needs is short, well understood, and free.

The catch is order. Every step below is simple, but doing two of them the wrong way round is how people lock themselves out of their own server. So this checklist is written for Ubuntu Server 26.04 LTS in the order that keeps a way back open at every step.

Throughout, the server’s address is 203.0.113.10 (a range reserved for documentation) and your new user is admin. Substitute your own.

The golden rule: two sessions, always

Until you finish, keep two SSH sessions open in two terminal windows. Work in one; leave the other alone as an emergency exit. Never close your last working login until you have confirmed, in a new window, that logging in still works.

Step 1: Choose a provider with a web console

Before you pay, check five things: a data center near you and your visitors, the price, backups, an Ubuntu 26.04 LTS image, and a web console. The console is your server’s screen and keyboard in the browser. It works even when SSH and the firewall are broken, which makes it your safety net for everything below. A provider without one is not suitable for a beginner.

A 1–2 GB RAM, 1-core plan is enough to start. We keep a VPS provider comparison with what we could verify in official documentation.

Step 2: Add your SSH public key when creating the server

An SSH key pair is two files: a private key that never leaves your computer and a public key you give to servers so they recognize you. Create a key pair on your own computer if you don’t have one yet (ssh-keygen -t ed25519), then print the public half:

cat ~/.ssh/id_ed25519.pub

Paste that single line, starting with ssh-ed25519, into the provider’s “SSH key” field. Only the file ending in .pub ever leaves your computer. If a form asks for your private key, stop: that should never happen.

ssh root@203.0.113.10

On the first connection, SSH shows the server’s fingerprint. If your provider’s panel shows one, compare them before typing yes. Then look around: whoami, hostname, ls /home. This is the last time you need root directly.

Step 4: Create a regular user with sudo

sudo adduser admin
sudo usermod -aG sudo admin

Pick a strong password: you will need it for sudo and for the web console. Note the lowercase -a (“append”): without it, usermod -G replaces all the user’s groups instead of adding one, a classic mistake.

Step 5: Test the new user in a second window

Leave the root window open. In a new terminal:

ssh admin@203.0.113.10
sudo whoami

The answer must be root. Ubuntu 26.04 uses sudo-rs, so the password prompt looks like [sudo: authenticate] Password:; that is expected. If you get a refusal instead, fix the group from the root window, then log out and back in.

If this login fails with Permission denied (publickey), your provider has already disabled password logins. Not your mistake: do this check in the web console instead, and use the alternative in the next step.

Step 6: Give the new user your key

From your own computer:

ssh-copy-id admin@203.0.113.10

If passwords are already off, copy the key from the root session that is still open:

sudo mkdir -p /home/admin/.ssh
sudo cp /root/.ssh/authorized_keys /home/admin/.ssh/
sudo chown -R admin:admin /home/admin/.ssh

Now ssh admin@203.0.113.10 from a new window must log you in without any password prompt. Don’t go on until you have seen that.

Step 7: Firewall, with SSH allowed first

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

A firewall decides which incoming connections are let in; ufw (“uncomplicated firewall”) is Ubuntu’s simple tool for managing it. The order is the whole point. enable without the SSH rule blocks all new incoming connections, including yours. Answer y to the warning about disrupting SSH. The status should show Status: active, Default: deny (incoming), allow (outgoing), and one rule: 22/tcp (OpenSSH) ALLOW IN Anywhere. (If ufw is missing on a slimmed-down image, install it with sudo apt install ufw.)

Then, golden rule: log in from a new window before going further.

Step 8: Close root and password logins in SSH

This is where copy-pasted guides most often fail silently. Ubuntu’s main /etc/ssh/sshd_config includes every .conf file from /etc/ssh/sshd_config.d/, and the first value sshd reads wins. Cloud images often contain 50-cloud-init.conf; if it says PasswordAuthentication yes, editing the main file changes nothing. So write your own file that is read first:

ls /etc/ssh/sshd_config.d/
sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Put these two lines in it, save with Ctrl+O, Enter, and exit with Ctrl+X:

PermitRootLogin no
PasswordAuthentication no

Check the syntax, apply, and confirm the values actually in effect:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'

sshd -t stays silent when the syntax is correct. The last command must print permitrootlogin no and passwordauthentication no. Note the service name: on Ubuntu it is ssh, not sshd.

Final test, with both old windows still open: ssh root@203.0.113.10 must be refused with Permission denied (publickey), and ssh admin@203.0.113.10 must let you in with your key. “Root refused, admin let in”: now you can close the root window.

Step 9: Automatic security updates

sudo apt install unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Both lines should end in "1". If the file is missing or shows "0", run sudo dpkg-reconfigure -plow unattended-upgrades and answer Yes. On many Ubuntu images the package is already installed, and apt will simply say so.

Step 10: Plan the way back before you need it

Know your recovery path. Locked out after ufw enable? Web console → sudo ufw allow OpenSSH. SSH broken after an edit? Web console → comment out the lines in 00-hardening.conf with #, then sudo sshd -t and sudo systemctl reload ssh. Lost your private key? Web console → paste a new public key into /home/admin/.ssh/authorized_keys.
Turn on backups at the provider as a first layer, then add your own copy “elsewhere” and test it by restoring. Options and an encrypted example are in our backups appendix.
If you add Docker later: ports that Docker publishes bypass ufw. Always bind them to localhost, like "127.0.0.1:3000:8080", and publish through nginx. Current install lines are in the Docker appendix.

A word on “change the SSH port”

It is popular advice, and it is optional. Key-only login is what actually stops password guessing. If you do change it on Ubuntu 26.04, old instructions (Port 2222 plus systemctl restart sshd) will fail: the service is ssh, and the port is managed by ssh.socket. You would need sudo ufw allow 2222/tcp first, then sudo systemctl daemon-reload and sudo systemctl restart ssh.socket, and a test with ssh -p 2222 admin@203.0.113.10 while the old window stays open. The broader lesson: check which system any guide was written for before you run it.

Frequently asked questions

What is the first thing to do on a new VPS? Create a regular user with sudo rights and make sure you can log in as that user with your SSH key, keeping your first session open. Only then turn on the firewall and close root and password logins.

Why did ufw lock me out of my server? Almost always because ufw was enabled before SSH was allowed. If you are locked out, log in through your provider’s web console and run sudo ufw allow OpenSSH.

I set PasswordAuthentication no, but password logins still work. Why? A file in /etc/ssh/sshd_config.d/ (often 50-cloud-init.conf) can set it back to yes, and sshd uses the first value it reads. Use a 00- file and confirm with sudo sshd -T.

Should I change the SSH port? It is optional and does not replace key-only logins. On Ubuntu 26.04 it involves ssh.socket, so follow up-to-date instructions and allow the new port in ufw first.

Does ufw protect Docker containers? Not by itself. Docker-published ports bypass ufw. Bind them to 127.0.0.1 and use a reverse proxy.

From a safe server to a useful one

This checklist condenses one chapter of Linux from Zero. In the book it is a full lab, with every command explained (what it does, why, what changes, how to check it, and the risk) and a recovery path for each mistake. From there the book continues to a website with your own domain and HTTPS, tested backups, Docker, and your own AI assistant on the same server, which we cover in Run your own AI assistant on a VPS.

Try the free sample first (introduction plus the full terminal chapter, no sign-up). If it fits the way you learn, the book is here.