I have configured monitoring for FreeBSD servers, and it's working correctly. The username and password work, and it correctly returns results of its scans in KNM. Despite this, once a minute, the FreeBSD server logs the error:
sshd: Did not receive identification string from [KNM server IP]
Any suggestions on why this may be occurring or how to stop it? The monitoring works so I have no complaints there, but it would be nice to not fill up the syslog with unnecessary errors.
The SSH2 server monitor checks if the SSH2 server is responding on the set port and also checks that you get a login prompt and then testing to logon. I just tested on CentOS 6.2 and it logs everything correctly for the monitor.
However, it seems that the automatic scan for monitors will render those logs though. I do get the same messages as you when setting up the object and also if I make any changs to the object and save (forces a new scan). I will check with any of the developers as soon as one is available (vacation times now) to see why the identification process seem to not be correct for the inspections.
To test if this is what's causing the logs on your end also, click Properties for the object and then click on "Advanced configuration". Check the "No inspection" checkbox and save the object. Check if you even after that get those identification errors in your sshd logs.
------------------------------------------------------------------Tomas AnderssonQuality Assurance Engineer - KNMKaseya
Looks like it's just checking for port 22 to be open on the server. The check script isn't identifying itself as a valid ssh client. That warning you see is generated when the sshd server can not read the remote client's version information.
Dan MuntzProject Manager@danmuntz
I had a TCP port scan enabled for 22, set to inverse to cause an alert if the port was closed. That is absolutely what was causing the log entry. Using the SSH2 server monitor does not cause this, nor does it seem to log anything.
Automatic scans and manual scans (like forcing a rescan of disks) causes a handful of log entries, but that's because we have pam enabled on our servers for RADIUS authentication and the KNM monitor account does not authenticate through RADIUS. The success message created is "Accepted password for [user] from [KNM server]"; this entry is just fine.
However, I did notice a series of five authentications and disconnections from the KNM account in a five second period. I have not been able to replicate this in about 20 minutes, so I'm going to call it a fluke for now.
Copyright © 2012 Kaseya International Limited. All rights reserved. Kaseya and the Kaseya k-bug logo are among the trademarks or registered trademarks owned by or licensed to Kaseya International Limited. All other brand and product names are or may be trademarks of, and are used to identify products or services of, their respective owners.