I have been told it is common practice to create a new user with sudo privileges and disable the root user. What risks does this mitigate?

  • Possible duplicate of Why is it bad to log in as root?
    – wjandrea
    Commented Mar 20, 2019 at 23:02
  • @wjandrea Isn't the questions fundamentally different? Commented Mar 20, 2019 at 23:03
  • In what way? Aren't they both asking "Why shouldn't I log in as root?"
    – wjandrea
    Commented Mar 20, 2019 at 23:06
  • @No, I do not think so. Neither are the answers the same, I believe the question has a lot of relevance for people confused over this specifically. Commented Mar 20, 2019 at 23:11

4 Answers 4


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.

  • 1
    If you can elaborate even more on the part where you explain about the security advantage of creating a non root, so I can mark as answer. :) Is it because root have more privileges than a sudo user? Commented Mar 20, 2019 at 11:49
  • 3
    +1, but I'd like to add that a successful brute force attack on username and password of a sudoer account has the same effect as bruteforcing root's password, so the fact that the username is not known is no security advantage. In fact, relying on the username as part of the "password" can decrease security if an attacker is able to retrieve a list of usernames. Instead of choosing a hard-to-guess username, it's more secure to append it to the password and name the user "abc".
    – danzel
    Commented Mar 20, 2019 at 13:25
  • 1
    @Ravexina there then :D
    – Rinzwind
    Commented Mar 20, 2019 at 13:30
  • 3
    Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*. Commented Mar 20, 2019 at 14:02
  • 2
    Devil's advocate: On a server you shouldn't have passwords, just SSH keys... And with things like fail2ban brute force attacks will take ages So this leaves the safety of being protected against accidents by lack of privs, but many things you do require root privs (those that don't have been scripted...) so you still have plenty of occasions for mishaps. Backups, backups, and backups. And be ready to recreate the server from the ground up if it is compromised.
    – xenoid
    Commented Mar 20, 2019 at 19:24

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.

  • Very nice addition! I myself might need a little more abstraction before grasping how a RCE works completely. It sparks a question: What decides which user a web-application is run with? Commented Mar 20, 2019 at 20:21
  • 1
    Understanding "what decides which user a web-application is run with" is a huge subject that probably should be its own SE question. With Apache, you set the desired user/group in a configuration file. At launch, the main daemon process (running as root) spawns new child processes as whatever user you tell it in the configuration file. There are also other permissions models for Apache. more info. Commented Mar 21, 2019 at 12:47

I think the security advantage of creating a non root user is vastly overestimated. Still it costs you basically nothing and it does not create any security problems. So I would recommend that you do it.


But don't neglect to secure what is really important.

  • That xkcd comic captures exactly what I have been thinking for a while now myself.
    – Sebastian
    Commented Mar 20, 2019 at 20:52

This actually depends on what you do on your server. In addition to the answer by @Ravexina (guess password attack): Do you e.g.

  • access some websites
  • read mail
  • view some pictures
  • read PDFs

All of these have been attack vectors in the past (browsers on a regular basis). If someone has used one of these vectors, he could

  • (non-root) access and remove all of your files, install software for the local user, etc
  • (root) do everything

While non-root exploits can be escalated (see https://superuser.com/questions/301646/linux-keylogger-without-root-or-sudo-is-it-real), this offers an additional layer of protection. It also protects against accidents as mentioned by @David Schwartz:

Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.

Not the answer you're looking for? Browse other questions tagged .