if I understand correctly @jinnatar , you suggest trying to preform health checks by connecting to address and checking for a banner?
@TwiN is it supposed to deprecate ssh with authentication health checks or as an additional field in the config file?
I wouldn't mind trying to solve this issue if no one is working on it.

That was my initial idea of what would be a reasonable check if auth won't even be attempted. It could however just as well be a standlone TCP check with config options for command to send and allowlist & denylist matching for banner content.

As an example of a second use case, just now I'm trying to monitor an uppity NUT daemon that occasionally just stops communicating with the UPS which is obvious from a very basic call LIST UPS, but does require you to send, receive & text match the received data.

So long answer short, it may not make sense to modify the ssh check, but instead modify the tcp check which would solve a whole class of similar issues.

@jinnatar maybe it should be opened as a separate issue since it seems that a generalized solution will be more complex, however the "no auth attempt" use case might be common enough that it will be worth to implement, even if it will be removed in a different update.

Hm, would it be possible to use the no-auth approach automatically if no username/password are provided?

@TwiN I think we could,
we would have to change the way ssh is currently validated, since no username and password would be okay.
also, we would have to change the behavior of handling SSH type, in the following block:

since we wouldn't be connected to it, we wouldn't be able to execute commands inside the shell, meaning we would have to check for username and password early and handle a health check to the endpoint and return.

I wonder how nice this would play with something like Fail-2-Ban. You might get failures because its banned the IP you check from.

A quick scan through some fail2ban discussions seems to indicate a closed connection without auth would not trip by default, but probably would trip if set to agressive mode. I'd say it would be worth a caution line in documentation that agressive fail2ban configs may be tripped by testing that does not attempt to auth.

that said too, if the IP is also known for the Gatus checking server a white list could be added if they are in aggressive mode

@jinnatar @stuartskelton I wouldn't mind adding to the documentation on my PR, as I am not familiar with fail2ban, is it something that justifies a note on the docs?
also, @TwiN let me know if it falls under the documentation scope and I'll include it, I've already made a PR but I would add that.

I think something in the docs to remind people SSH limiting and Tar pitting is a still a thing. UFW (the firewall in Ubuntu) can also apply limit on ssh connections. Something generic like, If you are using SSH brute force protection software like Fail2Ban or some firewalls (e.g. UFW in limit mode), you may encounter false negatives in some cases. To avoid this, consider reviewing and adjusting your settings.