How to Secure Your VPS: First 10 Things to Do (SSH Keys, Firewall, Fail2ban)

Last updated: October 2026

The moment you create a new VPS, it gets a public IP address. Within minutes, automated bots start trying to log in to it. They don’t care whether your server is a big company’s or a small WordPress blog. They simply try thousands of passwords on port 22 and hope someone left the door open.

The good news is that you can block most of these attacks in less than an hour. In this guide, I’ll walk you through the first 10 things to do on a new VPS: SSH keys, a firewall, Fail2ban, automatic updates, and more. Every step has the exact commands, with a simple explanation of why it matters.

Who is this for? Beginners who have just bought a VPS (from any provider) and want to run a website, WordPress blog, or app on it.

What I assume: Your server runs Ubuntu 24.04 or 26.04 LTS (most providers offer these). Debian works almost the same, with small differences. Replace YOUR_SERVER_IP and youruser in the commands with your own values.

Before You Start: 3 Important Warnings

1. Don’t lock yourself out. Many steps change how you log in. Always keep your current SSH window open and test the new login in a second window before closing the first one.
2. Know your provider’s web console. Most VPS providers have a browser-based console (sometimes called VNC or rescue console). If you get locked out, you can fix things from there. Find it now, before you need it.
3. Take a snapshot first. If your provider offers snapshots, create one before you start. It takes a minute and can save you hours.

1. Update Your Server

A fresh VPS image may already be out of date. Log in as root (or with the user your provider gave you) and run:

sudo apt update
sudo apt upgrade -y

If the system says a reboot is required, restart it:

sudo reboot

Wait a minute, then log in again. This installs the latest security patches before you do anything else.

2. Create a Non-Root User with sudo Access

Logging in as root all the time is risky, because root can do anything and attackers always try the username root first. Create a normal user instead:

adduser youruser
usermod -aG sudo youruser

The first command creates the user and asks you to set a strong password. The second gives the user permission to run administrator commands using sudo.

Test it by switching to the new user:

su - youruser
sudo whoami

If the second command prints root, your sudo access works.

3. Set Up SSH Keys

A password can be guessed. An SSH key is a long cryptographic file that is practically impossible to guess. Using SSH keys is the single biggest security upgrade you can make.

Create a key on your own computer

Open a terminal on your local computer (Linux, macOS, or Windows PowerShell) and run:

ssh-keygen -t ed25519 -C "your-email-or-name"

Press Enter to accept the default location. Add a passphrase when asked. It protects your key if someone steals your laptop.

This creates two files:

• A private key (for example id_ed25519): keep it secret and never share it
• A public key (for example id_ed25519.pub): safe to put on servers

Copy the public key to your server

On Linux or macOS:

ssh-copy-id youruser@YOUR_SERVER_IP

On Windows PowerShell, ssh-copy-id may not be available. Instead, show your public key and paste it into the server manually:

type $env:USERPROFILE\.ssh\id_ed25519.pub

Then, on the server, as youruser:

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

Paste the public key line into the file, save it, and then run:

chmod 600 ~/.ssh/authorized_keys

Test the key login

Open a new terminal window and log in:

ssh youruser@YOUR_SERVER_IP

If it logs you in with your key (asking for your key passphrase, not the server password), it works. Don’t continue until this works.

4. Disable Root Login and Password Login

Now that key login works, turn off the weaker methods. Create a small configuration file:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Add these lines:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3

Why the file name starts with 00: SSH reads these configuration files in alphabetical order, and for most settings the first value it finds wins. Some providers add their own file (for example 50-cloud-init.conf) that enables password login. Naming yours 00- makes sure your settings are read first.

Check the configuration for mistakes, and reload SSH:

sudo sshd -t
sudo systemctl reload ssh

If sshd -t prints nothing, there are no errors. Now confirm the settings are really active:

sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"

You should see permitrootlogin no and passwordauthentication no.

Important: Open a new terminal and confirm you can still log in with your key before closing your old session.

5. Turn On the UFW Firewall

A firewall blocks every port you don’t need. Ubuntu includes UFW (Uncomplicated Firewall), but it’s usually switched off by default.

Allow SSH first. If you skip this, you will lock yourself out.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH

If you’re running a website, also allow web traffic:

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

Then enable the firewall and check its status:

sudo ufw enable
sudo ufw status verbose

The output should show the firewall is active, with SSH, 80, and 443 allowed.

Two tips:

• Your VPS provider may also offer a cloud firewall in its dashboard. Using both gives extra protection.
• If you use Docker, remember that Docker can publish container ports and bypass UFW rules. Be careful with -p options, and bind private services to 127.0.0.1 where possible.

6. Install Fail2ban

Even with keys, bots will keep knocking on your SSH port and filling your logs. Fail2ban watches the logs and temporarily bans IP addresses that fail to log in repeatedly.

sudo apt install fail2ban -y

Don’t edit the main config file. Create a local one that survives updates:

sudo nano /etc/fail2ban/jail.local

Add:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
backend = systemd

This means: if an IP fails 5 times within 10 minutes, ban it for 1 hour. If you have a fixed home IP, you can add it to ignoreip so you never ban yourself, but only do this if the IP really is yours and stable.

Start it and check the status:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

After some hours or days on the internet, you’ll probably see banned IP addresses listed. That proves it’s working.

If you get banned yourself: Use your provider’s web console, then unban your IP:

sudo fail2ban-client set sshd unbanip YOUR_IP

7. Turn On Automatic Security Updates

Most hacked servers are attacked through known bugs that already have a fix, but the owner never installed the update. Let the server install security patches automatically.

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

Choose Yes when asked. You can test the configuration with:

sudo unattended-upgrades --dry-run --debug

Recent Ubuntu releases may already have automatic security updates enabled by default, but it’s worth checking. Remember that some updates, such as kernel updates, need a reboot. You can allow automatic reboots at a quiet hour, but only if a short downtime is acceptable for your site. Otherwise, reboot manually every few weeks.

8. Check What Ports and Services Are Open

The fewer things listening on the internet, the smaller your attack surface. See what’s open:

sudo ss -tulpn

Look at the Local Address column:

• Addresses starting with 0.0.0.0 or [::] are open to the whole internet.
• Addresses starting with 127.0.0.1 are only reachable from the server itself, which is safer.

A typical WordPress server should have only SSH (22), HTTP (80), and HTTPS (443) open to the world. Databases like MySQL (3306) should not be public. Bind them to 127.0.0.1.

If you find a service you don’t need, stop and disable it:

sudo systemctl disable --now service-name

9. Set Up Backups and Snapshots

Security isn’t only about keeping attackers out. It’s also about recovering if something goes wrong, whether from an attack, a bad update, or your own mistake.

• Provider snapshots: Enable automatic backups or snapshots in your VPS dashboard. They usually cost a small extra fee.
• Website backups: For WordPress, use a plugin like UpdraftPlus and send backups to remote storage, such as Google Drive, not only to the same server.
• Database backups: Back up your database regularly.
• Test your restore: A backup you’ve never tested may not work when you need it.

Follow the simple 3-2-1 idea: keep 3 copies of important data, on 2 different types of storage, with 1 copy off the server.

10. Use HTTPS and Keep Monitoring

If you host a website, you need an SSL certificate so visitors connect over HTTPS. Let’s Encrypt provides free certificates. With Nginx, for example:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com -d www.example.com

Replace example.com with your domain. Certbot normally sets up automatic renewal. You can test it with:

sudo certbot renew --dry-run

Then make monitoring a habit:

• Check sudo fail2ban-client status sshd and your login history from time to time
• View recent logins with last and failed attempts with sudo lastb
• Keep WordPress, themes, and plugins updated, and delete the ones you don’t use
• Use strong, unique passwords and enable two-factor authentication on your hosting account and WordPress admin
• Check your server’s disk space, memory, and uptime occasionally

Bonus: Should You Change the SSH Port?

Many guides suggest moving SSH from port 22 to a different port. This reduces noise in your logs, but it does not make you truly secure, because a determined attacker can still find the new port. SSH keys, a firewall, and Fail2ban matter far more.

Be careful on recent Ubuntu versions: Newer Ubuntu releases start SSH using systemd socket activation, so changing only the Port line in the SSH config may not work as you expect. If you decide to change the port, follow the official Ubuntu documentation for your exact version, open the new port in UFW first, keep your current session open, and test the new port in a second window. For a beginner, it’s perfectly fine to keep port 22 and rely on keys and Fail2ban.

Quick Security Checklist

• [ ] System updated and rebooted
• [ ] Non-root user with sudo created
• [ ] SSH key login works
• [ ] Root login and password login disabled
• [ ] UFW firewall enabled (SSH allowed first)
• [ ] Fail2ban running and protecting SSH
• [ ] Automatic security updates on
• [ ] Only needed ports open
• [ ] Backups or snapshots enabled and tested
• [ ] HTTPS enabled and monitoring habit started

Common Mistakes to Avoid

1. Enabling UFW before allowing SSH. This locks you out immediately.
2. Disabling password login before testing key login. Always test the key first in a second window.
3. Losing your private key. Keep a safe backup of it, with a passphrase.
4. Sharing your private key. Only the public key (.pub) is shared.
5. Never updating the server. Most attacks target known, fixable bugs.
6. Leaving the database open to the internet.
7. Skipping backups. Security tools can’t help if you have nothing to restore.
8. Following random commands without understanding them. Read what each command does before running it, including the ones in this post.

Frequently Asked Questions

Do I need all 10 steps?

For a public server, steps 1 to 7 are the essential foundation. Steps 8 to 10 are strongly recommended, especially backups.

Is Fail2ban still needed if I use SSH keys?

It’s not strictly required once password login is off, but it still reduces log noise and blocks repeated attacks, so it’s a useful extra layer.

Will these steps work on Debian or other Linux distributions?

Mostly yes, since Debian uses the same tools. Package names and service names can differ on other distributions such as CentOS or AlmaLinux (which use firewalld instead of UFW).

What if I lose my SSH key or get locked out?

Use your VPS provider’s web console to log in and fix the configuration, or restore from a snapshot. That’s why knowing your provider’s console and taking a snapshot first is so important.

Does changing the SSH port improve security?

It reduces automated noise, but it’s not real protection on its own. Keys, a firewall, and Fail2ban are much more important.

Is a VPS safe for WordPress?

Yes, if you secure and maintain it. A VPS gives you more control than shared hosting, but it also gives you more responsibility for updates, backups, and security.

Final Thoughts

You don’t need to be a security expert to protect a VPS. Update the system, use SSH keys, close unnecessary doors with a firewall, let Fail2ban deal with repeated attackers, and keep tested backups. These ten steps stop the vast majority of automated attacks.

If you’re still deciding on a server, you may like my guides on What Is a VPS and Who Needs One and How to Install WordPress on a VPS. Questions about this guide? Send them through my Contact page.

Disclaimer: Server security is a broad topic, and commands can differ between operating system versions and providers. This guide is for educational purposes. Always keep a backup, test changes carefully, and read the official documentation for your system before changing a production server.