(Randomly picking a place in the thread to insert this…)
Fundamentally, as someone has already pointed out, root login enabled/disabled doesn’t
matter for _authentication_ strength: The pair of (guessable or known user name, “root”)
and (user’s password, root password) can be equally strong as the pair of “root” and “a
password as strong as the two previous passwords together”.
OTOH, not all security is pure computer security: it is a good idea to _attribute_ every
action to a physical person, so that physical security mechanisms (disciplinary action,
lawsuits, guns) can be used. In this sense, the “root” account is a very strange concept,
and it is being used in two very different ways: 1) as an authentication system
bypass/override (very similar to “enter the BIOS password to bypass OS security
altogether”), and 2) as a conventional default user name to use for clearly
single-physical-user OS installations (personal VMs).
Now, arguably, in a perfect design, neither of these should be needed:
For 1), just use the BIOS password and boot into single-user mode (which then must be
configured not to ask for a password), or perhaps into a special variant of the standard
multi-user mode (so that networking and the IPA client works) with an unauthenticated root
shell open. This would break for servers with no or difficult physical access and no
KVM/serial console set up; is that a frequent and significant case?
For 2), use the same user name you use on the host or your other computers, and set up
sudo to give this user in the guest full control. This could, if we can automate the sudo
part, even be more convenient: “ssh hostname” now works without having to prepend root@,
or having to add such a configuration to ssh_config.
So I guess the long-term ideal would be to stop talking about the “root password”
altogether (i.e. have an anaconda install end up with root password authentication
disabled, and for “the” administrator, set up sudo to be authenticated with their own, not
root’s nonexistent, password), and to stop recommending _any_ log ins directly to the root
account. That would also implicitly resolve the sshd discussion.
Apart from older systems, which can stay unchanged on upgrades easily enough, there must
be other cases where this would cause difficulty. One obvious disadvantage of disabling
the root password would be that it essentially forces any organization with multiple
sysadmins to deploy IPA or something similar for managing all the individual’s accounts
and passwords; I’m sure this can be argued to be another advantage but some sysadmins who
used a shared password for a few decades (and a few generations of sysadmins) will still
disagree.
Mirek