Sure.

• root is the administrator account in Unix/Linux/OSX systems
• ssh is basically the standard for secure remote login
• There is a mechanism called sudo, which allows you to perform actions as root (including logging in as root) while being logged in as a regular user, if that user is white-listed for that.

So, the general consensus is that you do not allow root login via SSH per default, but create a second user that is allowed to use sudo. That second user should have a pretty decent password, of course.

There are two main advantages: - an attacker will have to guess username and password (instead of just root/password) - the auth.log (which logs security-related stuff) will show the usernames tried in plaintext, it will show you - in case of a successful breach - through which account the attack was successful (useful in multi-user systems), and you can see by the pattern whether the attacker just runs a blind brute-force attack (-> strengthen your password) or has some knowledge about the admin - if he tries usernames like "openex", "aussiecc" etc, he is not just a bot randomly trying to attack random servers on the net (which is quite common), but someone with insider knowledge. -> strengthen your password and change your user name.

This, of course, requires the admin to have a look in the auth.log every once in a while, which clearly did not happen here. (That is OK though, it usually is pretty "boring", random attacks are pretty common - my server had about 20 of them in the last minute. BUT, having a look every once in a while helps being aware that any computer in any network is theoretically at risk of a break-in. Different story though).

Anyway,

• there are two ways of doing authentication (actually more, but two standard ways), either using passwords or using a client certificate - a private key stored on your PC which allows you to login on a server.
• You can add a password to encrypt your private key.

So the standard way of logging in is, have a private key on your desktop, secure it with a password. On your account on the remote server, set a really hard password, but also allow public key authentication. So an attacker will either have to guess your server password, or the attacker will need to access your desktop PC and then has to guess the password for your private key.

If you, for any reason, want to enable root login - there are such scenarios - the same rules apply, but the passwords should obviously be quite good, and you might wanna have some additional layer of security around your private key (encrypted hard drive with a different password, for example).

So, as pretty evident from the log, the server in question had root login via password enabled. And there was a brute-force attack going on, so the admin should have realized that, if his password is not secure, it will be broken at some point. Which it eventually did.

Sorry for the long text, probably not ELI5, just woke up :)