Use of Root, Best Practice?

General Discussion & Chat
1

I suspect I already know the answer to this and I’ve simply been lazy/ignorant.

I’ve been using Linux for a little while, since being introduced to it when I started working in IT, starting with OpenSUSE and then CentOS for servers, since using CentOS I’ve been used to using the root account to setup the servers as that was the default login.

Then more recently I switched to Ubuntu as I tried to find a replacement for CentOS7/8 and by default you had to setup a new user account and make use of sudo for certain functions.

Now that I’m setting up some new systems in a datacentre I’d like to move back to a RHEL/CentOS like OS and want to use AlmaLinux as I’m more familiar with the way things are structured.

Now when setting up I have the option of enabling a password for root and enabling login via SSH, but I feel I shouldn’t be doing this and instead I should be creating a unique admin account on first setup which would be used for the initial server setup and maintenance.

So my question is that, what would be best practice here?

Thanks in advance.

2

There’s various options and opinions.

First - and I think everyone will agree, don’t allow root ssh and certainly not with a password (in fact ssh with passwords is best disabled in favour of keys).

I’m not a big sudo fan, most people don’t configure it correctly and so gain nothing over setting a root password, with the default config you end up with an unprivileged user with root access by using their own password which IMHO is worse (you gain some logging and a non-default username).

Basically you can either lock the root account and enable sudo but ensure there are no NOPASSWD options in the sudoers files, or set a password for root but set “PermitRootLogin no” in the sshd_config files.

Have a look at:

3

The el9 default is: if root is enabled, then root ssh auth is allowed with keys.
The additional (not recommended) option is to allow root ssh auth with password.

Ideally, root ssh is completely disabled. If the key auth is deemed enough, then question is how to deploy the authorized key? That would be with kickstart, cloud-init, or with additional account that can become root (with sudo, su, whatever).

As implied, the benefit of additional account is that the attacker has to guess its name too (and then how to become root); the name ‘root’ is well known. The additional account could/should be limited to ssh with only keys, so its password would not be used either.

4

Thank you both for your replies, seems I have some reading and re-educating to do.

Thankfully the servers I am deploying will not be publically available and I have a little time to read and test before they’re used in any production enviroment.