Does this mean that someone is trying to brute force the root password on this machine over SSH? Or is it something less nefarious?
It could be attempts to brute force in via SSH, but even if it was xe2x80x9cnefariousxe2x80x9d I would not lose any sleep over it. Most any server that is publicly accessible on the Internet gets probed by attackers all the time. Someone virtually xe2x80x9ccasing the jointxe2x80x9d is nothing to lose sleep over; actual penetration of the system is.
Heck, I just checked the
auth.log on a public server I manage and count over 2000+ xe2x80x9cauthentication failurexe2x80x9d attempts over the past 24 hours when I run this command:
sudo grep "authentication failure;" /var/log/auth.log | wc -l
Sounds scary but honestly, who cares? A quick visual check of the log entries in
auth.log using a slightly modified version of the above command:
sudo grep "authentication failure;" /var/log/auth.log
xe2x80xa6shows me stuff like this:
Mar 15 07:02:09 hostname sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=22.214.171.124 user=root Mar 15 07:02:19 hostname sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=126.96.36.199 user=root Mar 15 07:02:31 hostname sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=188.8.131.52 user=root
Note how all of the attempted access attempts are on the
root account? On any system I setup,
root getxe2x80x99s neutered right away. So these attempts are past fruitless in my case. So if you check your
auth.log and see tons of attempts to
ssh into the system via the
root account, make sure your systemxe2x80x99s
root account is completely disabled to knock that concern off of the list.
root account attempts, if you see accesses of seemingly random usernames to your system that too is another attempt to hack into the system. And unless those usernames equate to some username on your system, I would not worry about them at all either.
Now some sysadmins would say the best solution to this issue is to simple disable password authentication completely from SSH and only use SSH key pairs, but I tend to think that is overkill. Not saying SSH key pairs are weakxe2x80x94they arenxe2x80x99txe2x80x94but if a systemxe2x80x99s access methods are setup sanely and securely from day one, and the passwords are robust enough to not easily be hacked, then the system is quite secure. Thatxe2x80x99s because the biggest vulnerability on modern web servers is the front-facing web application actually running on the server itself and not things like SSH.
At the end of the day I would not worry about these kinds of random xe2x80x9cwar dialingxe2x80x9d attempts, but rather be preemptively rational in making sure the server itself has the
root user account disabled. If you still operate a public server in 2015 with the
root account enabled, youxe2x80x99re basically asking for headaches in the long run.