How to protect SSH server from brute force attacks using fail2ban

One common attack on SSH service is brute force attacks where a remote attacker indefinitely attempts to log in with different passwords. Of course there are arguments against password authentication for SSH, and alternative authentication mechanisms such as public key authentication or two-factor authentication exist to obsolete such attacks. Putting aside pros and cons of different authentication methods, let's consider the situation where password authentication is required. How would you protect your SSH server against brute-force attacks?

fail2ban is a well-known open-source intrusion prevention framework on Linux that monitors various system log files (e.g., /var/log/auth.log or /var/log/secure) and automatically triggers various defensive actions upon detecting any suspicious activities. In fact, fail2ban can be quite useful to defend against brute force password guessing attacks on an SSH server.

In this guide, I will demonstrate how to install and configure fail2ban to protect an SSH server against brute force attacks from a remote IP address.

Install Fail2ban on Linux

To install fail2ban on CentOS or RHEL, first set up EPEL repository, and then run the following command.

$ sudo yum install fail2ban

To install fail2ban on Fedora, simply run:

$ sudo yum install fail2ban

To install fail2ban on Ubuntu, Debian or Linux Mint:

$ sudo apt-get install fail2ban

Configure Fail2ban for SSH Server

Now you are ready to configure fail2ban to harden your SSH server. You need to edit the configuration file at /etc/fail2ban/jail.conf. The configuration file contains "DEFAULT" section where you define default parameters for all monitored services, and service-specific sections where you define any service-specific jails (e.g., SSH, Apache, etc) to overwrite default parameters.

In the service-specific jail sections (somewhere after [DEFAULT] section), you need to define [ssh-iptables] section, where you define SSH-specific jail configurations. Actual IP address banning is done by iptables.

The following is an example of /etc/fail2ban/jail.conf which contains "ssh-iptables" jail configuration. Of course there could be other application-specific jails depending on your needs.

$ sudo vi /etc/fail2ban/jail.local
# a space delimited list of IP addresses, CIDR prefixes, or DNS hostnames
# to bypass fail2ban protection
ignoreip =

# number of seconds during which a client host is blocked
bantime = 86400

# number of failures before a client host is blocked
maxretry = 5

# number of seconds within which "maxentry" failures result in banning
findtime = 600

mta = sendmail

enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
# for Debian-based distros
logpath = /var/log/auth.log
# for Red Hat-based distros
logpath = /var/log/secure
# ssh-specific max-retry threshold
maxretry = 3

According to the above configuration, fail2ban will automatically ban any remote IP address from which there have been at least 3 failed login attempts within the last 10 minutes. Once banned, the offending IP address will remain blocked for 24 hours. Such an event will be notified by sendemail to a recipient email address.

Once the configuration file is ready, restart fail2ban service as follows.

On Debian, Ubuntu or CentOS/RHEL 6:

$ sudo service fail2ban restart

On Fedora or CentOS/RHEL 7:

$ sudo systemctl restart fail2ban

To verify fail2ban is running successfully, run fail2ban-client command with "ping" argument. If fail2ban service is running okay, you should see "pong" as a response.

$ sudo fail2ban-client ping
Server replied: pong

Test Protection against SSH Brute-Force Attacks with Fail2ban

To test whether fail2ban works, try to SSH to the server using incorrect passwords to simulate a brute-force attack. In the mean time, monitor /var/log/fail2ban.log, which is logging any interesting events that are happening in fail2ban.

$ sudo tail -f /var/log/fail2ban.log

According to the log file above, fail2ban has banned an IP address, upon detecting multiple failed SSH login attempts from the IP address.

Check Fail2ban Status and Unban Blocked IP Addresses

As fail2ban's "ssh-iptables" jail uses iptables to block offending IP addresses, you can easily verify the ban by checking current iptables rules as follows.

$ sudo iptables --list -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-SSH  tcp  --             tcp dpt:22

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-SSH (1 references)
target     prot opt source               destination
DROP       all  --
RETURN     all  --  

If you want to unblock the IP address from fail2ban, you can also use iptables command:

$ sudo iptables -D fail2ban-SSH -s -j DROP

While you can check and manage fail2ban's IP blocklist manually with iptables command like above, a proper way is in fact to use fail2ban-client command-line tool. This tool allows you to manage not only "ssh-iptables" jail, but also any other types of fail2ban jails in a unified command-line interface.

To check fail2ban status (which will show a list of currently active jails):

$ sudo fail2ban-client status

To check the status of a particular jail (e.g., ssh-iptables):

$ sudo fail2ban-client status ssh-iptables

The above command will show a list of banned IP addresses.

To unban a particular IP address:

$ sudo fail2ban-client set ssh-iptables unbanip

Note that if you stop fail2ban, all blocked IP addresses will be unblocked. When you restart fail2ban, it will find a list of offending IP addresses from /var/log/secure (or /var/log/auth.log), and re-ban those IP addresses if the elapsed time of the offenses are still within ban time.

Set Fail2ban to Auto-start on Boot

Once you haved tested fail2ban successfully, the last step is to enable fail2ban to launch automatically upon powering on your server. On Debian-based distributions, fail2ban auto-start is enabled by default. On Red Hat-based distributions, enable auto-start as follows.

On CentOS/RHEL 6:

$ sudo chkconfig fail2ban on

On Fedora or CentOS/RHEL 7:

$ sudo systemctl enable fail2ban


In this tutorial, I demonstrated how to install and configure fail2ban to protect an SSH server. While fail2ban can mitigate brute-force password guessing attacks, please note that it cannot protect SSH servers against sophisticated distributed brute-force campaigns, where an attacker bypasses fail2ban by using many thousands of bot-controlled IP addresses.

Subscribe to Xmodulo

Do you want to receive Linux FAQs, detailed tutorials and tips published at Xmodulo? Enter your email address below, and we will deliver our Linux posts straight to your email box, for free. Delivery powered by Google Feedburner.

Support Xmodulo

Did you find this tutorial helpful? Then please be generous and support Xmodulo!

The following two tabs change content below.
Dan Nanni is the founder and also a regular contributor of He is a Linux/FOSS enthusiast who loves to get his hands dirty with his Linux box. He likes to procrastinate when he is supposed to be busy and productive. When he is otherwise free, he likes to watch movies and shop for the coolest gadgets.

21 thoughts on “How to protect SSH server from brute force attacks using fail2ban

  1. I ran multiple hosts, one a honeypot to detect and initiate blocking at my router. This looks less satisfying, but far easier.

  2. I always install Fail2ban DIRECTLY when I receive a hosted server...

    But, what is the difference between
    - bantime
    - findtime ?

    I always use only bantime.

  3. I tweaked my firewall - max x attempts in 60 issues since. Keys instead of passwords of course. :)

  4. I have been using fail2ban for years. You should install it on any computer that has an SSH port exposed to the internet. You can generally just set it up and forget about it.

  5. fail2ban and denyhosts log AND BLOCK IP addresses that failed to login, even on other servers using them (worldwide database updates).

  6. I am using failban 0.8.6-3 on Ubuntu 12.04.5 LTS and set/get commands are not implemented.
    For example, if I run
    fail2ban-client set ssh-root unbanip
    I get
    Invalid command (no set action or not yet implemented)

  7. I think I prefer to require certificates and disable password. Makes brute force a lot more interesting. I also prevent shell for any system accounts which also makes it more challenging.

  8. I would never allowed SSH login to be password only. SSH should be configured to connect using certificates only. There are known botnets that will try to login your server once every 1min using different IP each time and there is not effective way to prevent such.

  9. Arno's IPTABLES firewall seem an interesting script, thanks for sharing this info.
    Fail2ban works also with IPTABLES firewall to reject the IP addresses, so personally I work with Fail2ban and Shorewall to handle IPTABLES rules. is a gateway/firewall configuration tool for GNU/Linux, "Iptables made easy".
    I'm planning to test Arno's IPTABLES.

  10. Out of curiosity, is there a way to make fail2ban fire when you're using certificate-only logins? One of our boxes gets a ton of

    Mar 25 11:05:16 sshd[15824]: Received disconnect from 11: [preauth]
    Mar 25 11:05:18 sshd[15829]: Received disconnect from 11: [preauth]
    Mar 25 11:05:24 sshd[15834]: Received disconnect from 11: [preauth]
    Mar 25 11:05:29 sshd[15839]: Received disconnect from 11: [preauth]
    Mar 25 11:05:30 sshd[15844]: Received disconnect from 11: [preauth]
    Mar 25 11:05:31 sshd[15849]: Received disconnect from 11: [preauth]
    Mar 25 11:05:32 sshd[15854]: Received disconnect from 11: [preauth]

    and it'd be really nice to be able to have it block things like this too, rather than just failed "interactive" logins.

    • If you want to block ssh access when using keys (or even when you're not using keys) then you have to try port knocking, I guess is more secure because any port analyzer could not see that your server has ssh port 'till you send the corrrect packages sequence. It's very useful

Leave a comment

Your email address will not be published. Required fields are marked *