Purpose of creating non root user

One security advantage of disabling root and creating a non root user who is able of using sudo is protecting your server against brute force attacks which are trying to guess your "root" password.

As Rinzwind stated that, which one do you think is more secure?

• Root account + Hard to guess password
• A custom username + Hard to guess password

The other and more important advantage is that when you have only one root user, everything you are running is being run with the power of "root" which has access to do everything so running a wrong command or making a simple mistake has the potential of destroying your server.

Simply by creating a non root user:

• You aren't giving out your root password!
• You are able to define who can do what!
• You can audit who did what!
• You are minimizing the possibility of running a wrong or dangerous command with root access.

And also remember that if somebody has physical access to the server, He or she is able to do almost whatever he/she wants to the server unless everything is encrypted on that server.

In addition to the valid concerns mentioned in @Ravexina's answer, I think it's important to note:

SSHing into your server isn't the only way a malicious actor could perform actions

In fact, a successful brute-force attack on SSH is probably the least likely way a hacker would get into your server. SSH sleeps for 3 seconds when an invalid password is entered, so brute forcing a strong remote SSH password is practically impossible.*

What's more likely is they could find a remote code execution vulnerability and "get in" that way. If when they do, you want them to have as little permission as possible. You really don't want them to be root.

See, when you run a program, like Apache, PHP, or a PHP/Python/NodeJS script, or even your web browser: that "process" also must run as a user. For example: If you run a PHP script as root, then that PHP process can do anything root can do.

So let's say, for example, a malicious actor is able to carry out a "remote code execution" attack: they are able to run code on your server. If PHP runs that malicious code, and PHP is running as root, that means the hacker's code also runs as root. But if PHP is running as a less privileged user (ie: webapp), you significantly mitigate the amount of damage it can do. This applies when you run console scripts too, and not just to PHP: Every language can have this issue.

The tricky thing here is: the RCE vulnerability might not even be code you wrote: it could be buried deep in some 3rd party library/module that your code calls to: calculate dates, interact with a database, render HTML, etc... In other words: You might not even know it's there. And it might get silently added to your codebase when you update your dependencies/libraries. As we saw in the EventStream hack, it can be trivially easy to gain control of an upstream library repository, and use it to push malicious code to unsuspecting apps downstream. If that malicious code runs as root, it can take control of your entire server, and even cover its tracks to where you never know it happened.

So while having separate users for everything may not prevent an attack entirely, it will significantly mitigate damage that could come from a remote code execution attack if it does happen.

* Obviously if your password is abc123 this does not apply, because that's probably one of the first ones hackers will try when brute-forcing.