Fail2ban with increasing jail time for repeat offenders usually takes care of the worst of it after a day or two

99.999% of that is over IPv4. I leave IPv6 open to WAN for my own use and it's not a problem.

yeah, while reading this i was going "What maniac exposes SSH to WAN anyway...?" the whole time. I fail to see any reason or point that can be justified exposing SSH to WAN.

New friends from all over the world!

Did it help you find hot milfs within a mile of your location?

Among other things, change the default ssh port to something way higher.

Yet some people will still say with a straight face "tHeRe iS nO hYbRiD wAr!1!1"

Not in Ba Sing Se at least...

Surprised me too, it's even worse if you use a cloud host for a VPS since it'll be a more known IP

How do you know this? What tool or utility tells you this fact? I have a port exposed for a game server but realising I don't know how many attempts are being made.

One reason that I have my router ignore all connection attempts from Russia and China

i mean assholes are muscle holes.

which you should have been doing anyway for anything exposed to the internet

Yeah, any application checking passwords would be vulnerable.

Easier said than done.

If you have to support the sort of user that barely managed to download a copy of putty a few years ago and kept using this, then walking them through key generation and use is a nightmare.

One could fairly argue that maybe such people shouldn't have access to a system, but it is a reality.

Of course the likelihood that a system using musl is something that class of user would be accessing is lower.

Maybe now that ssh is generally "just there" for Windows users, you can more easily work with them to generate a key, or give them a zip file to make them have a key in a standard way. But the interaction of ssh and windows file security can be... Interesting, though mostly an issue on the ash server side.

The vuln is specifically for key-based accounts:

Second, the target system account must be configured to be passwordless. Passwordless accounts are commonly used for accounts that use certificate-based authentication.

For added security, there is a pam module for 6-digit OTP

The person who discovered *sshole said OpenWRT is affected, but by default, that OS uses the Dropbear package, not OpenSSH, for SSH connections (though maintainers provide instructions for installing the latter).

nah, find and fix as many as possible.

Yes, it’s actually a very creative name. It’s caused by the character * allowing anyone to log into an open SSH port. So it’s an amalgam of {*}{SSH}{port (hole)}.

The long story short is that if you don’t have a password set for an account, Alpine saves the user’s password hash as “*” because no password hash will ever match it. Should be safe, right? Any password will always automatically fail, because the hash algorithm cannot return “*” as a result. So the only way to log in as that user is via something besides a password.

And when musl (the underlying system that Alpine uses for SSH) gets a Null response from its password hash, it uses “*” to represent that null value. Because lots of programs throw a fit if they get a true null value. So instead of returning a null value, it just returns a *. Which shouldn’t match anything, right?

So an attacker forces the password hash to return a null value. Simple to do, because the password hash is capped at 256 characters. So just enter something with more than 256 characters. Musl takes that null value, turns it into a *, and passes that onto Alpine. Alpine takes this *, and compares it with the list of saved usernames and password hashes. And it finds that the user (who has no password set, and shouldn’t be allowed to log in with a password) has a password hash of “*”. This matches the result musl just provided, so the attacker is able to log into the system.

* ssh olé!

Cyberpunk as fuck.

The best armor is to not get hit!

Why would you even have an SSH server running in a Docker container (unless the purpose of the container is being a jumpbox or similar)?

I can't emphasise it enough how much more secure you get when you use rootless, read-only containers that are limited to truly just the software you want to run and its dependencies.

Alpine is great for dev containers, but the final container should be:

• immutable on the app layer (any executable path needs to be read only)
• have only the absolutely necessary GNU tooling, service management, etc. included (for most software you don't even need these tools, and why would you give an attacker who gain access to your container, an easy way to e.g. scan your network?)
• only the data mounted, rw only if absolutely necessary (e.g. if you host a Jellyfin server, just an example, you should have the mounted media be RO, and only the config and caches be writable, mounted noexec of course)