[kazinator]

I've never seen SSH attackers probe a space of user IDs in such a way that they would eventually find a user ID like Z@an4ar. In fact, they just stick to standard user IDs like root, and probe only the password spaces. If your super user account is not named root, or not available by that name via SSH, it is safe from attacks which only try that name.

sshd can be configured simply not to allow root logins. To use root, you log into some other account and then su. That other account can have a name that attackers will never try, and a decent password.

Then, if you happen to be using a log based banning system, since you know that no legitimate user would be trying the name root, you can impose an instant ban on such an IP address, with a long duration. It's really just for reducing traffic more than anything.

Regarding aliasing root, you can create an alias for the UID 0 user simply by editing your password and shadow files to create duplicate entry. If the root entry appears first, then that name is still used whenever a UID is resolved to a user name, like in your ls -l and whatnot.

The shadow entry for root can have a star in the password field so that it cannot be used for logging in by any means; only the alternative name can be used via the other entry that has a password set up in its shadow entry.

[kazinator]

Addendum: I just ran some scripts to see what attackers are trying. They probe various funny user names but there doesn't appear to be any system behind it. They are all short names. The vast majority of them are nothing but lower case letters. A few have underscores and digits, as well as dashes and periods. Some are digits only. A few are using glyph characters:

  !
  !!!
  ?
  #$

I suspect that the user IDs being tried are all targeting known passwords that have been obtained before. I.e. they are probing "where else on the planet has the same user ID used that same password".

The valid users they are trying are: avahi backup bin daemon Debian-exim foo games gdm gnats hplip irc libuuid list lp mail man messagebus news nobody ntp postgres proxy root saned sshd sshroot statd sync sys uucp www-data

None of these allow login; they have a * in the shadow file.

[tptacek]

You get that if you believe attackers can't break your passwords, screening SSH with "port knockers" or fail2ban isn't doing anything, right?

The whole thing is kind of moot though. For other reasons, you should just wrap all this stuff up in WireGuard and never think about it again. WireGuard is silent; you can't probe it.

[kazinator]

Banning does something; it reduces traffic.

It also reduces noise in the logs, but you could get that by not logging unsuccessful login attempts.

I don't favor port knocking. I tried it many years ago; it wasn't worth it.

> should just wrap all this stuff up in WireGuard

Suppose I just bought a burner phone in a foreign country. How easily can I set this up from scratch?

SSH with passwords: just install Termux, add ssh package, and go.

[tptacek]

Use a password to encrypt a key or config you save on a cloud drive. `age` is good for this.

[kazinator]

Actually, banning reduces traffic less than you might think. These days most of the attackers assume they are going to be banned. You get a lot of singleton requests from IP addresses that don't show up again, or not any time soon. And if your banning system generates logs of its own, it just increases the log noise.

As a result of this HN discussion, I disabled all SSH logging, and turned off the associated banning system. I disabled the use of PAM by sshd, and set its logging level to FATAL (because the ERROR level stupidly still logs when sshd is not able to find a shadow entry for a user ID).

I'm confident they are not getting in by guessing a password and no longer believe there is a net saving in resources by monitoring and banning.

[fragmede]

how do you get into the cloud drive though?

[tptacek]

Were you getting into it with an SSH password? Then it doesn't matter for this discussion.

The point isn't that passwords are evil, it's that SSH passwords are evil.