How to Protect a VPS from Brute-Force Attacks

Point a fresh server at the internet and within minutes bots start guessing SSH, database, and web logins. Brute-force attacks are constant background noise, and a single weak password can hand over your server. The fix isn't one setting — it's layers, so that even if one fails, the others hold. Here's the full playbook.

Layer 1: eliminate guessable credentials

The most effective defence is removing anything to guess. Switch SSH to keys and turn off passwords entirely, as covered in SSH key authentication. A 256-bit key cannot be brute-forced in any human timeframe, so the attacker's primary tool becomes useless.

Layer 2: remove obvious usernames

Attackers target root, admin, and ubuntu. Disable root login and use a non-obvious username. Now the bot must guess a valid username *and* a key — effectively impossible.

Layer 3: close unnecessary doors

A firewall means most services aren't even reachable to attack. Set default-deny and expose only what you need with UFW:

sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw enable

Bind databases and admin panels to localhost or specific IPs, never 0.0.0.0.

Layer 4: rate-limit and ban repeat offenders

Even with keys, you want to punish repeated attempts. UFW can throttle connections:

sudo ufw limit OpenSSH

And fail2ban bans IPs that rack up failures. A tight jail:

[sshd]
enabled  = true
backend  = systemd
maxretry = 3
bantime  = 1h
findtime = 10m

{{SCREENSHOT}}

Layer 5: reduce your attack surface

Brute-forcing isn't limited to SSH. Any exposed login is a target:

• Databases: never expose MySQL/PostgreSQL to the internet — see secure a MySQL database.
• WordPress: wp-login.php is heavily attacked — secure a self-hosted WordPress site.
• Admin panels: put them behind a VPN or IP allowlist.

Layer 6: add a second factor

For the most sensitive access, two-factor authentication on SSH means a leaked key still isn't enough.

Layer 7: watch the logs

You can't defend what you can't see. Check auth activity regularly:

sudo journalctl -u ssh | grep -i "failed\|invalid"

A sudden spike signals a campaign. Our journalctl guide and monitor a Linux VPS walkthrough help you set up ongoing visibility.

Put it together

None of these steps is hard, and together they turn your server from an easy target into a non-target. Bots move on to softer prey. Start with the quick wins in securing your first Linux VPS.

A realistic picture of what bots actually do

Understanding the adversary makes the defences make sense. The overwhelming majority of "attacks" on a typical VPS aren't targeted at *you* at all — they're mass, automated scans sweeping the entire internet. A botnet picks a range of IPs, connects to port 22 (and 80, 443, 3306, 3389…), and tries a dictionary of common usernames and passwords: root/root, admin/admin, root/123456, and so on. It spends a few seconds per host and moves on if it doesn't get quick results.

This is good news, because it means you don't have to be impregnable — you just have to be *harder than the easy targets next door*. Key-only auth alone defeats essentially all of this traffic, because there's no password field to fill. The bot's entire strategy collapses. That's why the single most effective step is disabling password authentication: it doesn't just slow the attack, it makes the attacker's primary tool irrelevant.

Watch for the rarer targeted attempt

A small slice of traffic is different — someone probing *your* server specifically, perhaps because it hosts something valuable. Signs include attempts against non-standard usernames that match your organisation, probing of specific application endpoints, or slow, low-volume attempts designed to stay under a fail2ban threshold ("low and slow"). This is where layered defence earns its keep: even a patient attacker who avoids triggering bans still faces key-only auth, a firewall that hides most services, and 2FA on the accounts that matter.

Set up alerting so a change in pattern reaches you. A sudden spike in failures, attempts from an unusual geography, or probes against an admin path are all worth a look. Combine monitoring with regular log review so you notice the unusual against a known-normal baseline.

FAQ

Do I still get brute-force attempts with keys enabled?

Yes — bots don't know you use keys, so they'll still try. But every attempt fails harmlessly, and fail2ban bans the persistent ones to keep logs clean.

Is changing the SSH port worth it?

It cuts automated noise significantly but isn't real security. Do it for tidier logs, not as a substitute for keys and a firewall.

What's the single most important step?

Disabling password authentication in favour of SSH keys. It removes the thing brute-force attacks actually target.

How do I know if I'm under attack?

Repeated "Failed password" or "Invalid user" entries in your auth log, or CPU/network spikes. Set up monitoring so you're alerted rather than surprised.

The brute-force defence checklist

No single setting stops brute-force attacks — the strength is in stacking cheap, independent layers:

• Keys, not passwords: PasswordAuthentication no removes the attack's target entirely.
• No obvious usernames: disable root login and avoid admin/ubuntu.
• Default-deny firewall: most services shouldn't be reachable to attack at all.
• Rate limit + ban: ufw limit OpenSSH plus fail2ban punish repeat attempts.
• Shrink the surface: bind databases to localhost, put admin panels behind a VPN or IP allowlist.
• Add a second factor on the accounts that matter most.
• Watch the logs so a change in attack pattern reaches you, not just your log files.

Work down that list and each layer covers a different failure mode of the others. An attacker would need several independent things to go wrong at once, which is exactly what turns your server from an easy target into one the bots skip.

A layered defence makes brute-forcing your server a waste of an attacker's time. Build it on a VPS with full root access — explore Nxeon VPS hosting and our security page.