sshd filter doesn't ban repeated failed publickey attempts

[jeanmonet]

Environment:

• Fail2Ban version (including any possible distribution suffixes): v0.11.1
• OS, including release name/version: Ubuntu 20.04 LTS
• Fail2Ban installed via OS/distribution mechanisms
• You have not applied any additional foreign patches to the codebase
• Some customizations were done to the configuration (provide details below is so)

The issue:

The ssh server is set to only allow passkey authentication (sshd_config: AuthenticationMethods publickey and PasswordAuthentication no).

The sshd filter doesn't seem to ban repeated Failed publickey attempts.

However, if I try to login with a wrong username, the ban is correctly enforced by the sshd filter.

Steps to reproduce

ssh user_name@server -i ~/.ssh/wrong_key_file
...
# Permission denied (publickey).
# Permission denied (publickey).
# Permission denied (publickey).
# Permission denied (publickey).
# Permission denied (publickey).
# Permission denied (publickey).
# Permission denied (publickey).
# Permission denied (publickey).

Expected behavior

Would have expected the sshd filter to be activated in case of multiple failed publickey attempts.

Observed behavior

The filter does not match the login behavior.

Relevant lines from monitored log files in question:

Jun 25 21:52:16 nc-ass-vip sshd[4179]: Connection closed by authenticating user user_name 192.168.0.26 port 54695 [preauth]
Jun 25 21:52:16 nc-ass-vip sshd[4181]: Connection from 192.168.0.26 port 54696 on 192.168.0.36 port 22 rdomain ""
Jun 25 21:52:16 nc-ass-vip sshd[4181]: Failed publickey for user_name from 192.168.0.26 port 54696 ssh2: ED25519 SHA256:xxx
Jun 25 21:52:16 nc-ass-vip sshd[4181]: Connection closed by authenticating user user_name 192.168.0.26 port 54696 [preauth]
Jun 25 21:52:16 nc-ass-vip sshd[4183]: Connection from 192.168.0.26 port 54697 on 192.168.0.36 port 22 rdomain ""
Jun 25 21:52:16 nc-ass-vip sshd[4183]: Failed publickey for user_name from 192.168.0.26 port 54697 ssh2: ED25519 SHA256:xxx
Jun 25 21:52:16 nc-ass-vip sshd[4183]: Connection closed by authenticating user user_name 192.168.0.26 port 54697 [preauth]
Jun 25 21:52:17 nc-ass-vip sshd[4185]: Connection from 192.168.0.26 port 54698 on 192.168.0.36 port 22 rdomain ""
Jun 25 21:52:17 nc-ass-vip sshd[4185]: Failed publickey for user_name from 192.168.0.26 port 54698 ssh2: ED25519 SHA256:xxx
Jun 25 21:52:17 nc-ass-vip sshd[4185]: Connection closed by authenticating user user_name 192.168.0.26 port 54698 [preauth]
Jun 25 21:52:22 nc-ass-vip sshd[4189]: Connection from 192.168.0.26 port 54700 on 192.168.0.36 port 22 rdomain ""
Jun 25 21:52:22 nc-ass-vip sshd[4189]: Failed publickey for user_name from 192.168.0.26 port 54700 ssh2: ED25519 SHA256:xxx

[sebres]

There are already several issues like this...
See for instance #2726 (comment), #2188 (comment), #1477 (comment), etc.

Shortly - it's not really a bug, and...
Normally I had nothing to add here, but... for my taste there are really too many issues to the subject.

Although since 9137c7b (not yet released in 0.11.1) the filter gets extended with parameter publickey, that could switch behavior on "Failed publickey" messages:

• nofail (default) - consider failed publickey (legitimate users) as no failure (helper to get IP and user-name only)
• invalid - consider failed publickey for invalid users only;
• any - consider failed publickey for valid users too;
• ignore - ignore "Failed publickey ..." failures (don't consider failed publickey at all)

But as one can see per default it's still nofail to be backwards-compatible (and avoid false positives by authorizing with multiple public keys). So this messages are recognizes as failure only if it'd be followed by other failures (which you did not have in mode normal).
In your case you could choice between mode = ddos or mode = aggressive in sshd jail to consider Connection closed by authenticating user as a failure.

Here are different variants how current version of the filter behaves on your log-excerpt, depending on filter parameters:

$ fail2ban-regex -o row /tmp/gh-2765.txt sshd;                    # default

$ fail2ban-regex -o row /tmp/gh-2765.txt 'sshd[mode=aggressive]'; # closed on auth phase (without accept)
['192.168.0.26',        1593114736.0,   {'mlfid': u' nc-ass-vip sshd[4179]: ', 'ip4': u'192.168.0.26', 'user': u'user_name', 'ip6': None, 'dns': None}],
['192.168.0.26',        1593114736.0,   {'mlfid': u' nc-ass-vip sshd[4181]: ', 'ip4': u'192.168.0.26', 'user': u'user_name', 'users': set([u'user_name']), 'cond_user': u'user_name', 'ip6': None, 'dns': None}],
['192.168.0.26',        1593114736.0,   {'mlfid': u' nc-ass-vip sshd[4183]: ', 'ip4': u'192.168.0.26', 'user': u'user_name', 'users': set([u'user_name']), 'cond_user': u'user_name', 'ip6': None, 'dns': None}],
['192.168.0.26',        1593114737.0,   {'mlfid': u' nc-ass-vip sshd[4185]: ', 'ip4': u'192.168.0.26', 'user': u'user_name', 'users': set([u'user_name']), 'cond_user': u'user_name', 'ip6': None, 'dns': None}],

$ fail2ban-regex -o row /tmp/gh-2765.txt 'sshd[publickey=any]';   # any kind of public key auth (new version only)
['192.168.0.26',        1593114736.0,   {'mlfid': u' nc-ass-vip sshd[4181]: ', 'ip4': u'192.168.0.26', 'user': u'user_name', 'users': set([u'user_name']), 'cond_user': u'user_name', 'ip6': None, 'dns': None}],
['192.168.0.26',        1593114736.0,   {'mlfid': u' nc-ass-vip sshd[4183]: ', 'ip4': u'192.168.0.26', 'user': u'user_name', 'users': set([u'user_name']), 'cond_user': u'user_name', 'ip6': None, 'dns': None}],
['192.168.0.26',        1593114737.0,   {'mlfid': u' nc-ass-vip sshd[4185]: ', 'ip4': u'192.168.0.26', 'user': u'user_name', 'users': set([u'user_name']), 'cond_user': u'user_name', 'ip6': None, 'dns': None}],
['192.168.0.26',        1593114742.0,   {'mlfid': u' nc-ass-vip sshd[4189]: ', 'ip4': u'192.168.0.26', 'user': u'user_name', 'users': set([u'user_name']), 'cond_user': u'user_name', 'ip6': None, 'dns': None}],

I must admit we should rethink about default handling on public key failures (e. g. publickey parameter) or some other strategy considering Failed publickey together with Connection closed by authenticating user as a failure in normal case.

[jeanmonet]

Thank you for your comprehensive answer, I didn't initially find the previous issues on this topic that you pointed out.

Will wait for the newer fail2ban version to become available on Ubuntu 20.04 LTS in order to use the publickey parameter for the sshd filter.

In the meantime I went for mode = aggressive, which, as you explained, successfully blocks failed publickey attempts on existing users.