Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Right, so if I can only SSH into my box by having the appropriate RSA keys configured, is there any point in using Denyhosts for SSH as well? Or is Denyhosts only looking at keyboard-interactive / password logins for SSH?

Don't get me wrong, Denyhosts is the absolute mac-daddy, but I've recently switched off keyboard-interactive logins altogether and wondered if it was worth still keeping Denyhosts running.

(If you don't know Denyhosts, it basically maintains - and uses - an IP blacklist of people who keep trying to get into SSH but with the wrong username / password etc.)

share|improve this question
up vote 4 down vote accepted

By my read of it, there are two reasons to continue using DenyHosts:

  1. Failed-login processing still takes resources, so using it keeps that lower.
  2. Your log-files with DenyHosts will be a lot smaller than your log-files without it.

If either of those don't really matter to you, then DenyHosts isn't doing anything for you.

share|improve this answer
So, basically, when a keyboard login is attempted and the user is presented with "access denied" (or whatever), Denyhosts is still going to count it as a login attempt? Hmmm, that could work... – Dougal Aug 7 '11 at 16:45

It minimizes the "bad actor/person" from slamming additional resources.

share|improve this answer
Don't understand this answer :( – Dougal Aug 7 '11 at 12:36
@Dougal, It is the same thing as what sysadmin1138 said, but not as clear. :) – snap Aug 7 '11 at 15:27
It spare the ssh daemon/process from having to deal with/process any additional attacks from the listed IP address. – user48838 Aug 7 '11 at 19:17
aaah, ok, cool. – Dougal Aug 8 '11 at 14:23

Depends on the other services running on that box. If it's a webserver with an online store, you might be losing business because of an incorrectly denied host - though this seems unlikely, especially if you're only using your own denyhost data.

On the other hand, if you're running other services that might be less secure than your locked down ssh server - it may be worth keeping the deny to protect your other services if the attacker tires of your ssh, or indeed if you ARE using shared data.

Long and the short, if you have no worry about false positives (eg. the people who might fail to access the server have another way to contact you, and it won't harm any relationship with them!) then there's no reason not to keep denying hosts. Also its fun ;)

share|improve this answer
a) The default denyhosts.conf only creates entries for sshd. b) How many other applicable daemons even read /etc/hosts.deny (or equivalent)? – andol Aug 7 '11 at 13:28
Incorrect answer methinks :-/ – Dougal Aug 8 '11 at 14:23

To add to the other answers, there is one word of caution I have encountered (in the form of a notice on the ArchWiki) when reading about tools like denyhosts (e.g. Fail2ban):

Warning: Using an IP blacklist will stop trivial attacks but it relies on an additional daemon and successful logging (the partition containing /var can become full, especially if an attacker is pounding on the server). Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server. ...

So especially if you're only allowing public-key authentication it may be worth considering just using a non-standard port (to avoid blind attacks on port 22) and intentionally not using denyhosts.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.