are you affected?
- is your sshd running on musl? (alpine, openwrt, buildroot, yocto)
- is it not using pam? alpine’s openssh-server doesn’t by default, or maybe you set UsePAM no
- are password logins still on? they are by default
- is there an account with just * as its password? key-only users, ldap users, root on alpine
- and some other account with a real password?
- then that * account takes any password between 257 and 1024 characters
on alpine’s official aws and azure images that’s the default alpine user, and it has passwordless doas. so it’s root
on debian, ubuntu, fedora or anything else with glibc? going through pam? dropbear? openbsd? you’re fine
I’ve been setting
UsePam = nofor decades because leaving it on meant that it’d still present a password login of keys failed. Is this still the case, was I wrong from the beginning, or is this somehow ok?I’m not following. Are you saying you login with ssh keys and not the password, but leave “UsePam = no” so then if ssh fails you don’t have a pam error?
The way I read it, it is fine if you do not allow password authentication in general?
The container thing is extremely unlikely. However, having worked with developers before, I know there are people who are running those AWS and Azure images with internet-facing SSH password authentication. If they hadn’t already been hacked, they’ve all been hacked now. Somebody just had to check Shodan for hosts in those IP ranges running OpenSSH and try a few usernames.
I use alpine with an ssh port exposed to the internet so I can connect to it. This doesn’t seem to be an issue if you configured your settings to be secure.
Never use just default settings.
I wouldn’t recommend deploying any ssh server without reviewing the config and believe sane defaults are sane.
People use * as an account password, or sysadmins allow that? I’d never allow that on any system or service of mine. No surprise, like most of these LLM discovered issues in the media lately, it hasn’t come up before. 💯 Good they’re getting fixed, but nothing so far has really been that urgent to fix for me.
No,
\*is being put as a hash of a password, originally precisely because that would mean no actual hash (over any input) ever matches it.Ah got it, so is that a hack to prevent a specific user from logging in rather than something like:
Match User <username> PasswordAuthentication no
Nah the hash function gives up after 256 bytes and outputs
*, matching the ‘hash’.Edit: it’s unix tradition to put
*as the hash for system accounts that should never be able to be logged in, this bug now means you can login (with the right config), using any password longer than 256 characters.But how is that better than just disabling a user’s ability to log in with a password through the normal notation I mentioned? Just not sure why that was used at all. Is it something that some installer or distribution does by default? Why would that be used?
this is in the shadow file, which services more than just SSH
How is crashing on an unhandled path in a security context not better?!
This isn’t nearly as bad as I thought it was. Also the author is very reliant on AI to the point where they didn’t think about what if someone wipes the logs.
Any effected devices should be wiped and redeployed
The only container i have that has a reachable SSH port is forgejo, and even then it’s only local traffic and i’d have to check if it even uses alpine. All others also don’t have SSH enabled.
The vulnerability doesn’t seem too bad tbh.
I mean, anybody who’s still using password login for SSH is kind of asking for it.
OP I know you’re trying to do good, but please try to understand the vulnerability before spreading FUD
Yeah fair, sorry about that. The intro + where I originally learned this from made me overreact a bit, it seems.
Why would a local server even have open internet access though?
This alerts feel more relevant for public facing servers.
did you get hacked? check.
$ grep “Accepted password” /var/log/messages
That’s a really bad check unless you have an external box receiving logs and you’re looking there, because the first thing that a sophisticated attacker is going to do if they get in as root is remove the signs of their presence.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters Git Popular version control system, primarily for code LXC Linux Containers SSH Secure Shell for remote terminal access
3 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.
[Thread #159 for this comm, first seen 5th Nov 2026, 15:30] [FAQ] [Full list] [Contact] [Source code]
If I’m running containers on Alpine, doesn’t that mean that they already don’t offer SSH (sshd)? The entire point of Alpine as a base is to not add stuff you don’t need.
Unless you are running openssh with password authentication on Musl you are not impacted by this
Everything behind a good firewall and proxy.
No public facing url should ever not be proxied.
Only ports you explicitly forward. Ever.
Most containers don’t run ssh right?
Unless it’s explicitly installed no. The default Alpine image doesn’t come with OpenSSH.
