Smart Doorkeeper
Charly's Column – DenyHosts
When it comes to warding off unwanted login tests on SSH port 22 and others, Charly likes to keep an ace or two up his sleeve by relying on DenyHosts instead of Fail2ban.
Many sys admins use Fail2ban to keep unwanted login tests on SSH port 22 and others at bay. However, there are alternatives to Fail2ban. Today, I would like to introduce you to DenyHosts, which does basically the same thing as Fail2ban but has one or two aces up its sleeve.
You can find DenyHosts as part of the standard package on all popular distributions; my lab system is an up-to-date Debian. To install DenyHosts, type:
sudo apt install denyhosts
This is followed by the most important step of the configuration: You need to add the IP addresses of all the systems from which you want to log in to the protected system without being blocked to the /etc/hosts.allow
file (Listing 1). If you forget this step, there is a danger that you will be locked out of the system permanently – so it might be better to take another sip of coffee and check again that there are no typos.
Listing 1
hosts.allow
sshd: 10.0.0.8 sshd: 10.0.0.42 [...]
DenyHosts is controlled by the /etc/denyhosts.conf
file, which contains sensible defaults, but I'll take a closer look at some of them anyway. The most important lines in this longish configuration file are the ones where I define the number of failed attempts before the system locks out a host by applying an iptables rule. In doing so, DenyHosts takes into account whether you log in with a username that actually exists in /etc/passwd
(Listing 2). After adjusting the values to your satisfaction, it's time to put DenyHosts into operation (Listing 3).
Listing 2
denyhosts.conf
# Admissible failed attempts: # Username does not exist DENY_THRESHOLD_INVALID = 5 # Username exists DENY_THRESHOLD_VALID = 10 # Username is "root" DENY_THRESHOLD_ROOT = 1
Listing 3
Starting DenyHosts
$ sudo systemctl restart denyhosts $ sudo systemctl enable denyhosts
DenyHosts writes all activities to the /var/log/auth.log
file (Figure 1). If you exceed one of the thresholds, the IP address of the knocking system is entered in the /etc/hosts.deny
file and blocked by iptables (Figure 2). As a highlight, DenyHosts can synchronize with other servers worldwide – the settings for this can be found a bit further down in the Sync
section of the configuration file.


The fact that DenyHosts, unlike Fail2ban, does not release a blocked IP address after a certain time is seen as a disadvantage by some admins. So far, however, none of my users has managed to enter their password incorrectly more than 10 times. In the end, it depends on your personal preferences as to which of the two tools you use. I tend cautiously towards DenyHosts.
Buy this article as PDF
(incl. VAT)