Secure your Linux VPS: the 6 essential steps

A server exposed on the Internet receives connection attempts within minutes of going online. This guide applies the six basic protections to an Ubuntu VPS, in fifteen minutes. Every command was run on Ubuntu 26.04.1 LTS on September 27, 2026, in a test environment and then on a QuantylCloud VPS; they also work on Ubuntu 24.04 LTS.

Before you start

Two firewalls, which complement each other. Every QuantylCloud server is created behind a network firewall that blocks all incoming connections except SSH (port 22). You set it in the Firewall tab of the server's page. This guide adds a second firewall, ufw, on the machine itself: if one is misconfigured, the other still holds. A port to open, for example 80 and 443 for a website, must therefore be opened in both places.

Keep a way back in. During steps 3 to 5, leave your SSH session open and test each change from a second terminal. If you find yourself locked out, the Rescue console on the server's page connects you to the machine without going through SSH.

Step 1 — Install the updates

Logged in as root, start with the pending security fixes:

apt update && apt upgrade -y

Step 2 — Create an administration user

Working as root all the time means giving full rights to the slightest mistake. Create a user who will go through sudo. Pick your own name: gestion is used as an example. Avoid admin: on Ubuntu images, a system group already has that name and adduser refuses to create the user. The adduser command asks you for a password: it will be used for sudo, not for logging in.

adduser gestion
usermod -aG sudo gestion

Give it the SSH key already authorized for root:

mkdir -p /home/gestion/.ssh
cp /root/.ssh/authorized_keys /home/gestion/.ssh/
chown -R gestion:gestion /home/gestion/.ssh
chmod 700 /home/gestion/.ssh
chmod 600 /home/gestion/.ssh/authorized_keys

Did you order the server without an SSH key? Create one (see Create a VPS in Morocco, step 5), then, from your computer, send it with ssh-copy-id gestion@ADRESSE_IP, which asks for the password one last time.

From a second terminal, check that logging in and sudo work:

ssh gestion@ADRESSE_IP
sudo whoami

The answer must be root. Do not move on until it is: the next step closes root access.

Step 3 — Close root and passwords in SSH

Now logged in as gestion, forbid direct root login and any password authentication, which is what bots target:

printf 'PermitRootLogin no\nPasswordAuthentication no\nKbdInteractiveAuthentication no\n' | sudo tee /etc/ssh/sshd_config.d/00-durcissement.conf
sudo sshd -t
sudo systemctl reload ssh

The file name matters. SSH keeps the first value it reads, and reads the files in /etc/ssh/sshd_config.d/ in alphabetical order. On many images, a 50-cloud-init.conf file allows passwords: a file named 99-… would be read after it, and ignored. We saw this in testing. The 00- prefix comes first.

Check the effective configuration:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication) '

Both lines must end with no. Then open a new connection ssh gestion@ADRESSE_IP from another terminal before closing the current session.

Step 4 — Enable the ufw firewall

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

ufw enable warns that the operation may cut SSH connections: answer y. The OpenSSH rule, added just before, keeps your access. Check:

sudo ufw status verbose

Only port 22 must appear as ALLOW IN. Later, for a website, you will add sudo ufw allow 80,443/tcp, and the same ports in the Firewall tab of the console.

Step 5 — Ban brute-force attacks with fail2ban

fail2ban reads the SSH logs and blocks for a while an address that accumulates failed logins.

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

On Ubuntu, SSH protection is active as soon as it is installed: five failures in ten minutes earn a ten-minute ban. In testing, a series of failed attempts did get the attacking address banned, and every connection from that address, legitimate ones included, was refused until the ban was lifted.

If you ban yourself, for example after several tries with the wrong key, wait ten minutes, or open the Rescue console and lift the ban:

sudo fail2ban-client set sshd unbanip VOTRE_ADRESSE_IP

Step 6 — Install security updates automatically

sudo apt install -y unattended-upgrades
printf 'APT::Periodic::Update-Package-Lists "1";\nAPT::Periodic::Unattended-Upgrade "1";\n' | sudo tee /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run

The server now installs Ubuntu's security fixes every day. We write the file directly rather than going through dpkg-reconfigure, which does not recreate it if it has been deleted. The server does not reboot by itself: after a kernel update, the /var/run/reboot-required file appears, and it is up to you to choose when to reboot.

Summary

• pending fixes installed;
• an administration user with sudo, and no more root login;
• SSH by key only, checked with sshd -T;
• two firewalls: the console's and ufw, with only SSH open;
• fail2ban against brute force;
• daily security updates.

These protections do not replace backups: enable the daily backup option from the server's page, or keep your own.