why should root access be disabled for ssh? I always hear that's for security reasons. But I don't get it. What's different to login as non-root and then sudo su -? What's the preferred way to handle tasks that need privileged permissions?



migrated from stackoverflow.com Jun 17 '10 at 22:25

This question came from our site for professional and enthusiast programmers.


Sudo is the preferred way for when you need to delegate admin tasks because of its auditability and rich granularity. Sudo allows all commands to be logged and allows for the adminstrator to setup up different sudo profiles for individuals or groups.

su or root access is all or nothing

  • I'm inclined to call FUD on this. Circumventing auditing is trivial with sudo -s or sudo bash. Unless you are talking about restricting the set of commands in /etc/sudoers, which I've never seen deployed in production environment where sudo is used interactively. When sudo is enabled, malicious software (e.g. executed by typing make or python setup.py in that random repository you just cloned from GitHub) effectively has root permissions. Compare that to the scenario where sudo is disabled and instead a separate SSH connection is used for executing commands as root. – Feuermurmel Mar 17 '17 at 11:02

Root is the one account guaranteed to be on and enabled on every single unix machine, so it's a no-brainer to pick it to attempt to brute-force the password. Without external tools (wrappers that kill obvious scanners, Intruder Prevention Devices, that kind of thing) it's only a matter of time before the password is figured out. Even with external tools preventing this kind of behavior, it's still a good idea to force incoming users to log in as a normal user and then su/sudo/pfexec up to enhanced privs. Yes, it is an extra step, and that means you'll have to create user accounts on machines that are shared between root-users, but it's another barrier between an attacker and unrestricted control of the box.


The main difference is that the attacker has to guess the username too. If you let root to log in, then he just has to guess the password.

Also he can spoof a login of a user getting the ssh key or re-sending the data using the man-in-the-middle approach and he may log into the system without having to type the password. But if he logs in as a user, he has to sudo-ize commands and thus he is forced to type the password manually. If he were logged as a root, he does not need to sudo-ize things, so is one less security step.


There hundreds of thousands of machines that are scanning for sshd's and brute forcing them. "root" is a good account to try first because if it breaks then you completely own the machine. Its is also a common account on all *nix systems, unless you disable root logins. It is a very good security practice to do this.

  • 1
    Disabling root logins is required to protect against brute force. Disabling password-based authentication would also protect you against the people scanning and still allow you to authenticate as root with little risk. Running an IPS that kill connections after a few failed attempts will also be more helpful then just blocking root access. – Zoredache Jun 17 '10 at 22:28

The main advantage to this is that it allows for more flexible access control: If a user has root rights via sudo, it's easy to grant root rights or take them away as necessary. Conversely, if you actually hand people the root pw, you can't take it away (unless you're the Men In Black ;-)), you can only change the root pw, which will impact everyone.

In that context, direct root logins are unnecessary b/c no one has the root pw.

(You will still need the root pw for emergency access at the console in single user mode; but there should be special provisions for that).


But HP-UX never forces inaccessibility of root via ssh, why?

  • 3
    because its old and no one uses it. – Rook Jun 17 '10 at 23:39

Your Answer

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