I recently read that it's a good idea to disable root login, e.g. by setting the root user's shell to /sbin/nologin instead of /bin/bash, and to use a non-root user with sudo rights.

I did this now on a server of mine where logs were showing a large amount of login attempts. So instead of root, I now login as a non-root user, and use sudo whenever I need to.

How is this safer? In both cases, if anyone cracks the password, they will be able to execute any command.

  • 2
    Does your non-root user use an ssh key or a password? Also consider adding IP tables rules to limit where SSH connections may come from - ie block all and only accept from known good clients. Consider a reaction package like fail2ban as well. – Criggie Oct 17 '20 at 21:26
  • 3
    You can simply remove the sudo user when he retires/resign for one. The other way round would have the person who should no longer have access still remembering the root password in his brain requiring you to change the root password and tell everyone about that new password – slebetman Oct 19 '20 at 3:34
  • 2
    You can't ask this question without also addressing how sudo is configured for each user in the sudo group. Using sudo doesn't have to imply unlimited root access. – chepner Oct 19 '20 at 12:31

sudo improves safety/security by providing accountability, and privilege separation.

Imagine a system that has more than one person performing administrative tasks. If a root login account is enabled, the system will have no record/log of which person performed a particular action. This is because the logs will only show root was responsible, and now we may not know exactly who root was at that time.

OTOH, if all persons must login as a regular user, and then sudo for privilege elevation, the system will have a record of which user account performed an action. In addition, privileges for that particular user account may be managed and allocated in the sudoers file.

To answer your question now, a hacker that compromises one user account will get only those privileges assigned to that account. Further, the system logs will (hopefully) have a record showing which user account was compromised. OTOH, if it's a simple, single-user system where the privileges in the sudoers file are set to ALL (e.g. %sudo ALL=(ALL:ALL) ALL), then the advantages of accountability, and privilege separation are effectively neutered.

Finally, in regard to the advantages of sudo, the likelihood is that a knowledgeable hacker may also be able to cover his tracks by erasing log files, etc; sudo is most certainly not a panacea. At the end of the day, I feel that like many other safeguards we put in place, sudo helps keep honest people honest - it's less effective at keeping dishonest people at bay.


If you use ssh with a key to login, then the password is a 2nd factor. There is also a small amount of protection in not using a default user name. (As noted by others, this protection is that it reduces load on you machine (not having to check so many passwords/keys), and allows blocking.)

The other main safety effect, is that you make it harder to accidentally run something as root. So not a defence against malicious damage.

  • Re "protection in not using a default user name": Security through obscurity? – Peter Mortensen Oct 18 '20 at 17:35
  • 7
    @PeterMortensen Security through obscurity is only an issue when it’s your primary defense (note the term 'main method' in the first sentence of the article you linked). It’s perfectly fine as an additional layer of defense on top of other countermeasures, and is in fact a good thing there because it discourages casual attackers. – Austin Hemmelgarn Oct 18 '20 at 23:48
  • 3
    I often configure fail2ban on public facing servers to block IPs that try and log in as admin or root - if you look at your logs, an awfully large number of automated attacks use these as a starting point, then go on to try other usernames. Makes me feel better, at least, but don't know if it helps security – lupe Oct 19 '20 at 10:44

sudo helps improve security in a couple of ways:

  • It allows for fine-grained permissions. Among other things, with sudo you can:
    • Prevent a user from trivially accessing an administrative shell (which makes almost any attack you can name much more complicated).
    • Limit which commands a user can run.
    • Limit what commands can be invoked based on various properties of the login session itself (for example, allowing only a very restricted set of commands for SSH logins, but allowing full access for physical console logins).
  • It provides a paper trail that makes it easier to figure out who did what when. This is very important for postmortem analysis after a system is compromised, because it gives you better information about how the system was compromised. Note that this is in addition to any shell histories and any other logging.
  • Use of sudo instead of a root account or well-known admin account name discourages casual attackers. If you pay attention to the authentication logs on any system that has SSH on port 22 exposed to the internet, you will notice that almost all attacks are generic, attempting to brute-force a handful of very specific usernames (root, admin, toor, pi, and similar ‘well-known’ names that are widely used for administrator accounts). By not using such accounts at all and instead relying on privilege elevation using sudo once you are already logged in as a regular user, you completely eliminate a large chunk of attack surface.
  • In certain configurations (targetpw mode (which you shouldn’t use on multi-user systems, but is a reasonable choice for single-user systems), or when using something other than a password for the initial login (such as an SSH key)), using sudo provides a second layer of authentication that an attacker must get through to get root access.
  • It provides a clear demarcation of the permissions boundary. IOW, it makes it harder to accidentally run something with more privileges than it needs, because you have to consciously choose to do so. This, in turn, helps provide a marginal additional layer of protection against social engineering attacks.

Overall, none of this is all that major in terms of preventing external attacks (although the first two points are huge for protecting against internal bad actors), but all of it is also stuff that has a very low impact on usability, so it’s generally worth it to just do it to provide the marginal improvement to security it gives.


Others have pointed out the "paper trail" and that a knowledgeable attacker can delete logfiles.

If you have remote syslogging setup, it's a lot harder for an attacker to erase the evidence, as it's already elsewhere

There is never a "one true" solution. Security is layered


Other answerers have submitted a number of advantages, but I would like to posit another. Sudoers have more protections against serious mistakes than root. Running rm -rf * in / as jshmoe is extremely unfortunate, but nowhere near as catastrophic as running the same command as root. (Of course since the addition of --preserve-root as default, this particular example isn't quite as catastrophic as it used to be, but root would still wipe out everyone's stuff, while the most jshmoe can do without sudo is wipe out stuff that jshmoe has write permissions on.)

There's a psychological effect at play with sudo that makes a legitimate user working in good faith take a good look at the command they're about to run before they hit enter. This is especially important if you've got a critical machine sitting around that has a bunch of hotshot code jockeys running around on it.

Of course there's nothing worse for system stability than having your hotshot code jockeys start writing sudo as a matter of habit, so your mileage may vary.


There are several security benefits, as the other answers have lined out. The main one has not been mentioned yet:

When a person with admin rights leaves the company, you don't have to change the root password on every machine.


How is allowing login for a sudo group member safer than allowing root login?

It's not.

Generally, sudo is a way to trade security for convenience. The only reason to install sudo is when you have to deal with people who cannot live without it. But just like tobacco, there's zero reason to get used to it in the first place.

I did this now on a server of mine where logs were showing a large amount of login attempts.

Disable password authentication. Use only public key authentication. If possible, do it for all users, not just for root or "staff".

In order to reduce the noise created by stupid ssh login bots (NOT secure your system against a targeted/competent attack) you could also move the ssh server to another port than 22.

In both cases, if anyone cracks the password, they will be able to execute any command.

Exactly. And they will immediately try to sudo (that's at least what they do in my honeypot ;-)).

  • I agree with most of what you wrote, but would like to point out that sudo is useful beyond “trade security for convenience”, e.g. for accountability and auditing. – Amir Oct 20 '20 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.