Bug #9971
closed
sshguard error: Logging subprocess <pid> (exec /usr/local/sbin/sshguard) exited with status 1.
Added by Jim Pingle almost 5 years ago.
Updated almost 5 years ago.
Affected Architecture:
All
Description
sshguard logs an error repeatedly on recent snapshots:
Dec 16 15:52:35 pfsense syslogd: Logging subprocess 63382 (exec /usr/local/sbin/sshguard) exited with status 1.
/usr/local/etc/sshguard.conf:
BACKEND="/usr/local/libexec/sshg-fw-pf"
: grep sshguard /var/etc/syslog.d/pfSense.conf
auth.info;authpriv.info |exec /usr/local/sbin/sshguard
A user on the forum noted that the log messages may indicate a missing required option in /usr/local/etc/sshguard.conf: https://forum.netgate.com/topic/148978/sshguard-exiting-with-status-1
- Assignee changed from Jim Pingle to Renato Botelho
Looks like in https://bitbucket.org/sshguard/sshguard/commits/600ce84ff6ab745d5507b3b147f37890a1451a7e they changed it to require either FILES or LOGREADER, though we feed it via syslog (stdin).
So perhaps we have two ways forward:
1. Remove it from syslog.conf and have it monitor /var/log/auth.log directly
2. Patch out the error/exit that is complaining about the config.
If pfSense 2.4.5 snapshots have sshguard 2.4.0 as well then the fix will need to happen there in addition to pfSense 2.5.0
- Target version changed from 2.5.0 to 2.4.5
- Affected Version changed from 2.5.0 to 2.4.5
Since 2.4.5 is still using clog, at least there the only option appears to be patching out the error/exit.
I took another run at this and found a potential fix without patching too much in sshguard. We can set LOGREADER to /bin/cat and pass it a PID file to make it a little happier, but that alone isn't enough. We have to change the last couple lines back to the old version.
system.inc diff:
diff --git a/src/etc/inc/system.inc b/src/etc/inc/system.inc
index e945d37637..b5e61321cd 100644
--- a/src/etc/inc/system.inc
+++ b/src/etc/inc/system.inc
@@ -1050,7 +1050,7 @@ local4.* {$log_directive}{$g['varlog_path']}/portalauth.log
local5.* {$log_directive}{$g['varlog_path']}/nginx.log
local7.* {$log_directive}{$g['varlog_path']}/dhcpd.log
*.notice;kern.debug;lpr.info;mail.crit;daemon.none;news.err;local0.none;local3.none;local4.none;local7.none;security.*;auth.info;authpriv.info;daemon.info {$log_directive}{$g['varlog_path']}/system.log
-auth.info;authpriv.info |exec /usr/local/sbin/sshguard
+auth.info;authpriv.info |exec /usr/local/sbin/sshguard -i /var/run/sshguard.pid
*.emerg *
EOD;
@@ -1139,6 +1139,7 @@ EOD;
}
$sshguard_config = array();
+ $sshguard_config[] = 'LOGREADER="/bin/cat"' . "\n";
$sshguard_config[] = 'BACKEND="/usr/local/libexec/sshg-fw-pf"' . "\n";
if (!empty($config['system']['sshguard_threshold'])) {
$sshguard_config[] = 'THRESHOLD=' .
sshguard diff:
--- /usr/local/sbin/sshguard.orig 2020-01-03 11:12:02.896999111 -0500
+++ /usr/local/sbin/sshguard 2020-01-03 11:12:14.393207610 -0500
@@ -105,5 +105,4 @@
trap "kill 0" EXIT
eval $tailcmd | $libexec/sshg-parser | \
- $libexec/sshg-blocker $flags | $BACKEND &
-wait
+ $libexec/sshg-blocker $flags | ($BACKEND ; pkill -PIPE -P $$)
With those changes on 2.4.5, sshguard properly detected and blocked attacks as expected.
- Status changed from New to In Progress
- Assignee changed from Renato Botelho to Jim Pingle
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Pushed the changes to RELENG_2_4_5 and a variation of the same to master. Note that this needs to be tested on both 2.4.5 and 2.5.0 separately since each branch required different changes.
sshguard does not like the RFC 5424 log format, however, I'll open a separate issue for that since it's not directly related to this problem. It works fine with the default RFC 3164 format.
Verified old behavior before upgrade.
Verified erroneous log messages are gone and sshguard properly blocks both webgui and ssh connections based on invalid attempts on either service.
Block was removed after the appropriate interval.
Looks good on 2.4.5-DEV.
Verified old behavior before upgrade.
Verified erroneous log messages are gone and sshguard properly blocks both webgui and ssh connections based on invalid attempts on either service.
Block was removed after the appropriate interval.
Looks good on 2.5.0-DEV.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF