I've long been under the impression that with unix, you should never login as root.
Now I've started using Virtual Private Servers over at DigitalOcean, and some advice is to use SSH keys to login as root.
This makes sense to me but I feel uneasy, like I've been caught using tabs and spaces in the same text file.
Is it more secure to use SSH root login or as another user with a tricksy password?
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 sudo.
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 execve 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 sudo.
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 sudo access.
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.
When /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.
This recommendation is most relevant on systems where multiple people can perform root-level operations. The Linux auditing daemon can distinguish "UID" and "effective UID", so user "bob" who does "sudo -i" and then performs a root-level operation will show up in audit logs as "user bob acting as user root". So, if you track changes to files in /etc, or executions of files in /sbin, you'll know exactly who performed these actions. If someone logs in directly as root, this information will not be available.
It also simplifies account management -- if a member of your admin team leaves, you just have to lock their account and not replace root ssh keys on all systems (though it's a good practice anyway, together with changing root passwords).
mricon brought up two excellent points for not using root login in a multi-user system. I just want to add a counter-point for using root login. If I need to rsync config files to the server, I can do it in one step using root login instead of uploading to the home directory of a user, then do su or sudo to rsync again into the /etc folder. Of course, I am the only administrator on the server and auditing is not an issue here.
There is no hard and fast rule for not permitting root login. It is part of a defense in depth measure. For that purpose, you can implement IP filtering or port knocking on your firewall. These, together with a strong password or key authentication should put you in good stead.
What I normally do myself is configure log on to the root account, configure the server with sudo (adding myself to the sudoers) and then not permit root login anymore through SSH.
I don't see a reason why you should not be able to work like this, but should you have a valid case yourself, using a key and a password is normally good protection (it's two-factor authentication since it's something you know and something you have).
If you disable the root login you also decrease the attack surface of your machine. One other argument generally given is that sudo gives you an amount of accountability, the root account is generally a system account and you can't, if something or someone logs on using root, know who is actually executing those commands. When using sudo you still have that accountability since the person first has to logon onto his own account and then sudo to root. This might not be applicable to you if you have few accounts (and in most cases not a seperate remote log system.
I always review the Digital Ocean when I provision a VPS follow these steps.
Add a new user (standard command)
Grant this new user root privileges by running visudo and adding your username under the one for root in the section titled "# User privilege specification". Effectively give yourself the same privileges as root
Change the port SSH listens on by editing etc/ssh/sshd_config using your editor of choice. Locate the line which says "Port 22" and change the numeric portion of that line to something else. Naturally, don't use a reserved port. A quick look online will show which are available. In that same file, locate "PermitRootLogin yes" and change the "yes" to "no" As a last step, but do so cautiously, provide explicit access to SSH to your new user account. This requires adding a line "AllowUsers "
Following all this restart the SSH service (service ssh restart).
NOTE: If you don't have console access to your VM/VPS, carefully consider how many of these steps you will change. eg. Simply changing the default port is a good.
Good-luck!
Source: https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04
I think on a server the "don't login as root" recommendation isn't as hard. If you are on a desktop, you don't use root privileges most time. But if you are on a server, most time you use it is some maintenance task. While you can give people who only have to care for the webserver limited accounts, if you are the admin of the server, you can give yourself root login. Bruteforcing is hard if you use a key for root login.
If you give some people ALL=(ALL:ALL) ALL-sudo rights, you should do the logging on another server, as some of their commands might tamper with the logs.
Thanks to everyone for answers, it's been really helpful. FWIW I'm posting my own answer for completeness, which is basically logging in as non-root user with SSH key, disallowing passwords.
It's a VPS server which only I have access to which only runs a couple of sensitive services. To that end, I want it to be as secure as possible with as little aggravation as possible:
$ adduser demoauthorized_keys file in ~/.ssh/$ visudodemo ALL=(ALL:ALL) ALL$ vim /etc/ssh/sshd_config
PasswordAuthentication no$ PermitRootLogin no$ service ssh restartHopefully that will do it, secure SSH login with no root powers :)