Secure Your VPS: A First-10-Minutes Checklist

Written by the ApexVPS team • Last updated: July 2026 • 9 min read

A fresh Linux VPS is probed by automated bots within minutes of coming online, so the smartest first move is to run through a short, repeatable secure a VPS checklist before you install anything else. This guide is that checklist: a practical, first-10-minutes routine you can follow on any new Ubuntu or Debian server to create a non-root user, lock down SSH, switch on a firewall, and shut the door on brute-force logins. Every command below is standard and safe to copy, and none of it needs special tooling — just your terminal and a few minutes.

Work through the steps in order. Each one builds on the last, and by the end you will have a server that is dramatically harder to break into than the default image you started with.

Why the rush? Public IPv4 space is scanned continuously. Search engines for internet-connected devices, along with countless botnets, catalogue new hosts and try default credentials around the clock. The gap between "server is live" and "server is being attacked" is measured in minutes, not days. Spending ten focused minutes on these basics removes you from the easy-target pool that automated tools feast on, and it costs nothing beyond your attention.

Before you start

You will need SSH access to your new server and the IP address your provider emailed you. On ApexVPS every plan ships with full root access, so you can complete this whole hardening pass yourself. Open a terminal and connect as root (or the default user your image created):

ssh root@your_server_ip

One rule matters more than any other: never disable a login method until you have confirmed the replacement works. Keep your first SSH session open while you test a second one. If something goes wrong, that open session is your safety net.

Step 1 — Update the system

Patched software is the foundation of every VPS security checklist. Start by refreshing the package index and installing the latest security fixes:

sudo apt update && sudo apt upgrade -y

On a brand-new image this often pulls dozens of updates, including kernel and OpenSSH patches. If the kernel is upgraded, plan a reboot with sudo reboot once the rest of the checklist is done.

Step 2 — Create a non-root user with sudo

Logging in directly as root is risky: a single mistaken command runs with unlimited privileges, and root is the first account every attacker tries. Create a dedicated user and grant it administrative rights through sudo instead:

adduser deploy
usermod -aG sudo deploy

The first command creates the account and prompts for a password; the second adds it to the sudo group. Swap deploy for any name you like. From now on you will log in as this user and elevate to root only when a specific command needs it.

Step 3 — Set up SSH key authentication

Passwords can be guessed; SSH keys effectively cannot. Generate a modern Ed25519 key pair on your local machine (not the server):

ssh-keygen -t ed25519 -C "[email protected]"

Accept the default location and, ideally, set a passphrase. Then copy the public half to your new user on the server:

ssh-copy-id deploy@your_server_ip

If ssh-copy-id is unavailable, create the directory and file by hand on the server, paste your public key into ~/.ssh/authorized_keys, and fix the permissions:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Now open a fresh terminal and confirm you can log in without a password: ssh deploy@your_server_ip. Do not move on until this works — the next step depends on it.

Step 4 — Lock down SSH: disable root login and passwords

With key login proven, turn off the weaker options. Edit the SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Set (or uncomment and change) these three directives:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Validate the file before applying it, then restart the service:

sudo sshd -t
sudo systemctl restart ssh

The sshd -t check catches typos that could otherwise lock you out. After the restart, test a new connection in a separate terminal. Root login over SSH and password guessing are now both off the table.

Change the SSH port (optional)

Moving SSH off port 22 will not stop a determined attacker, but it does hide you from the constant background noise of bots that only scan the default port. If you want it, add a line such as Port 2222 to /etc/ssh/sshd_config. Crucially, open the new port in your firewall (next step) before you restart SSH, or you will be locked out.

Step 5 — Enable a firewall with UFW

A firewall makes sure only the ports you intend to expose are reachable. Ubuntu and Debian ship with UFW (Uncomplicated Firewall), which is exactly what its name promises. Set a sensible default and allow SSH before enabling it:

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

The OpenSSH profile opens port 22. If you moved SSH in the previous step, allow the new port instead with sudo ufw allow 2222/tcp. Running a website? Add HTTP and HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Everything else stays closed by default, which is exactly what you want on a public server.

Step 6 — Install fail2ban to stop brute force

Even with keys enforced, attackers will keep hammering your SSH port. fail2ban watches your logs and temporarily bans any IP that fails too many times. Install and enable it:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

To customise the rules, copy the default config to a local override so upgrades never clobber your changes, then edit it:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

In the [sshd] section you can tune values like maxretry and bantime. Reload with sudo systemctl restart fail2ban and check who is currently jailed using sudo fail2ban-client status sshd.

Step 7 — Turn on automatic security updates

Security holes are found constantly, and the ones that hurt are the patches you never applied. The unattended-upgrades package installs important updates for you on a schedule:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Choose "Yes" when prompted, and Ubuntu or Debian will quietly apply security updates in the background. This single step closes the gap between a vulnerability being disclosed and your server being protected.

Step 8 — Disable unused services and basic hardening

Every service that listens on the network is a potential way in, so remove anything you do not need. List what is actually running and what is bound to a port:

sudo systemctl list-units --type=service --state=running
sudo ss -tulpn

If you spot a service you are not using, disable and stop it:

sudo systemctl disable --now <service-name>

A few more quick wins round out the checklist:

• Keep the clock accurate — reliable timestamps make your logs trustworthy; timedatectl confirms time sync is active.
• Review sudo access — only the accounts that genuinely need root should be in the sudo group.
• Read your logs — sudo journalctl -u ssh shows exactly who has been knocking on your door.

For a deeper, framework-level view of secure configuration, the OWASP Foundation publishes widely respected hardening and security guidance worth bookmarking as your setup grows.

Your 10-minute checklist at a glance

Keep this summary somewhere handy — it is the whole routine to secure a VPS in checklist form, so you can repeat it in a couple of minutes on every new server you spin up:

1. Update all packages and reboot if the kernel changed.
2. Create a non-root user and add it to the sudo group.
3. Generate an Ed25519 SSH key and copy the public key to the server.
4. Confirm key-based login works in a second terminal.
5. Disable root login and password authentication in sshd_config.
6. Optionally move SSH to a non-standard port.
7. Enable UFW, deny incoming by default, and allow only the ports you use.
8. Install fail2ban to auto-ban brute-force attempts.
9. Switch on unattended security upgrades.
10. Disable unused services and review what is listening.

None of these steps is difficult on its own, but skipping any one of them leaves an obvious gap. Done together they form a solid baseline that stops the overwhelming majority of opportunistic attacks. From here you can layer on extras as your needs grow — a reverse proxy with TLS, an intrusion-detection tool, per-service isolation with containers, or an off-server backup of your own on top of the provider snapshots.

How ApexVPS complements your hardening

The checklist above hardens the operating system, but some threats live below it. Volumetric attacks and hardware failures are handled at the infrastructure layer, and that is where your provider matters. Every ApexVPS plan includes always-on DDoS protection, so a flood of traffic is absorbed before it ever reaches your firewall, plus automated backups — daily on Starter Pro and hourly snapshots on Business and Enterprise — so a mistake or compromise never means starting from zero. Round-the-clock monitoring and truly dedicated CPU and RAM mean a noisy neighbour can neither slow you down nor become your problem.

You can see the full set of protections on the ApexVPS features overview, and compare what each tier includes on the VPS plans and pricing page. If you are hardening a box specifically to run your own apps, our self-hosting VPS guide pairs neatly with this checklist. Signup is email-only and checkout is crypto-only through OxaPay — Bitcoin, Ethereum, USDT and 30+ coins, with no credit card, no bank account and no KYC.

Frequently asked questions

What is the first thing to do to secure a new VPS?

Update every package with sudo apt update && sudo apt upgrade -y, then create a non-root user with sudo rights so you stop logging in as root. Those two steps close the most common and most damaging attack paths before you configure anything else.

Should I change the default SSH port?

It is optional. Moving SSH off port 22 cuts down the volume of automated scans in your logs, but it is not real security on its own — key-based authentication, a firewall and fail2ban do the heavy lifting. If you do change the port, open the new one in UFW before restarting SSH so you are not locked out.

Do I still need a firewall if I use SSH keys?

Yes. SSH keys only protect the SSH service; a firewall like UFW controls every other port on the machine. Denying all incoming traffic by default and allowing only the ports you actually use is a core part of any secure a VPS checklist, keys or not.

Is fail2ban necessary on a VPS?

It is strongly recommended. Even with password logins disabled, bots will keep probing your SSH port and cluttering your logs. fail2ban automatically bans repeat offenders, reducing noise and blocking the small chance of a successful brute-force attempt against any service.

Does ApexVPS include DDoS protection and backups?

Yes. Every plan comes with always-on DDoS protection and automated backups — daily on Starter Pro and hourly snapshots on Business and Enterprise — alongside 24/7 monitoring. These complement your own OS hardening by covering the infrastructure layer you cannot secure from inside the server.