What I do is laughably simple.

1. Disable all logging about break-in attempts.

2. Do not have any common user names like "root".

Say you want to be able to log in as root from anywhere, just with a password. This is a wise idea; what if you need access, but are in a situation where you are not able to use a certificate?

Make up an alternative name like roto-rooter or whatever pops into your head. Install it into the password file as an alternative name for UID 0. (Make sure it appears later than the "root" entry!). Also edit the shadow file, making sure that the entry is duplicated for the alternative name.

Then in the sshd config file, use AllowUsers to allow only a whitelisted set of users. Here if you say "AllowUsers rotorooter", then the only user id that can authenticate is exactly that one, and it's mapped to UID 0 via passwd/shadow. Add any other accounts you would like to remotely access, giving them similar aliases if they happen to land into a commonly probed space, or are something that a targeted attacker could infer from knowing something about you.

Attackers do not probe the user ID space at all. They concentrate exclusively on probing the password spaces of common user IDs like root, admin, database, www-data, etc. If your system does not support any of those IDs, they are not on a trajectory to crack anything. Your rotorooter password could be "g0d" and they will not get in, if all they ever try is root.

▲

mmh0000 16 hours ago | parent [-]

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/...

▲

kazinator 16 hours ago | parent | next [-]

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.

▲

emj 12 hours ago | parent | next [-]

Using A as root username with Kj as password is good enough to not be bruteforced generally. People think too much about this.

▲

imoverclocked 16 hours ago | parent | prev [-]

> Whoever wrote that does not know WTF they are talking about

... or they know something you don't.

▲

kazinator 15 hours ago | parent | next [-]

Giving a the most flimsy reason for the policy doesn't give me confidence in that; I can think of much better reasons for disallowing uid aliases (root or otherwise).

It has the same optics as an unauthorized entry someone planted: a backdoor to retain root access. It will continuously have to be explained to new people who spot it.

If the intent is to keep the passwords identical (which it probably should be), the tooling doesn't support it. When someone changes the password for root using standard tools, the one for rotorooter doesn't sync. This is a problem if someone is changing the password in order to restrict access to just a specific set of people who know the new password. The unaltered entry turns into a de facto backdoor for everyone knowing the old password.

Pitafall: if you put an alias entry in the wrong spot in in the password file, so that it appears before the canonical entry, then UID 0 maps backward to the alias name (e.g. via the getpwuid() function). This breaks all logic that looks for the string "root" rather than UID 0. E.g. shell scripts looking for root in the output of some command.

	▲	imoverclocked an hour ago \| parent [-]
		I’m confused; Your entire response seems like reasons to not do this.

▲

therein 16 hours ago | parent | prev [-]

Quick, someone ask an LLM.

▲

kstrauser 14 hours ago | parent | prev | next [-]

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.

	▲	ffsm8 10 hours ago \| parent [-]
		in case anyone else is mildly curious (i didnt know that was a thing) > The reason it exists is shell flexibility. Traditionally root's shell is kept as a statically-linked shell like /bin/csh or /bin/sh so that the superuser can always log in even in single-user mode or if dynamically-linked shells in /usr/local break. The toor account lets an admin have a UID 0 login with a fancier daily-driver shell (bash, zsh, etc.) without touching root's safe configuration.

▲

yjftsjthsd-h 14 hours ago | parent | prev | next [-]

> 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).

▲

16 hours ago | parent | prev [-]

[deleted]