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]'
