{"id":881,"date":"2026-08-13T23:49:36","date_gmt":"2026-08-13T23:49:36","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=881"},"modified":"2026-08-19T22:12:36","modified_gmt":"2026-08-19T22:12:36","slug":"fail2ban-setup-linux-vps-ssh-security","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/fail2ban-setup-linux-vps-ssh-security\/","title":{"rendered":"Fail2ban on a VPS: Block SSH Attacks Without Locking Yourself Out"},"content":{"rendered":"\n

Any Linux VPS with SSH exposed to the internet starts collecting brute-force attempts within hours of its first boot. A typical fresh instance sees thousands of failed logins per day from scripted dictionaries and botnets. Fail2ban is the standard, low-cost defense: it watches log files, counts failures per source IP, and temporarily bans offenders via the firewall. This guide walks through a safe setup for SSH and web logins \u2014 including the whitelisting and testing steps that keep you from locking yourself out of your own server.<\/p>\n\n\n\n

How fail2ban works<\/h2>\n\n\n\n

Fail2ban runs a daemon that tails log files (by default \/var\/log\/auth.log<\/code> on Debian and Ubuntu), matches entries against regex filters, and increments a counter per source IP. When the counter crosses maxretry<\/code> within findtime<\/code> seconds, it applies a jail action \u2014 usually adding a firewall rule that drops traffic from that IP for bantime<\/code> seconds. It is reactive, not preventive: it does not stop the first few attempts, but it makes sustained brute force impractical and keeps your logs readable.<\/p>\n\n\n\n

Install and enable<\/h2>\n\n\n\n
    \n
  1. sudo apt update && sudo apt install -y fail2ban<\/code><\/li>\n
  2. sudo systemctl enable --now fail2ban<\/code><\/li>\n
  3. sudo systemctl status fail2ban<\/code> \u2014 confirm it is active (running)<\/li>\n
  4. sudo fail2ban-client status<\/code> \u2014 the default sshd<\/code> jail should be listed<\/li>\n<\/ol>\n\n\n\n

    On Ubuntu 22.04+, Debian 12, and newer images, fail2ban detects the host firewall backend automatically and uses nftables<\/code> when the system firewall is nftables-based (which includes default ufw on modern Ubuntu). It coexists with ufw cleanly; just avoid enabling both the iptables and nftables backends at the same time.<\/p>\n\n\n\n

    The config model: jail.conf vs jail.local<\/h2>\n\n\n\n

    Never edit \/etc\/fail2ban\/jail.conf<\/code> directly \u2014 package updates overwrite it. Put your overrides in \/etc\/fail2ban\/jail.local<\/code>. The settings that matter most:<\/p>\n\n\n\n

    Setting<\/th>Default<\/th>Practical recommendation<\/th><\/tr><\/thead>
    bantime<\/code><\/td>10m<\/td>1h\u201324h for SSH; longer for repeat offenders<\/td><\/tr>
    findtime<\/code><\/td>10m<\/td>Time window in which failures are counted<\/td><\/tr>
    maxretry<\/code><\/td>5<\/td>3\u20135 for SSH<\/td><\/tr>
    ignoreip<\/code><\/td>127.0.0.1\/8<\/td>Add your own static IP \u2014 never ban yourself<\/td><\/tr>
    backend<\/code><\/td>auto<\/td>systemd<\/code> reads from journald, immune to log rotation issues<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Lock down SSH without locking yourself out<\/h2>\n\n\n\n
      \n
    1. Whitelist your static IP first. In \/etc\/fail2ban\/jail.local<\/code>, set ignoreip = 127.0.0.1\/8 ::1 203.0.113.7<\/code> (replace with your real IP) under the [sshd]<\/code> section.<\/li>\n
    2. Restart the service: sudo systemctl restart fail2ban<\/code><\/li>\n
    3. Verify the jail is loaded: sudo fail2ban-client status sshd<\/code><\/li>\n
    4. Test a ban manually: sudo fail2ban-client set sshd banip 198.51.100.23<\/code>, then sudo fail2ban-client set sshd unbanip 198.51.100.23<\/code>.<\/li>\n
    5. Optional: set bantime.increment = true<\/code> so repeat offenders get progressively longer bans.<\/li>\n<\/ol>\n\n\n\n

      Two extra steps make SSH much quieter: switch to key-based authentication and set PasswordAuthentication no<\/code> in \/etc\/ssh\/sshd_config<\/code>. Fail2ban then only needs to cover the remaining fallback paths, and the volume of log noise drops sharply. If you administer many servers from one office IP, keep that IP in ignoreip<\/code> on every host.<\/p>\n\n\n\n

      Protect web logins too<\/h2>\n\n\n\n

      SSH is not the only brute-force target. WordPress, phpMyAdmin, and other web logins get hammered as well, and fail2ban ships jails for the common cases:<\/p>\n\n\n\n