(sorry if this doesn't show up in thread - I had digest mode turned on, so I haven't gotten your reply yet)

yeah -- weird one... did you try running them one by one in a terminal?

yeah I did that first, and I am getting some dbus "access denied error" that I don't have the "know how" to debug (some quick googling didn't help):

[erick@dev1 ~]$ sudo -u fail2ban firewall-cmd --direct --remove-rule ipv4 filter INPUT_direct 0 -p tcp -m multiport --dports 2222 -m set --match-set fail2ban-SSH src -j REJECT --reject-with icmp-port-unreachable[sudo] password for erick: 
ERROR:dbus.proxies:Introspect error on :1.252:/org/fedoraproject/FirewallD1: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.373" (uid=200 pid=3910 comm="/usr/bin/python -Es /bin/firewall-cmd --direct --r") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination=":1.252" (uid=0 pid=29630 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")

but works fine when I run as a regular sudo command

[erick@dev1 ~]$ sudo firewall-cmd --direct --remove-rule ipv4 filter INPUT_direct 0 -p tcp -m multiport --dports 2222 -m set --match-set fail2ban-SSH src -j REJECT --reject-with icmp-port-unreachable
success

what is really strange though, is if I run the add rule command I get the same error, but this is definitely working on service start

[erick@dev1 ~]$ sudo -u fail2ban firewall-cmd --direct --add-rule ipv4 filter INPUT_direct 0 -p tcp -m multiport --dports 2222 -m set --match-set fail2ban-SSH src -j REJECT --reject-with icmp-port-unreachableERROR:dbus.proxies:Introspect error on :1.252:/org/fedoraproject/FirewallD1: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.375" (uid=200 pid=3915 comm="/usr/bin/python -Es /bin/firewall-cmd --direct --a") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination=":1.252" (uid=0 pid=29630 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -")

this makes me question how the start-up case works at all.

wild guess is that sudo call
doesn't match defined in sudoers so it tries to ask for the password but
fails

that was my thought too, but I tried debugging by copying the exact command into the to sudoers.d config file and get the same result

lso -- have you seen

https://github.com/fail2ban/fail2ban/blob/HEAD/doc/run-rootless.txt

I did see that but I'm using firewalld and am not familiar with xt_recent, and if it's even a CentOS 7 thing? or just a debian thing? basically I tried choosing an approach that I was more comfortable maintaining.

I tested whether banning IPs actually works last night and it seems fine. I guess other than ugliness in the logs, leaving the filter-chain around on service shutdown (which I don't see myself doing), and leaving banned users banned... there doesn't seem to be a major problem? I can live w/ the ugliness and move on

is there another problem I might be overlooking leaving as is?

Thanks

Erick