Potential Bug in "Others/System and Server Status" - Remote SSH monitor insists on trying to log in regardless of configuration

Pretty much what it says in the title. I have multiple publicly accessible VPS servers and a private, home server sitting behind a prosumer grade nat firewall. I’ve configured the home server to query the opensshd on each of my VPS using the “remote ssh” monitor type and, if it can reach an sshd login prompt, terminate and report success. I have “Login as User” left blank and “Login with Password” set to “Don’t try to login”.

My sshd on each VPS is hidden behind a Netfilter firewall that only allows access to whitelisted IPs. So imagine my surprise when I discovered hundreds of these a day after setting up this monitor:

Sep 13 12:49:51 [VPS-HOST] sshd[8285]: Failed none for invalid user root from [MY-HOME-IP] port 49232 ssh2 Sep 13 12:49:51 [VPS-HOST] sshd[8285]: Failed password for invalid user root from [MY-HOME-IP] port 49232 ssh2 Sep 13 12:50:08 [VPS-HOST] sshd[8942]: User root from [MY-HOME-IP] not allowed because none of user's groups are listed in AllowGroups Sep 13 12:50:08 [VPS-HOST] sshd[8942]: input_userauth_request: invalid user root [preauth] Sep 13 12:50:08 [VPS-HOST] sshd[8942]: Postponed keyboard-interactive for invalid user root from [MY-HOME-IP] port 49242 ssh2 [preauth] Sep 13 12:50:08 [VPS-HOST] sshd[8944]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=[MY-HOME-IP] user=root Sep 13 12:50:10 [VPS-HOST] sshd[8942]: error: PAM: Authentication failure for illegal user root from [MY-HOME-IP] Sep 13 12:50:10 [VPS-HOST] sshd[8942]: Failed keyboard-interactive/pam for invalid user root from [MY-HOME-IP] port 49242 ssh2 Sep 13 12:50:10 [VPS-HOST] sshd[8942]: Connection closed by [MY-HOME-IP] port 49242 [preauth] .

After ruling out IP spoofing. I tested and confirmed the log messages are being triggered by the “Remote SSH” monitor type I had previously configured. This, inspite of the monitor being configured not to attempt to log in. The problem for me is it could mask an actual bruteforce attack if someone did figure out my ip address and manage to spoof it. As such I’ve disabled the monitor pending resolution of the issue.

Am I missing something or is this a bug?

I could configure a dummy user and give the monitor the credentials for that… but I intend to disable password auth entirely in the near future in favor of two-factor auth using per-user public-private key-pairs and per-user TOTP. The former does not appear to be supported by the “Remote SSH” monitor and the latter is impossible to support in an automated fashion (at least without rendering it exploitable). Thus, to use this monitor, it must work without requiring a login attempt.

Looks bug-like, to me. File a ticket, and Jamie will get it sorted.