I close SSH port 22 (and what I use instead)

I think the answer is yes. A response from a remote system (or lack of) is a signal. The conventional ssh protocol method when connecting to a server is to instantly send over the identification string. RFC 4253 requires "both sides MUST send an identification string". It doesn't necessarily decide an order, but most ssh implementations I've seen send their protocol string before any other data has been received.

The broadcasting of the versioning information does constitute a potential leakage of information that could be useful to an attacker. Even if we contrast this to something like mTLS, the client certificate doesn't come until fairly late in the handshake, so there is still information that can be cleaned from the ServerHello from an unauthenticated inspector. This is also the case with QUIC since it piggybacks off the general TLS handshake.

I think the issue is, for a known set of systems, can you create communications between them that are oblivious/non-discoverable to non-authorized systems. I think the answer is yes, but it requires an out-of-band key agreement protocol. Wireguard is an example. However, the problem of out-of-band key agreement can't really be ignored.

I think the article's method is somewhat valid. I also think it is non-ideal for only doing source IP based rulesets, especially in the world of IPv4 and NAT being prevalent.

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.

And https on 22? Why didn't I think of that?

This is what spiped is for.