Hi. On Sun, Aug 14, 2022 at 08:57:47AM +0200, Maurizio Caloro wrote: > Thanks for you answer, yes add aggressive to mode, restart services and add > to ssh_config > > Host * > HostKeyAlgorithms +ssh-rsa,ssh-dss > PubkeyAcceptedKeyTypes +ssh-rsa,ssh-dss
Please do not do this unless you're in a corporate environment. Basically you just allowed every SSH client made in last 25 years to connect to you. A very bad idea, to say the least. In fact, I'd restrict allowed SSH algorithms like this: Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com MACs hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com KexAlgorithms curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256 Because it does not affect in any way proper OpenSSH users, and you'll probably want all those annoying bots to fail to connect. Windows users will suffer, but that's their fate anyway :) > But still auth logs everysecond with: > > Aug 14 08:53:20 lenovo sshd[270588]: Unable to negotiate with 80.92.231.239 > port 38675: no matching host key type found. Their offer: > ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ecdsa-sha2-nistp > 256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2 > -nistp521-cert-...@openssh.com,ssh-rsa,ssh-dss [preauth] And that shows us that either fail2ban is not suitable for such messages (which is strange, fail2ban's sshd.conf contains appopriate regexes), or maybe you did not restart fail2ban. Personally I don't use fail2ban for sshd. Because why bother with userspace (written in python too, yuck) if the kernel does the same job? I.e. block M$ AS, China Telecom AS and maybe add Eastern Europe to the mix, and you've just reduced the number of offending logins by two orders of magnitude. Reco
