First rule to remember is that you don't perform tasks as root unless they have to be performed as root.
This part reduces the risk of doing damage by a typo or other mistake. It also reduces the risk of damage if the tools you are using happen to have a security vulnerability.
Additionally accounts should only have the privileges they need and nothing more than that.
With those parts stated, let's look at the arguments for the two approaches to root access.
Arguments for logging in as non-root and using sudo
You get an audit trail in which it is easier to figure out who did what. You don't run every command as root, but only those which you prefix with
Arguments why it may not give you as much security as people say
The audit trail only works as long as people play by the rules. It is convenient if there are more than two people with
sudo access or if you just can't remember everything you did yourself. Then you can look up who did something, and ask them why they did it.
But if anybody want to bypass the audit trail, they can. If you try to prevent somebody from bypassing the audit trail, those restrictions are likely to eventually prevent them from doing their job.
People may put
sudo in front of every command by reflex, even when it wasn't needed. And in case of a security vulnerability, running without the
sudo command won't give you lots of benefit since if an attacker compromise a running process, it doesn't matter if it was run with
sudo or not, because it can just
sudo to gain the same privileges.
Arguments why using sudo can be bad
The user password gives access to more privileges. The user may by typing the user password frequently. If an attacker gets this password, it can be used to run commands through
A compromised user account effectively gives
root privileges. Remember the part about not running as
root unless you had to, and giving accounts no more privileges than they need?
If you log in as non-root user for all tasks that don't require root privileges, you reduce exposure. You don't get that benefit if the account has
sudo access. Those tasks that weren't run as root become a more valuable target for an attacker, if that same account has
What else can you do?
If you want the best of both sides, you could give each administrator two logins on the server. One login for day-to-day tasks, that do not need root privileges. And a secondary login with
sudo access for when they do need it. But then the only thing that is different between that second account and login directly as root is the audit trail. But it may be easier for people to forget that they are not supposed to use the account with
sudo access all the time. Remembering to not log in as
root all the time seems a bit easier for people to remember.
What about password brute forcing?
Some argue that it is easier to brute force a password for an attacker that only need to guess a password and not both user name and password. In reality this is a weak argument.
You can configure
sshd to only permit logins using a key. There is no need to permit login using a password. If password logins are not permitted, then password brute forcing is no longer an issue. There does not even need to exist a password, that gives access to the root account. And nobody is going to guess the secret key for ssh authentication.
/root/.ssh/authorized_keys contain a public key for each administrator, those public keys could be used as an audit trail showing who did what. And it is just as easy to revoke access by removing a key from
authorized_keys as through any other means.