Why does denyhosts `hosts-restricted` file have contents when there are no `restricted-usernames`?

Question

I have a user that is getting blocked by denyhosts on a daily basis after some initial problems and confusion with keys, passwords, account names and such, even though I keep unblocking him.

When I went to /var/lib/denyhosts (WORKDIR specified in /etc/denyhosts.conf) and inspected the files for his IP, I found him in hosts, hosts-root, hosts-valid, users-hosts and hosts-restricted. Now, if I understand correctly, hosts-restricted is the landing place for those who get blocked by repeatedly logging in as one of the users listed in /var/lib/denyhosts/restricted-usernames... but I never created such a file, and reading the docs failed to uncover a default list that would be in use if that file did not exist.

How did my user manage to get himself on the restricted login list if no logins are restricted?

Answer 1

The contents of your hosts-restricted file likely have all of their counts set to zero, the second field in a row, and are therefore almost worthless.

I think the reason this happens (and probably the reason all /var/lib/denyhosts/hosts* have a similar size) appears to be to do with the AGE_RESET_* configs; the date will be the last time that host was seen.

Potentially this is a bug, but perhaps a harmless one (other than wasting CPU), the code should probably check to see if the host already exists in the file (python set) before creating and initializing count to zero.

Further investigation shows bug(s) in the defunct DenyHosts SF project have been logged.

Even more investigation suggests that that SF DenyHosts was forked to SF denyhost and that denyhosts on GitHub may even be the source of the most up to date code. A version 3.0 was released on this year Jun 27 which is alleged to fix this strangeness.

Yet more info: The strangeness appears to still occur in the current 3.0 version and a bug has been logged in the active GH issue tracker.