upvote
It's because alpine has updated all openssh-server packages already. Even from EOL alpine versions.
reply
Ahh! Wasn't working on 3.16, which does indeed have an updated package.

But, got it to work on 3.15 - which requires changing the ! to a * in the shadow file in addition to other steps (making another user with a hash, setting PermitRootLogin to yes, etc.).

https://pkgs.alpinelinux.org/package/v3.16/main/x86_64/opens... Build time 2026-11-05 06:53:46

reply
oooh, that'll do it.

Didn't notice that the openssh-server-10.3_p1-r2 was released today.

reply
Nope, wasn’t able to reproduced it in my firecracker VM, which isn’t publicly accessible anyway.
reply
As far as I understand, it wont work on default setups. You need musl-c, no pam and openssh.
reply
In Alpine, these would all be the case for an out of the box install with openssh added unless you specifically install openssh-server-pam and configure sshd_config to use PAM (Alpine is already musl-c based and doesn't default to PAM).
reply
Doesn't it also need a user to be added with a password entry?

I only ever see Alpine Linux used for containers which don't need accounts with interactive user logins, which is not to say it doesn't exist, just that it doesn't seem like Alpine comes with all preconditions met out of the box

reply
Isn't it the opposite, accounts which have no password and hence had * instead of a hash? I.e. the bug is:

> accounts that should never take a password at all (root, your key-only deploy user, ldap users, the default user on alpine's aws and azure images) take any password longer than 256 characters.

But yeah, Alpine for persistant installs isn't unheard of - just not as popular as the container use case. They offer official VM, Xen, Pi, and bare metal images users deploy as well. I actually had a fleet of VMs to update!

Edit: The Alpine notice made it clearer to me that at least one other account has to have a password, it's just the target account that doesn't

> The attacker needs the name of an account whose password field is * (an account with no password set, which is normal for key-only accounts), and needs the machine to have at least one other account with a $5$ or $6$ password hash.

https://alpinelinux.org/posts/2026-11-05-openssh-password-au...

reply
deleted
reply
Did you try one incorrect standard password fail first?
reply
EDIT: works after downgrading OpenSSH, turns out even EOL Alpine version got updated packages!

Also didn't have much luck on Alpine 3.20.10 with OpenSSH_9.7p1 which I've freshly installed from an official ISO.

Last two entries in /etc/shadow:

    test:*:20762:0:99999:7:::
    q3k:$6$snip.GgDQNTrqqX.A0:20762:0:99999:7:::
SSHing into test@ with one 'wrong' password then one 'long' password doesn't work. I have UsePAM no and PasswordAuthentication yes in my sshd_config.
reply
I can't reproduce it either. I used alpine:3.24.1 and openssh is openssh-server-10.3_p1-r2

I tried adding PermitRootLogin yes and PasswordAuthentication yes. Tried adding another user with a valid password.

Verified shadow entry has a *. Can't login as root or a test user. Tried another incorrect password first as well.

edit: can reproduce after `git revert 384e25e6bd1f2e7b30095900e48b570d46953510` in aports and rebuilding openssh without the fix. It also accepts the password on the 2nd+ attempt, NOT the first.

reply
No, didn't work for me open OpenWRT x64 running in a container but that is probably 'cause I'm using dropbear instead of openssh-server. That's what OpenWRT uses by default so the impact there will be minimal assuming that most installations don't change to openssh-server - it isn't installed by default.
reply
deleted
reply
[dead]
reply
[dead]
reply