SSHD: Difference between "connection closed..." and "disconnected from..." in log file

Question

The sshd service on my Ubuntu server is under constant attack for various IP and user id.

According to /var/log/auth.log file, there are three different types of fails from unknown id and IP address:

• Disconnected from invalid user...
• Connection closed by invalid user...
• Connection closed by xxx.xxx.xxx.xxx

What is the difference among the three? Do any of these suggest a successful (unauthorized) login? especially the last one...

I'm assuming all of these are failed attempts, on the basis that I've configured the SSH server to require pubkey from non-LAN IP and restricted login to only one, non-root, user ID.

But, in truth, I don't know how to verify that these security precautions are set properly, if my pub-key has not been compromised or if my servers password auth mechanism has not been compromised. So I can't say for sure that these are all failed attempts.

I tried to use fail2ban to block repeat attacks from certain IP, but this was major fail. First, no quicker than 24hr later, did attacker(s) switch to rotating thru hundreds of unique IP addresses. Second (and more worryingly) fail2ban doesn't seem to acknowledge the repeat attempts that result in Connection closed by xxx.xxx.xxx.xxx.

Answer 1

The messages:

Disconnected from invalid user
Connection closed by invalid user

both indicate a failed login attempt with a username that doesn't exist on your server. The difference is just an insignificant detail in the way the connection was torn down.

A failed attempt with an existing username would instead be logged as:

Connection closed by authenticating user 

A successful login would be logged as:

Accepted publickey for

The message:

Connection closed by <ipaddress>

(without any mention of user) indicates a connection to your server's ssh port where no attempt was made to authenticate, ie. to actually log in. These are usually scans to collect open ssh ports and the ssh server version they are using in order to find servers with known vulnerabilities. Since repeating such an attempt doesn't increase the risk it doesn't make much sense for fail2ban to block them.

Answer 2

In agreements with @tilman-schmidt, just few cents from my side (regarding fail2ban etc)...

OpenSSH people continuously changing the logging behavior, so it may be not considered by fail2ban by default (it also depends on where disconnect occurs, e.g. on preauth phase or after user name gets supplied, as well as which authentication methods are allowed in your sshd as well as on the "intruder" behavior).

I'd at least set LogLevel VERBOSE in sshd_config, as described in /etc/fail2ban/filter.d/sshd.conf

Also note this answer to similar question - https://unix.stackexchange.com/questions/662946/fail2ban-regex-help-for-banning-sshd-connection-attempts/663002#663002

no quicker than 24hr later, did attacker(s) switch to rotating thru hundreds of unique IP addresses

This has nothing to do with the usage of fail2ban - the scanners, as they found the sshd listener, "published" it in some list of them, so the deeper scanning (e. g. with distributed botnets) could begin. This is the sorry fate of any server with open ports to outside.

You can try to change the ssh port to something other, but it'd just avoid the half of script kiddies (if you'd ban the port-scanning attempts) and basically not a panacea at all. But you could drastically reduce the count of intruders at least for short time up to few months. What may definitely help is to enable bantime.increment in fal2ban (for sshd jail or by default).

fail2ban doesn't seem to acknowledge the repeat attempts that result in Connection closed by

This is not quite correct. You have to set mode = aggressive for sshd jail in jail.local to allow fail2ban consider any kind of "attack" (not the authentication issues only), also occurring by port scanners and DoS-similar stuff.

And you can see what exactly would be found by fail2ban with your current filter with this command (note matched in last line from result):

fail2ban-regex /var/log/auth.log 'sshd[mode=aggressive]'