Arch Linux

Unfortunately, upstream changed the behavior of -b so that it now accepts an optional argument.

Really wish they wouldn't do this....

I've changed sshguard-journalctl usage:

sshguard-journalctl <sshguard's-db> [journalctl-match1 [journalctl-match2 [...]]]

sshguard-1.5-14 should work

@sergej: The filter that you have set in the unit file is not good IMHO. You are still filtering for facilities 4 and 10 like before but you are also restricting to log entries from sshd only.

This does not solve abdo's problem that claims that sshd logs are assigned to facility 5 (not verified here, on systemd 204 they are still on facilities 4 and 10) and it prevents sshguard from analysing logs from other daemons (eg: vsftp, exim and so on...)

BTW if the logs are really going to facility 5 (syslog internals) instead of 4 and 10 (auth and authpriv) like they should, then the bug is probably either in journald or openssh, not in sshguard.

> it prevents sshguard from analysing logs from other daemons

Yes, but now filter is in .service file which can be copied to /etc/systemd/ and modified. Probably it is not the best solution.

I know, and it would have been fine by me if not for the fact that right now SYSLOG_IDENTIFIER=sshd appended to the previous filters does not achieve anything for anyone because abdo's issue would require removing the SYSLOG_FACILITY filters anyway.

I think it would be best to leave the SYSLOG_FACILITY=4 SYSLOG_FACILITY=10 as they were before and with your solution anyone can still remove them and put something else in their place. The wrong facility issue should be investigated separately.

I've looked into the FACILITY issue and it is indeed related to systemd 206. Downgrading to systemd 204 solves the problem. It is worth noting that both facilities were increased by one, so logs that should have been in facility 4 are now facility 5 and facility 10 became 11.

I'm filing a new bug against systemd and I think this can be closed.

> it prevents sshguard from analysing logs from other daemons

@sergej journalctl syntax is weird. When matching for thifferent values of the same field, like SYSLOG_FACILITY=4 SYSLOG_FACILITY=10 they are combined as OR. Otherwise, if the key is different, like SYSLOG_FACILITY=10 SYSLOG_IDENTIFIER=sshd they are combined as AND (WTF?!). To force OR you should add a + in between:

sshguard_journalctl ... SYSLOG_FACILITY=4 SYSLOG_FACILITY=10 + SYSLOG_IDENTIFIER=sshd

Here is a piece of the output from
journalctl SYSLOG_IDENTIFIER=sshd -o verbose

PRIORITY=6
_UID=0
_GID=0
_BOOT_ID=84340610e04d4d43bf1e4bff04d99206
_MACHINE_ID=b4e6d17f67d226c25ddeec660000048f
_HOSTNAME=galois
_TRANSPORT=syslog
_CAP_EFFECTIVE=1fffffffff
SYSLOG_FACILITY=5
SYSLOG_IDENTIFIER=sshd
_COMM=sshd
[...]
MESSAGE=input_userauth_request: invalid user platic [preauth]

So yes, it does go to SYSLOG_FACILITY=5. It may be related to this bug
https://bugzilla.redhat.com/show_bug.cgi?id=988814
which seems to be fixed after 206.


> I think it would be best to leave the SYSLOG_FACILITY=4 SYSLOG_FACILITY=10 as they were before.

@mtorromeo I don't have any problem with adjusting my sshguard.service, and I understand it probably is an upstream issue. However I think sshguard should adapt, temporarily to the situation until it gets fixed upstream. Otherwise it silently stops blocking attacks for systemd 206 users!

@abdo: Yes, that seems the correct bug and yes, maybe sshguard should adapt temporarily but as you have already pointed out adding SYSLOG_IDENTIFIER=ssh won't work and that plus sign should do the trick.

> I'm filing a new bug against systemd and I think this can be closed.
Don't bother. I'm already fixing it.

@falcoindy: Too late, sorry about that. https://bugs.archlinux.org/task/36837