Systems running an SSH server have been a frequent target of attack for perhaps the last 10 years. You check your logs in the morning, and find that there were several thousand login attempts (hopefully, all failures) from one IP address. And a few days later, it happens from another IP address.
To succeed, a SSH attacker has to guess both a user loginid and the password for that user. The attackers often try standard user accounts, such as “root”, “bin”, “daemon”.
I have never had an actual breakin. This is partly because the well known accounts do not allow logins, with the single exception of root. And I use a hard-to-guess password for root, and I configure sshd to allow only public key and host based authentication for the root user.
Home system setup
For my home (non-work) systems, and for a client-only system at work, I go a step further. I disable password logins and keyboard-interactive logins for all users. So that leaves only public key authentication.
That does not stop the breakin attempts, though it does make it almost certain that they cannot succeed. The only remaining annoyance is that the logs can get a lot of entries.
I go one step further at home. I have added entries to “/etc/hosts.allow” and “/etc/hosts.deny”, so that ssh connections are only allowed from the home LAN, from my work campus network, and from localhost. That pretty much shuts down the breakin attempts. I will occasionally see something like this log from today:
Dec 30 16:40:51 nwr2 sshd: refused connect from ::ffff:126.96.36.199 (188.8.131.52)
but it is usually a single attempt. Apparently, the disconnect from the tcp-wrapper checks (the “hosts.deny” and “hosts.allow” rules) discourages repeated tries.
That’s until today, when I see:
Dec 30 16:42:17 nwr2 sshd: refused connect from ::ffff:184.108.40.206 (220.127.116.11) Dec 30 16:42:23 nwr2 sshd: refused connect from ::ffff:18.104.22.168 (22.214.171.124) Dec 30 16:42:28 nwr2 sshd: refused connect from ::ffff:126.96.36.199 (188.8.131.52)
There have been around 80 attempts from that IP address. Apparently some of the SSH attackers (or at least one of them) are using a modified script that is not discouraged by tcp-wrappers rules.
Incidentally, that IP address “184.108.40.206” is part of a block that is allocated to “CHINANET Guangdong province network”.