VPS Security Checklist: First Setup Steps

The clock starts the moment you get a new VPS: any server exposed to the internet meets automated bot scans within minutes of going live. A solid vps security foundation is laid in those first few hours, before you install a single application on top. In this article I share the checklist I go through, in order, when preparing a fresh Ubuntu/Debian server for production: a privileged user, SSH hardening, a firewall, fail2ban, automatic security updates, and a few essential good habits.

1. First login and system update

Your provider usually hands you a root password or an SSH key. The very first job is to refresh the package list and upgrade installed packages. Old packages ship with known vulnerabilities; updating is the cheapest security win there is.

apt update && apt upgrade -y

If a kernel or library update came down, reboot the server once: reboot. This is also a good moment to set your timezone and hostname.

2. Create a privileged (sudo) user instead of root

Doing everything as root means a single wrong command or a hijacked session can take down the whole system. Create your own user and add it to the sudo group:

adduser aslain
usermod -aG sudo aslain

Switch to the new user and run sudo whoami to confirm the privileges. From now on you will do daily work as this user, and shortly we will disable direct root login entirely.

3. Use an SSH key, drop the password

Password-based login is an open door to brute-force attacks. Use an SSH key pair instead. If you do not have a key on your own machine, generate one:

ssh-keygen -t ed25519 -C "aslain@laptop"

Copy the public key to the server:

ssh-copy-id aslain@SERVER_IP

If you can now log in with ssh aslain@SERVER_IP without being asked for a password, the key works. Do not disable password login until you have verified key-based access, or you may lock yourself out.

4. Harden the SSH configuration

SSH hardening is one of the highest-return steps on the vps security side. Edit /etc/ssh/sshd_config (or a separate file under /etc/ssh/sshd_config.d/):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

In order, these settings: block direct root login, disable password authentication entirely, and allow key-only access. After the change, restart the service:

systemctl restart ssh

Important tip: open a new terminal and try to reconnect, but keep the existing session open. If you made a mistake, the open session lets you go back and fix it. Changing the default port 22 is security by obscurity; it offers no real protection but does cut down log noise — you can do it if you like, but it is no substitute for a firewall and key login.

5. Set up a firewall and open only the ports you need

On Ubuntu/Debian the most practical tool is ufw (Uncomplicated Firewall). The logic is simple: deny everything, allow only what you need.

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable

If you will run a web server, open HTTP and HTTPS too:

ufw allow 80/tcp
ufw allow 443/tcp

Check the state with ufw status verbose. Careful: make sure the SSH rule is in place before you enable the firewall, otherwise you will lock yourself out.

6. Block automated attacks with fail2ban

Even after switching to key login, your logs fill up with failed login attempts. fail2ban temporarily bans an IP after a set number of failures:

apt install fail2ban -y
systemctl enable --now fail2ban

The defaults give reasonable SSH protection. To customise, create a /etc/fail2ban/jail.local file (do not edit jail.conf itself — it gets overwritten on update):

[sshd]
enabled = true
maxretry = 4
bantime = 1h

You can view banned IPs with fail2ban-client status sshd.

7. Enable automatic security updates

People forget to update; automation does not. Use unattended-upgrades to apply security patches on their own:

apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgrades

By default this package installs only updates from the security repositories, so you avoid unexpected major version jumps. Even so, on critical systems you should still review updates periodically yourself.

8. A few essential good habits

• Time sync: run timedatectl set-ntp true to keep the clock accurate; it matters for certificates and logs.
• Least privilege: run services under their own limited users, not root.
• Backups: security is not only about blocking attacks but about recovering on a bad day. Do not skip your provider's snapshot feature and regular data backups.
• Monitoring: glance at login records now and then with journalctl and last.

Once these steps become a habit, putting a new server on a secure footing takes less than half an hour.

Frequently Asked Questions

Do I need to change the SSH port from 22?

It is not required. Changing the port reduces automated log noise but is not a real security layer. The genuine protection is key-based login, disabled password authentication, and a firewall; a port change does not replace those.

What happens if I disable password login and lose my key?

You are locked out of the server entirely. So back up your key safely and learn the web-based console (VNC/recovery) access most providers offer; from there you can log in and add a new key.

Do fail2ban and the firewall do the same job?

No. The firewall decides which ports are open; fail2ban detects repeated malicious behaviour (such as failed logins) hitting those open ports and temporarily bans the offending IP. The two complement each other.

Need help setting up a server? I help with Linux server hardening, game/web server setups, and DevOps work. To talk through your project, get in touch.