Replies: 2 comments 1 reply
-
You didn't give the info what exactly should be banned... neither log-excerpt, nor what fail2ban see or not see. Also interesting is the output of fail2ban-regex (does it find matches?): # for systemd journal:
?sudo? fail2ban-regex systemd-journal sshd
# for log-file:
?sudo? fail2ban-regex /var/log/auth.log sshd
Related to #3676 your Anyway to switch to log-file monitoring, just add [sshd]
backend = auto
enabled = true (and then restart fail2ban or sshd jail)
This has probably nothing to do with issue, if fail2ban (or rather filter of sshd jail) doesn't recognize failures at all. |
Beta Was this translation helpful? Give feedback.
-
I'll try to help @Acenl12 out here. I was in the same boat with Debian 12 and fail2ban 1.0.2-2 which seems to be quite a mess on Debian 12. In any case, in Debian 12, the backend should be You'll find an error such as |
Beta Was this translation helpful? Give feedback.
-
I see a lot of connection attempts in my /var/log/auth.log, but those aren't getting banned by fail2ban on Debian 12. I tried moving the banaction to ipset but that didn't helped either.
Fail2ban version
1.0.2
It's an azure cloud vm and I had ssh wide open to the internet and literally no ip was banned
Based on my experience in the past there should be at least a couple banned
Beta Was this translation helpful? Give feedback.
All reactions