Yes, disabling password-based authentication is the first thing to do and probably the most effective.jcyr wrote: ↑Mon Sep 02, 2019 3:38 amAny Pi on public Internet will probably have ssh enabled for remote access. In that case the 1st thing to do is disable password based login. This and lots of good tips here https://securitytrails.com/blog/mitigat ... -practices
As to the link above, points 4 (no root login), 6 (keys with strong passphrases), and 10 (SSHGuard, Fail2ban, or DenyHosts) are quite helpful. Points 1, 2, and to a certain extent also 3 are not up to date:
1. Putting SSH on a non-standard port is a bad idea in general, or an ineffective one at best. It will do a little to quiet the logs but otherwise running SSH on weird ports won't actually hide you from any one.
2. OpenSSH stopped supporting TCPd aka TCPwrappers a long time ago. TCPwrapper support was removed in OpenSSH 6.7, back in 2014, and Raspbian Buster is already on 7.9p1, in 2019. Almost all of its reason for existence has been replaced by ipchains^Wiptables^nftables now with rate limiting. However, since most attacks are distributed, classical rate limiting using iptables^nftables has almost no benefit.
3. It is silly to limit access to the Pi only to known IP addresses if remote access is a priority, especially if mitigations 4 (no root login), 6 (keys with strong passphrases), and 10 (SSHGuard, Fail2ban, or DenyHosts) have been implemented. Point 6 is especially important.
As far as I can tell, in regards to running OpenSSH on the Raspberry Pi, the single best mitigation tactic is to use SSH key-based or SSH-certificate based logins with password authentication disabled. Most bots seem to be able to determine this and back off on first contact, regardless of which port SSH is listening on.