I get that. We use fail2ban here because we've a number of ways people
can connect to our systems so we needed something that was more
flexible. It's also nice that it just bans the IP so it can't keep
hammering the service.
I think it depends on your use case. That said, I understand why some
people might not want to use yet another process when all they are
trying to do is ban people spamming your sshd process. No promises but
we can look into it. I don't think the actually banning part would be
all that hard. It's everything that goes along with it in terms of
managing things and making sure it would be performant enough in high
volume scenarios.
On 10/18/23 2:34 PM, Thomas Köller wrote:
Am 18.10.23 um 20:12 schrieb Chris Rapier:
That's a good idea but I think fail2ban might be a better solution to
this than extending the application itself. The main issue being that
maintaining and managing a blocklist like that within ssh might be
cumbersome in large organizations.
AFAIK fail2ban works by scanning through the logs periodically, which
IMO is a really clumsy solution.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
