Securing a new VPS: a step-by-step checklist

You'll go through a checklist that turns a new VPS into a secure server: updates, strong passwords, your own user, an SSH key, a firewall, fail2ban and automatic security patches. For each step we explain why to do it and exactly what you're setting.

Why right after creation#

Every public IP address is visible from the whole internet. Automated bots scan addresses and try to log in over SSH with common names and passwords. On a new VPS you'll often see the first attempts within a few minutes. Try it:

journalctl -u ssh --since "1 hour ago" | grep -E "Failed password|Invalid user"

• journalctl -u ssh – prints the SSH service entries.
• --since "1 hour ago" – only from the last hour.
• grep -E "…" – keeps only lines with a failed login or a non-existent user.

We block known internet scanners on the network, but that doesn't stop every attempt. A strong password, an SSH key and fail2ban protect you against the rest.

Checklist#

Security and the customer area#

The Files and Database tabs in the customer area connect to the VPS over SSH, using a user name and password (by default root and the password from when the VPS was created). Some steps in this guide therefore affect them:

Only the service owner can change the credentials in the Files tab. The Console and the Network, Firewall, Backups and Change plan tabs always work; VPS settings don't affect them. Decide what matters more to you. Turning off password login gives the highest security. If you use the Files and Database tabs, keep the password on but strong, and install fail2ban.

Updating the system#

1. Download the list of available updates:

   apt update

   • apt update – loads the list of new package versions from the repositories. It doesn't install anything by itself.

2. Install all updates:

   apt full-upgrade -y

   • apt full-upgrade – updates packages and may add or remove dependencies to do so (a new kernel, for example).
   • -y – automatically answer “yes” to the confirmation.

3. If the installation asks about a configuration file (for example /etc/ssh/sshd_config “has been locally modified”), choose keep the local version currently installed. This keeps the current settings the VPS works with.

4. Find out whether a restart is needed:

   ls /var/run/reboot-required

   If the command finds the file, restart. On Debian without the unattended-upgrades package the file may not be created, so there always restart after a kernel update (a package starting with linux-image).

5. Restart the VPS:

   reboot

   The SSH connection closes. Connect again after about a minute.

Changing the root password#

You saw the password from when the VPS was created in the customer area, or in an email. Set a new one that only you know.

1. Generate a strong password, for example with the password generator (at least 20 characters), and save it in your password manager.

2. Start the password change:

   passwd

   • passwd – with no other parameter, changes the password of the user running the command (that is, root).

3. At the New password: prompt, paste the new password and press Enter. The password doesn't show.

4. At the Retype new password: prompt, paste it again. You'll see passwd: password updated successfully.

5. Don't close the current window. Open a new one and test logging in with the new password.

6. In the customer area, open the Files tab, click Change credentials, fill in User root, Port 22 and the new Password, and click Verify and save.

A new user with sudo#

As root, every typo in a command affects the whole system. For everyday work, create your own user who requests administrator rights only with the sudo command. As an example we'll use the name jan.

1. Create the user:

   adduser jan

   • adduser – creates the user and their home folder /home/jan and asks for a password.

   Enter a password twice (different from the root password). Skip the questions about name, phone and other details with Enter and confirm with Y at the end.

2. Add the user to the sudo group:

   usermod -aG sudo jan

   • usermod – changes a user's properties.
   • -aG sudo – adds (-a) the user to an additional group (-G) sudo. Without -a the user would drop out of all other groups.
   • Members of the sudo group can run commands as root.

3. If you already have an SSH key for root, copy it to the new user too:

   install -d -m 700 -o jan -g jan /home/jan/.ssh
   install -m 600 -o jan -g jan /root/.ssh/authorized_keys /home/jan/.ssh/authorized_keys

   • install -d – creates the .ssh folder.
   • -m 700 / -m 600 – permissions: the folder only for the owner, the file read and write only for the owner. SSH rejects other permissions.
   • -o jan -g jan – the owner will be the user jan.

4. In a new window, log in as the new user and test sudo:

   ssh [email protected]
   sudo whoami

   • sudo whoami – runs the whoami command as root. After you enter the password of the user jan, it must print root.

If the adduser or sudo command is missing (minimal Debian installation), install them: apt install adduser sudo.

SSH key and turning off password login#

This is the most important step. A password can be guessed; an SSH key practically can't. The steps for Windows, macOS and Linux are in a separate guide, SSH key: log in without a password, including safely turning off password login.

Disabling root login#

When root isn't allowed over SSH, an attacker also has to know your user's name. Do this only once you can log in as the new user and sudo works for you.

1. Open (or create) your own SSH server configuration file:

   nano /etc/ssh/sshd_config.d/00-zabezpeceni.conf

2. Add the line:

   PermitRootLogin no

   Setting	What it does	Recommended value	When to change
   PermitRootLogin	Whether root can log in over SSH. no = not at all, prohibit-password = only with a key, yes = with a password too.	no	prohibit-password, if you need root access with a key (for a backup script, for example).

   The file name starts with 00 so that it loads first. The SSH server uses the first value it finds for each setting.

3. Check the configuration and the effective value:

   sshd -t && sshd -T | grep -i permitrootlogin

   • sshd -t – syntax check. On an error it prints the file and line.
   • && – the next command runs only if the previous one finished without an error.
   • sshd -T – prints the resulting effective configuration. It must contain permitrootlogin no.

4. Restart the SSH server:

   systemctl restart ssh

   The current connection stays open.

5. In a new window, check that ssh [email protected] no longer logs in and ssh [email protected] does.

You then work as root through sudo -i (opens a root command prompt after you enter the password of the user jan).

Changing the SSH port#

Moving SSH from port 22 to another port is not real security; an attacker will find the new port. But it does cut the bot attempts in the log considerably.

Pros:

• Fewer automated login attempts and cleaner logs.

Cons:

• You have to give the port every time you connect (ssh -p 2222 …).
• Some company and public networks block non-standard ports.
• You have to update the port in the firewall, in fail2ban and in the customer area (Files).

If you decide to change it, choose a port above 1024 that no other application uses (avoid, for example, port 2022, which some game panels use for SFTP). In the example we'll use 2222.

1. Allow the new port in the firewall before you move SSH: in the Firewall tab, add an Inbound, Allow, TCP rule for port 2222 (required in the Block everything except allowed mode, harmless in Allow everything), and if you use UFW, run ufw allow 2222/tcp.

2. Add two lines to the file /etc/ssh/sshd_config.d/00-zabezpeceni.conf. Keep the old port for now so the change doesn't lock you out:

   Port 22
   Port 2222

   • Port – the port the SSH server listens on. There can be several Port lines; the server then listens on all of them.

3. Check the configuration: sshd -t.

4. Find out how SSH starts on your VPS:

   systemctl is-active ssh.socket

   The result active means systemd starts SSH through a socket (the default on Ubuntu 24.04). The result inactive means a regular service (usually Debian 13).

Apply the new port according to the result:

5. Check that SSH listens on both ports: ss -tlnp | grep -E ':22 |:2222 '.
6. In a new window, connect through the new port: ssh -p 2222 [email protected].
7. When the connection through the new port works, delete the Port 22 line from the configuration.
8. Check the configuration: sshd -t.
9. Load the change with the same command as above (depending on whether the socket is active).
10. In the customer area, open Files › Change credentials and enter port 2222. The Files and Database tabs connect to the VPS over SSH and would stop working without the new port.
11. Update the port in the sshd jail in fail2ban (see Fail2ban).
12. Delete the rule for port 22 in the firewall.

Firewall and fail2ban#

• The firewall in the customer area filters traffic before it reaches the VPS and you set it up by clicking: Firewall in the customer area.
• UFW is a firewall right inside the VPS: UFW firewall.
• Fail2ban watches failed logins and blocks attackers: Fail2ban.

One firewall is enough. For beginners we recommend the firewall in the customer area, because you can fix it even if you lock yourself out.

Automatic security updates#

The unattended-upgrades package installs security updates once a day. On Ubuntu it's installed and turned on; on Debian you turn it on.

By default, Ubuntu installs only security updates; Debian installs security updates and fixes from point releases of the stable version (for example 13.1, 13.2). The VPS doesn't restart by itself. You change the behavior in your own file that overrides the default 50unattended-upgrades (don't edit that one; a package update could overwrite it):

nano /etc/apt/apt.conf.d/52unattended-upgrades-local

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Try the settings in a dry run:

unattended-upgrade --dry-run --debug

• --dry-run – a simulation only; nothing gets installed.
• --debug – detailed output, including the loaded settings and the packages that would be updated.

Records of actual updates are in the /var/log/unattended-upgrades/ folder.

Time zone and server name#

1. Set the time zone so the times in logs match (the example uses Czech time):

   timedatectl set-timezone Europe/Prague

   • timedatectl – sets the system time and time zone.
   • set-timezone Europe/Prague – Central European Time, including daylight saving time.

2. Check the result with timedatectl. The Time zone line must show Europe/Prague and System clock synchronized: yes.

3. Optionally change the server name (hostname):

   hostnamectl set-hostname vps1

   • hostnamectl set-hostname vps1 – sets the VPS name to vps1. Use lowercase letters, digits and hyphens.

   The new name shows in the command prompt after you log in again. If sudo starts printing unable to resolve host vps1, add the name to /etc/hosts on the 127.0.1.1 line. If the file's header says it's generated automatically, follow the instructions in the header.

What next#

• Backups: we back up the whole VPS and you can restore it in the Backups tab. Back up important data outside the VPS too, see VPS backups.
• Overview: now and then, check the disk space (df -h), running services (systemctl --failed) and fail2ban records.
• Only the services you need: don't install what you don't need. Every open port is another possible way in.

Verification#

• apt update after updating prints All packages are up to date.
• The new root password works and the Files tab logs in.
• The user jan logs in over SSH and sudo whoami prints root.
• sshd -T | grep -E "^(permitrootlogin|passwordauthentication|port) " shows the values you set.
• unattended-upgrade --dry-run --debug runs without an error.

Troubleshooting#

You locked yourself out of SSH#

Use the browser console. You log in with the root password (even if root is disabled over SSH) and fix the mistake, for example by deleting the file /etc/ssh/sshd_config.d/00-zabezpeceni.conf and restarting SSH with systemctl restart ssh.

sudo: jan is not in the sudoers file#

The user isn't in the sudo group. As root, run usermod -aG sudo jan; the user must log out and back in for the group to take effect.

The Files tab says signing in to the VPS failed#

The customer area is using old credentials. Open Files › Change credentials and enter the current user, port and password. If you have password login turned off or SSH allowed only from your IP address, the tab won't work (see the table in the Security and the customer area section).

sshd -T shows a different value than you set#

The same setting is in another file that loads earlier (the SSH server takes the first value it finds). Find it:

grep -rni "permitrootlogin" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

• grep -rni – searches for text in all files of a folder (-r), ignoring case (-i), and prints the line number (-n).

Comment out the line in the other file (put # at its start), or change the value right there. Then run sshd -t && sshd -T | grep -i permitrootlogin again and restart SSH.

After a port change, SSH still listens only on port 22#

On Ubuntu 24.04 you most likely skipped systemctl daemon-reload. Run it and then systemctl restart ssh.socket.

E: Could not get lock /var/lib/dpkg/lock-frontend#

Another installation is running in the background, typically automatic updates (on a new VPS after the first boot). Wait a few minutes and run the command again. Don't kill the process.

Further reading#

• Ubuntu: OpenSSH server (opens in a new window)
• Ubuntu: automatic updates (opens in a new window)
• Debian Wiki: UnattendedUpgrades (opens in a new window)
• sshd_config manual page (opens in a new window)