In some "passwordless" configurations - in other words: working as designed.

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.

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

Not in Ba Sing Se at least...

New friends from all over the world!

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

i mean assholes are muscle holes.

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.

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)

The best armor is to not get hit!

Are you sure the VPN server has the smaller attack surface than the SSH server?

Meaning router port, not firewall port? I struggle to know the difference.

I'll expose my port to you.

I feel like alpine is more well-known for being lightweight than secure

"Security" and getting rid of that pesky copyleft licensing in order to make it so corporate users have to give back as little as possible.

Yes, one bug invalidates the whole project. As everyone knows, no bugs in glibc were ever discovered.

Dude. One issue in the time of how many in glibc...

My password is 4, will I be okay?

Funny coincidence, I'm also using your birthday as a password!

No, I kinda feel ya. These glib names used to feel earned and brought levity to often serious issues. Now it feels like people are tripping over themselves to use LLMs to dig out whatever inflated 9.8 they can find and rub our faces in it.

Such is the world, but I'm kinda done laughing for awhile (is also cranky).