SSH hardening is where most people brick their first VPS. I did it on Vultr in 2019 — changed the port, enabled key-only auth, and watched PuTTY time out because I forgot Vultr’s cloud firewall still pointed to port 22. This guide is the sequence I now run on every new Vultr instance. Follow it in order. Skip a step and you may need the web console.

—

What Makes Vultr Different

Vultr runs two firewalls in parallel: their cloud firewall in the control panel, and whatever you install on the instance itself (UFW, firewalld, or nothing). The cloud firewall defaults to deny all incoming when you attach a firewall group. If you change your SSH port in `sshd_config` but don’t update the cloud firewall, you lose all SSH access immediately.

Vultr’s View Console button is your recovery path. It opens a VNC session in the browser. No copy-paste, slow refresh, but it works even with broken networking or SSH. Bookmark where it lives: Products → Compute → your instance → View Console. Last verified in Vultr panel: 2026-09-07.

—

Prerequisites

Item	Why You Need It
Vultr Cloud Compute instance	This guide tested on Ubuntu 24.04 LTS
Root or sudo access	All commands need elevation
SSH key already added to instance	Vultr prompts for this at creation — do it
Vultr View Console tab open	Recovery path if SSH breaks

If you created your instance with password root login, complete Step 1 (key setup) before touching anything else. Password auth is the first thing we’re killing.

—

Step 1: Verify Key-Based Login Works

Lockout risk: Low, but confirm before proceeding.

Open a second terminal window. Log in again with your key:

ssh -i ~/.ssh/your_key root@your.vultr.ip

If this fails, fix it now. Do not continue. The Vultr View Console accepts password login if that’s your only access method — use it to upload a proper key to `~/.ssh/authorized_keys`, set `chmod 600` on that file, and `chmod 700` on `~/.ssh`.

—

Step 2: Update Packages

sudo apt update && sudo apt upgrade -y

—

Step 3: Install fail2ban

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

fail2ban watches SSH logs and bans IPs after failed attempts. Default is 5 failures in 10 minutes, 10-minute ban. Good enough for now. We’ll tighten it later.

—

Step 4: Configure SSH — The Danger Zone

We’re changing three things: port, root login, and authentication method. Each can lock you out independently. I handle them in this order specifically because of how Vultr’s stack behaves.

4a. Pick Your New Port

Choose something between 1024 and 65535. I use 4422 for testing — easy to remember, not in common scan lists. Do not use 2222 — it’s the first alternative port bots probe.

4b. Edit sshd_config

sudo nano /etc/ssh/sshd_config

Find and change these lines:

#Port 22
Port 4422

#PermitRootLogin prohibit-password
PermitRootLogin no

#PasswordAuthentication yes
PasswordAuthentication no

#MaxAuthTries 6
MaxAuthTries 3

Uncomment the lines if they’re commented. Set the values exactly. Do not reload SSH yet.

4c. Validate Syntax

sudo sshd -t

No output means clean config. Any error output means SSH will refuse to start. Fix it before continuing.

—

Step 5: Open the New Port in Vultr’s Cloud Firewall

Lockout risk: CRITICAL. Do this before reloading SSH.

Vultr’s cloud firewall sits between the internet and your instance. If you change SSH to port 4422 but the cloud firewall still only allows 22, your next login attempt dies at the edge. The connection never reaches fail2ban, UFW, or anything else.

In the Vultr control panel (last verified 2026-09-07):

1. Products → Firewall
2. Click your firewall group, or Create Firewall Group if none exists
3. Add Rule:
– Type: TCP
– Port: 4422
– Source: My IP (or 0.0.0.0/0 if dynamic IP, less secure)
4. Do not delete the port 22 rule yet
5. Save Changes
6. Products → Compute → your instance → Settings → Firewall
7. Attach the firewall group if not already attached

Wait 30 seconds for propagation. Vultr’s firewall pushes are usually instant, but I’ve seen 15-second delays in the Singapore region.

—

Step 6: Open the New Port in UFW (If Enabled)

Check if UFW is active:

sudo ufw status

If `Status: active`, add the rule:

sudo ufw allow 4422/tcp

Do not enable UFW here if it’s disabled. Vultr instances often ship with UFW disabled. Enabling it without proper rules can block your new SSH port if the cloud firewall doesn’t cover it — Vultr’s cloud firewall and UFW are independent layers. I once enabled UFW on a fresh instance, forgot to allow my new SSH port in UFW specifically, and locked myself out because the cloud firewall was set to “allow all” (no group attached). The web console saved me.

—

Step 7: Test the New Port Without Closing Your Current Session

Lockout risk: MODERATE. Keep your existing SSH window open.

In your second terminal window (opened in Step 1), test:

ssh -p 4422 -i ~/.ssh/your_key root@your.vultr.ip

If this connects, you have working key auth on the new port. If it hangs or refuses:

Symptom	Likely Cause	Fix
Connection timed out	Cloud firewall blocking 4422	Check Vultr panel, rule propagation
Connection refused	SSH not listening on 4422	sudo ss -tlnp | grep sshd, check sshd_config
Permission denied (publickey)	Key not in authorized_keys, or wrong key file	Use View Console, verify ~/.ssh/authorized_keys

Do not proceed until the second terminal connects successfully. Your first terminal is your lifeline.

—

Step 8: Reload SSH to Apply Changes

In your first terminal (the original connection on port 22):

sudo systemctl reload sshd

`reload` keeps existing connections alive. `restart` would drop them. Use `reload`.

—

Step 9: Verify Key-Only, No-Root, New Port Works

In your second terminal (already on 4422), confirm you’re in. Then try root login from a third test — it should fail:

ssh -p 4422 -i ~/.ssh/wrong_key root@your.vultr.ip

Expected: Permission denied (publickey)

ssh -p 4422 root@your.vultr.ip

Expected: Permission denied (publickey) — no password prompt

If you still get a password prompt, `PasswordAuthentication no` didn’t take. Check sshd_config for typos.

—

Step 10: Remove Port 22 from Vultr Cloud Firewall

Now that 4422 is confirmed working, delete the port 22 rule in Vultr’s panel:

Products → Firewall → your group → Delete the TCP 22 rule → Save Changes

I wait 60 seconds, then test that port 22 no longer responds:

ssh -p 22 root@your.vultr.ip

Expected: Connection timed out or refused

—

Step 11: Harden fail2ban

sudo nano /etc/fail2ban/jail.local

Create this file if it doesn’t exist:

[sshd]
enabled = true
port = 4422
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

The `port = 4422` line is critical. Default fail2ban watches port 22. If you changed SSH port but not fail2ban’s target, it monitors the wrong service.

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

—

Step 12: Install and Configure Unattended Upgrades for SSH

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

Select Yes. This auto-installs security updates including OpenSSH patches. I configure it to auto-reboot if needed:

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Uncomment:

Unattended-Upgrade::Automatic-Reboot “true”;
Unattended-Upgrade::Automatic-Reboot-Time “03:00”;

—

Recovery Reference: If You Lock Yourself Out

What You Did	Recovery Path
Changed SSH port, forgot cloud firewall	Vultr View Console → log in → sudo nano /etc/ssh/sshd_config → revert port → sudo systemctl restart sshd
Enabled key-only auth, lost key file	View Console → password login (if still enabled) or use Vultr’s ISO mount to boot Finnix and reset
Broken sshd_config syntax	View Console → sudo sshd -t to find error → fix → sudo systemctl restart sshd
UFW or iptables blocking SSH	View Console → sudo ufw disable or sudo iptables -F → fix rules → re-enable

The View Console is slow. It has no copy-paste. But it bypasses every network and SSH issue. I keep it open in a browser tab during any SSH hardening session.

—

What Specifically Worked on Vultr

Vultr’s dual-firewall setup is both risk and safety net. The cloud firewall saved me when I botched UFW rules — I could still reach the instance because no firewall group was attached, so default-allow applied. The View Console recovered me when I attached a firewall group with wrong rules. Both tools are standard, but Vultr exposes them clearly in the panel without hunting through menus.

Reference environment for this guide: Vultr Cloud Compute, Regular Performance, 1 vCPU / 1GB RAM (Amsterdam region). $5/month at time of writing. Pricing verified 2026-09-07.

—

Provider Note

I recommend Vultr for SSH hardening practice specifically because the View Console is reliable and the firewall group UI is fast. I’ve used providers where console access takes 90 seconds to initialize or firewall changes propagate inconsistently. Vultr’s console loads in under 10 seconds and firewall pushes are typically sub-30-second. That matters when you’re one bad config away from rebuilding. The $5 entry plan is enough to run fail2ban and a small web stack without swap thrashing.

If you’re comparing providers for a similar project, I’ve run comparable hardening sequences on RackNerd and InterServer — both have functional consoles, though RackNerd’s firewall UI is less granular and InterServer’s console requires Java plugin workarounds on some browsers. Vultr’s web-native console and clean firewall abstraction make it the safer choice for non-sysadmins learning SSH hardening.

Check RackNerd’s current VPS pricing

That said, if your main concern is renewal pricing — watching a $2.50/month intro rate balloon to $12 on year two — InterServer is worth a look. They built their reputation on holding the signup price for the life of the account, and they own their own data centers rather than leasing space.

Check InterServer’s VPS pricing

This post contains affiliate links. If you purchase through our links, we may earn a small commission at no extra cost to you.