The first 10 security steps on a new VPS

On a new VPS, the first jobs are to update the system, create a separate user that logs in with a key instead of root, turn off password login, switch on the firewall and fail2ban, enable automatic security updates, and check that your backups work. Below are the 10 steps in the order you should do them. The commands are for Ubuntu and Debian.

Every server on the internet is a target for automated scans and password-guessing bots, and you can see this in your own SSH log. The order matters: confirm that steps 2 and 3 work before you do step 4, or you can lock yourself out. The sudo in the commands also works if you are logged in as root.

System and accounts

1. Update the system

sudo apt update && sudo apt upgrade -y

On Ubuntu, the file /var/run/reboot-required appears when an update needs a restart. If it does, restart the server once. Debian may not create this file, so restart after a kernel update anyway.

2. Create your own user

Don't use root for daily work. Create a separate user with sudo rights. Replace deploy with any name you like:

sudo adduser deploy

sudo usermod -aG sudo deploy

3. Log in with an SSH key

If your computer has no key pair yet, create one with ssh-keygen -t ed25519. Then copy the public key to the new user and test the login:

ssh-copy-id [email protected]

ssh [email protected]

If you got in without a password prompt, you are ready. Windows has no ssh-copy-id. In PowerShell, this command does the same job:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Harden SSH

4. Turn off password and root login

First confirm that you can log in as the new user with your key. Then find out which files define these settings. When OpenSSH finds the same setting in several places, it uses the first value it reads. On Debian and Ubuntu the main configuration file includes the /etc/ssh/sshd_config.d/ folder at the very top. Provider images may leave a file in that folder that turns password login on. Even if you write no in the main file, the yes in that file stays in force:

sudo grep -rniE "^\s*(PasswordAuthentication|PermitRootLogin|KbdInteractiveAuthentication)" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Set every active line in the output to no in the file where it appears: PasswordAuthentication no, PermitRootLogin no, KbdInteractiveAuthentication no. Append any setting that doesn't show up in the output to the end of /etc/ssh/sshd_config. Then test, apply and check the values that are actually in effect:

sudo sshd -t && sudo systemctl reload ssh

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

All three lines should end in no. Don't close your open session. Open a new terminal and make sure the key login works before you leave. If you still lock yourself out, open the VNC Console from the panel. Console login isn't affected by SSH settings.

These settings can quietly go back later. Actions in the provider's panel, such as adding an SSH key or resetting the password, can make the provider's first-boot script (cloud-init) run again at the next boot, and that script may turn password login back on. After any such action, run the sshd -T command above again and check the values.

Narrow down outside access

5. Turn on the firewall

In ufw, allow SSH first and enable the firewall second. Do it the other way round and your connection drops. If SSH runs on a port other than 22, use that port instead of 22:

sudo ufw allow 22/tcp

sudo ufw enable

sudo ufw status verbose

If you will run a web server, also allow ports 80 and 443. By default ufw rejects incoming connections. The panel also has a firewall tool. If you use Docker, be careful: according to Docker's documentation, ports you publish bypass ufw rules. For services that only the server itself needs to reach, publish the port on the loopback address only, for example 127.0.0.1:5432:5432 in a Docker Compose file.

6. Install fail2ban

fail2ban blocks IP addresses that keep failing to log in, for a while:

sudo apt install -y fail2ban python3-systemd

printf '[sshd]\nenabled = true\nbackend = systemd\nmaxretry = 5\nbantime = 1h\n' | sudo tee /etc/fail2ban/jail.local

sudo systemctl enable fail2ban && sudo systemctl restart fail2ban

sudo fail2ban-client status sshd

On Seturack's one-click app servers, ufw is on and fail2ban runs. If you installed a clean operating system, check their state with sudo ufw status and systemctl is-active fail2ban.

7. Review open ports

sudo ss -tulpn

The command lists every listening service and port. Services that don't need outside access, such as databases and caches, should listen on 127.0.0.1 only. Shut down what you don't need: sudo systemctl disable --now service-name

Keeping it that way

8. Automate security updates

According to Ubuntu's documentation, the unattended-upgrades package normally comes preinstalled and security updates are on. If it is missing, install and enable it:

sudo apt install -y unattended-upgrades

sudo dpkg-reconfigure -plow unattended-upgrades

Automatic reboot is off by default, so restart the server yourself after kernel updates. Under the terms of service, keeping the system updated after setup is your responsibility.

9. Take backups and test a restore

At Seturack, your server is backed up every night and the last 7 days are kept. This is included in the price. On the Management tab, open Backups to see them, recover a single file or restore the whole server. To test a restore, recover a single file: restoring the whole server replaces the entire current disk. Taking a snapshot before a big change is a good habit, but a snapshot is not a backup. Keep a copy of your important data outside the server too. For details, see the daily backups article.

10. Strengthen your passwords

Your panel account is the key to the server. Use a long password there that you use nowhere else, and keep it in a password manager. Change the first root password you copied from the panel with sudo passwd root. Put a passphrase on your SSH private key. Never paste passwords or keys into support messages or chats.