Your VPS Is Being Attacked Right Now: SSH Hardening Guide for Seedbox and Self-Hosting Users

If you just spun up your first VPS and checked your fail2ban stats, you probably saw something like this:

$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed:  3
|  |- Total failed:      586
`- Actions
   |- Currently banned:  51
   `- Total banned:      54

54 bans in 12 hours. 586 total attempts. Is this normal?

Yes. Completely. Automated bots scan the entire IPv4 address space continuously. A new public IP gets its first probe within minutes of going online. For seedbox users running qBittorrent, Plex, Sonarr, or any web-facing service on a VPS or dedicated server, this is your baseline threat environment — and fail2ban alone isn't enough.

Here's how to actually lock things down.

---

Step 1: Disable Password Authentication Entirely

This is the single highest-impact change you can make. Bots are brute-forcing passwords. If you're not using key-based auth yet, do this first.

On your local machine, generate a key pair if you don't have one:

ssh-keygen -t ed25519 -C "seedbox-vps"

Copy your public key to the server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-vps-ip

Then on the server, edit /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AuthorizedKeysFile .ssh/authorized_keys

Restart SSH:

sudo systemctl restart sshd

⚠️ Test your key login in a second terminal before closing your current session. Locking yourself out of a remote VPS is a painful lesson.

Once password auth is disabled, the vast majority of bot attacks become completely irrelevant — they're all trying passwords.

---

Step 2: Move SSH Off Port 22

Security through obscurity isn't a strategy on its own, but moving SSH off port 22 will eliminate nearly all automated noise from your logs and reduce fail2ban's workload significantly.

In /etc/ssh/sshd_config:

Port 2222

(Pick any unused port above 1024. Some people use something in the 40000–60000 range.)

Update your firewall to allow the new port, then restart sshd. Your SSH command becomes:

ssh -p 2222 user@your-vps-ip

Or add it to ~/.ssh/config on your local machine so you don't have to type it every time:

Host myvps
    HostName your-vps-ip
    User youruser
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Then you just run ssh myvps.

---

Step 3: Tune fail2ban Properly

The default fail2ban config is conservative. Here's a more aggressive setup for a seedbox/VPS context.

Create or edit /etc/fail2ban/jail.local (never edit jail.conf directly — it gets overwritten on updates):

[DEFAULT]
bantime  = 24h
findtime = 10m
maxretry = 3
banaction = iptables-multiport

[sshd]
enabled  = true
port     = 2222
logpath  = %(sshd_log)s
backend  = systemd
maxretry = 3
bantime  = 48h

Key changes from defaults:

• bantime = 48h — bots get blocked for two days, not 10 minutes
• maxretry = 3 — three strikes, not five
• findtime = 10m — three failures within 10 minutes triggers a ban

Reload fail2ban:

sudo systemctl reload fail2ban
sudo fail2ban-client status sshd

---

Step 4: Set Up a Firewall (ufw or nftables)

If you're running seedbox services — qBittorrent web UI, Plex, Sonarr, Jellyfin — you need explicit firewall rules. Don't leave ports open that don't need to be.

ufw is the easiest option on Ubuntu/Debian:

sudo apt install ufw

# Default deny incoming, allow outgoing
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow your custom SSH port
sudo ufw allow 2222/tcp

# Allow Plex (if running locally exposed)
sudo ufw allow 32400/tcp

# Allow qBittorrent WebUI (change port to match your config)
sudo ufw allow 8080/tcp

# Allow qBittorrent torrent port
sudo ufw allow 51413/tcp
sudo ufw allow 51413/udp

sudo ufw enable
sudo ufw status verbose

Only open what you actually use. If your qBittorrent WebUI is behind a reverse proxy (Nginx/Caddy), you can restrict port 8080 to localhost only and only expose 443.

---

Step 5: Consider Restricting SSH Access by IP

If you have a static IP at home (or use a VPN with a consistent exit IP), you can whitelist SSH access entirely:

sudo ufw allow from 203.0.113.42 to any port 2222

This means even if someone knows your SSH port and has a valid username, they can't connect from any other IP. For seedbox users who primarily manage their box from home, this is extremely effective.

---

Step 6: Keep Your Attack Surface Small

Every service you expose is a potential entry point. For a typical seedbox stack:

Service	Recommendation
SSH	Key auth only, non-standard port, IP whitelist if possible
qBittorrent WebUI	Behind reverse proxy with HTTPS + auth
Plex	Native Plex relay or reverse proxy; don't expose raw port if possible
Jellyfin	Reverse proxy (Caddy or Nginx) with HTTPS
Sonarr/Radarr	Never expose directly; reverse proxy with auth or VPN-only access
Prowlarr	Same as above — internal only

A Caddy reverse proxy config for Jellyfin looks like this:

jellyfin.yourdomain.com {
    reverse_proxy localhost:8096
}

Caddy handles HTTPS automatically via Let's Encrypt. No exposed port 8096, no plain HTTP.

---

Step 7: Monitor What's Actually Happening

Install logwatch or check logs manually to stay aware:

sudo apt install logwatch
sudo logwatch --output stdout --format text --range today --service sshd

Or a quick manual check:

sudo journalctl -u ssh --since "24 hours ago" | grep "Failed password" | wc -l
sudo journalctl -u ssh --since "24 hours ago" | grep "Accepted"

The second command shows successful logins — if you see anything unexpected there, that's your real problem.

---

The Practical Takeaway

54 SSH bans in 12 hours is normal. 0 successful unauthorized logins is the goal.

The attack surface for a typical seedbox VPS is larger than most people realize — you've got SSH, a torrent client WebUI, a media server, and several automation tools all potentially reachable from the internet. The good news is that the fixes are straightforward:

1. Key-based SSH auth — eliminates brute-force attacks entirely
2. Non-standard SSH port — kills the automated noise
3. Aggressive fail2ban config — catches anything that slips through
4. ufw with minimal open ports — reduces exposure
5. Reverse proxy everything — keeps internal services off public ports

Do steps 1 and 2 today. The rest can follow. A compromised VPS doesn't just affect you — it can get your seedbox provider to terminate your account and your private tracker accounts flagged if your ratio data gets corrupted or your IP starts appearing in abuse reports.