Package: fail2ban
Version: 0.8.7.1-1
The Debian filters for SSH include the following:
^%(__prefix_line)s(?:pam_unix\(sshd:auth\):\s)?authentication
failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S*
rhost=<HOST>(?:\s+user=.*)?\s*$
If users have configured more than one authentication module in PAM, e.g.
pam_unix and pam_ldap, this filter will lead to spurious "failures" being
detected: PAM will log the attempt-and-fail of pam_unix, then will move on to
the next module (e.g. pam_ldap), which may very well succeed. With this filter
in place, I get locked out of my systems after just three _perfectly
successful_ login attempts.
For example, here's a successful login in /var/log/auth.log:
Aug 23 22:01:55 tucsbuild001 sshd[48740]: Set /proc/self/oom_score_adj to 0
Aug 23 22:01:55 tucsbuild001 sshd[48740]: Connection from 9.80.89.118 port 36465
Aug 23 22:02:02 tucsbuild001 sshd[48740]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=9.80.89.118 user=davisk
Aug 23 22:02:02 tucsbuild001 sshd[48740]: Accepted password for davisk from
9.80.89.118 port 36465 ssh2
Aug 23 22:02:02 tucsbuild001 sshd[48740]: pam_unix(sshd:session): session
opened for user davisk by (uid=0)
Aug 23 22:02:02 tucsbuild001 sshd[48740]: User child is on pid 48876
Note that the successful pam_ldap module attempt doesn't even appear in the log
at all, only the preliminary "failure" from the pam_unix module does.
This bug was noticed on Ubuntu 13.04, but I'm pretty sure the problem is due to
a Debian-specific patch, introduced in Debian Bug #648020 [1]. This pattern
does not appear to be in the upstream fail2ban source code [2]. I suggest that
this pattern be removed from Debian, as well.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648020
[2] https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/sshd.conf
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
