This is a bad idea™. You should never have more than one UID 0 on a Unix system. This will violate most corporate security guidelines (STIG and CIS) *. And for good reason.
A much better idea is to set up a non-root user and configure sudo correctly.
* https://www.stigviewer.com/stigs/red_hat_enterprise_linux_9/...
Ah, yes, those BSD idiots with their root and toor accounts, clearly clueless about security concerns.
I don’t recall ever seeing a security requirement not to have 2 root accounts. What you can’t have is multiple users sharing the same account. This is different.
> And for good reason
Could I trouble you to specify? Your link only seems to mention password problems that are trivially avoidable (really, if doubling the guesses is a problem, you're already done).
I am not a corporation, so I don't need corporate guidelines.
There isn't more than one UID 0. Only more than one password/shadow database entry pointing to it.
(It might not be necessary; perhaps there is a way for OpenSSH to remap names, so that our example rotorooter is mapped to root by sshd itself.)
> A much better idea is to set up a non-root user and configure sudo correctly.
Even if so, the same principle applies: do not call that user admin, for instance. Don't use your first name or anything that a targeted, non-random attacker could guess about you.
If that user's name is, oh, 7yMfAxB6, it will never be probed. Though no need to be that paranoid.
From the document:
> Multiple accounts with a UID of "0" afford more opportunity for potential intruders to guess a password for a privileged account.
Whoever wrote that does not know WTF they are talking about. Two identical entries in passwd/shadow do not comprise different "accounts".
The UID is the account; the password DB is more or less just window dressing.
If the two shadow entries have exactly the same password hash, then no, there aren't more opportunities to guess a password.
The only problem with the scheme in a multi-user institutional context is that when an additional UID 0 entry appears that is not "root", it looks like a backdoor someone planted to give themselves continued root access.
I don't think it's applicable to what I'm talking about because an institution probably shouldn't be setting up password-based SSH access to a renamed root account over the public internet. This is something that's a good solution for individuals or very small operators.
> Change the UID of any account on the system, other than root, that has a UID of "0".
Change it to what, with what desired effect? Might as well say 'oh, screw with the password file randomly for shits and giggles'.
Better idea: investigate why there is another 0. Maybe there is a good reason.