What's the first thing to do on a new VPS?

Get in with an SSH key and turn off password login. Automated bots hammer port 22 with password guesses within minutes of a server going live; a key makes those attempts pointless. Everything else is secondary to that one change.

Do I need a firewall if I only run one service?

Yes. A firewall (ufw) means only the ports you explicitly open are reachable — so a service you forgot you started, or one a dependency opened, isn't silently exposed. It's two commands and it closes a whole class of mistakes.

Is fail2ban necessary if I disabled password login?

It's optional once keys are enforced — with passwords off, brute force can't succeed anyway. fail2ban mainly trims log noise and blocks abusive IPs early. Nice to have, not critical, on a key-only box.

Should I change the SSH port?

It's cosmetic security — moving off 22 cuts log noise from dumb bots but stops no determined attacker. Do it if the noise bothers you, but don't mistake it for real protection. Keys + no passwords is what actually matters.

How do I keep a VPS patched automatically?

Enable unattended-upgrades (Debian/Ubuntu) so security patches install themselves. It's the single highest-value habit after SSH keys — most break-ins exploit known, already-patched bugs on servers nobody updated.

Securing a new VPS: the checklist that actually matters

The first ten minutes on a fresh VPS quietly decide a lot. A new public IP starts getting probed by automated bots almost immediately — they're not targeting you, they just scan everything. Do nothing and you're relying on luck. Do four or five small things and you've closed the doors that actually get kicked in. Here's the list, in priority order, with the commands.

This is the one that matters most. If you can log in with a password, so can a bot that guesses it — and they try thousands per minute.

From your laptop, if you don't already have a key:

ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id root@your-server-ip

Then on the server, turn passwords off:

# /etc/ssh/sshd_config.d/99-hardening.conf
PasswordAuthentication no
PermitRootLogin prohibit-password

sudo systemctl reload ssh

⚠️ Test a second SSH session before you close the first — if the key login works, great; if not, you still have the open session to fix it. Locking yourself out is the classic own-goal here.

2. A firewall — default deny

Only expose what you mean to. On Ubuntu/Debian:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH        # or your SSH port
sudo ufw enable

Now a stray service can't be reached from outside unless you open it. This catches the thing you'll inevitably forget about.

One note for NAT-style plans: your SSH lands on a forwarded port, not 22, and you can't open arbitrary inbound ports — the isolation does part of this job for you. On a dedicated-IP plan you own all ports, so the firewall does more work.

3. Automatic security updates

Most servers that get popped weren't clever targets — they were running a known bug that a patch had already fixed, on a box nobody updated. Make patching automatic:

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

Set-and-forget. This is the highest-value habit after SSH keys.

4. fail2ban (optional, but cheap)

With password login already off, brute force can't win — so this is about trimming noise and banning abusive IPs early rather than core protection:

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

Worth it for the quieter logs; skip it without guilt if you're keeping things minimal.

What you can skip

Changing the SSH port — cuts bot noise, stops no real attacker. Cosmetic. Don't confuse it with security.
Elaborate IDS/SELinux tuning — overkill for a single-purpose box running a bot or an agent. Diminishing returns.

The honest summary

If you only do one thing, do SSH keys + no password login. Add the firewall and auto-updates and you've handled the overwhelming majority of real-world risk in well under ten minutes. Everything past that is polish.

Running an always-on agent or bot on the box? Pair this with keeping it alive under systemd so it survives reboots and crashes, not just attackers.