Why trust this guide
By Victus Cloud · Reviewed by Victus Cloud · No individual author claimed. Verify paths, versions, and backups before changing a live service.
Evidence-led, product-agnostic
A freshly provisioned Linux VPS is a blank slate, and attackers scan new IP ranges constantly. The good news is that you can secure Linux VPS hosts in about 15 minutes with a handful of disciplined steps. This guide walks through disabling root login, hardening SSH, configuring the UFW firewall, and deploying fail2ban plus an automated, AI-driven threat detection layer — while being honest that advanced detection tooling availability is plan-dependent and must be confirmed in your panel.
Before you begin
Make sure you have a non-root sudo user already created and that you can log in with an SSH key from a second session before you change anything. The single most common lockout mistake is disabling password and root login before key-based access is proven. Keep that rescue session open until every change is verified.
- Create a sudo user before touching SSH config
- Copy your public key and confirm key-based login works
- Keep one authenticated session open as a safety net
- Note your provider console or rescue access in case you lock yourself out
Victus plan details are the source of truth
Firewall controls, automated backups, console or rescue access, and any AI-driven threat detection tooling vary by product and plan. Verify current panel and plan details before relying on a specific capability or promised metric.
Disable root login and use SSH keys
Root is the account every brute-force bot tries first, so disabling direct root login and password authentication removes the bulk of automated attacks. Edit the SSH daemon config to require key-based auth, then restart the service. Replace the port only if you have a reason; moving it is security through obscurity, not a real control.
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl restart ssh
# Confirm a NEW key session works before closing the old oneConfigure the UFW firewall
UFW is the uncomplicated firewall front-end for iptables. Start by denying everything, then explicitly allow only the traffic you need: SSH, and whatever services you actually run. A default-deny stance means a forgotten open port cannot become an open door.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp # SSH
sudo ufw allow 80/tcp # HTTP
sudo ufw allow 443/tcp # HTTPS
sudo ufw enable
sudo ufw status verboseIf you changed the SSH port, allow that port instead of 22. After enabling, confirm from your open session that you can still reach the server; a mistake here is recoverable via console access, which is why we kept it handy earlier.
Deploy fail2ban to slow brute force
fail2ban watches log files for repeated failures and temporarily bans the offending IP. It is lightweight, mature, and a strong second layer behind key-only SSH. The config below jails SSH after three failed attempts within ten minutes.
sudo apt-get install -y fail2ban
sudo tee /etc/fail2ban/jail.local >/dev/null <<'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 10m
bantime = 1h
EOF
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshdAdding automated, AI-driven threat detection
Beyond static rules, modern hosts offer automated, AI-driven threat detection that baselines normal process and network behavior and flags anomalies such as a sudden crypto-miner or an unexpected outbound connection. This is where plan-dependent tooling matters: some plans surface these detections in the panel, while others leave you to wire up your own agent. Confirm what your plan provides before depending on it.
- Confirm whether your plan includes managed threat detection
- If self-serving, install an auditd + anomaly-scoring agent
- Forward auth and fail2ban logs to a single place for review
- Set alerts so a detected anomaly pages a human quickly
Detection is plan-dependent
Do not assume AI-driven monitoring, managed detection, or automatic bans are included. These features vary by product and plan; verify the current panel and plan details before designing an incident response around them.
The 15-minute security checklist
Use this table as a final pass. Each row is a discrete, fast action; tick them off in order and you have a genuinely hardened baseline in well under a quarter hour on a typical Debian or Ubuntu VPS.
| Step | Action | Time |
|---|---|---|
| 1 | Create sudo user, copy SSH key | 2 min |
| 2 | Disable root + password auth | 2 min |
| 3 | Enable UFW default-deny | 2 min |
| 4 | Install and start fail2ban | 3 min |
| 5 | Confirm console/rescue access | 1 min |
| 6 | Enable AI threat detection if available | 5 min |
Going further without the rabbit hole
Once the baseline is set, consider automatic security updates, a weekly credential rotation for service accounts, and encrypted backups stored in a separate failure domain. None of these are required for the 15-minute win, but they turn a one-time lock-down into a durable posture. Tie the firewall and monitoring into your resource alerts so a ban storm is visible, not silent.
- Enable unattended-upgrades for security patches
- Store backups off-host and test a restore
- Monitor fail2ban and detection alerts in one dashboard
- Review authorized keys quarterly and prune stale ones
Summary
You can secure Linux VPS hosts in 15 minutes: disable root login, require SSH keys, set UFW to default-deny, and deploy fail2ban. Layer automated, AI-driven threat detection on top where your plan provides it, and verify that capability in the panel rather than assuming it. Discipline beats complexity — a small, correct baseline beats a fancy, unfinished one.