Hacker News

points by scandinavian 2 days ago | 0 comments

Did anyone get it to work? I tried on the official alpine docker image, enabled password login for root. The shadow entry has ! as password by default, this didn't work with a > 256 character password (i also did passwd -l which also does !). I manually changed it to * and it still didn't work.

Am I doing anything wrong here?

OpenSSH_10.3p1, OpenSSL 3.5.9 29 Sep 2026

PRETTY_NAME="Alpine Linux v3.24"

[–] markuman123 2 days ago

It's because alpine has updated all openssh-server packages already. Even from EOL alpine versions.

[–] bonyt 2 days ago

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

[–] markuman123 2 days ago

https://gist.github.com/markuman/acd2c2e7e08c849cfafe9e47bec...

on 3.21 with the previous version ...

[–] justinsaccount 2 days ago

oooh, that'll do it.

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

[–] q3k 2 days ago

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.

[–] hagbard_c 2 days ago

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.

[–] necovek 2 days ago

On top of OpenWRT on my router (running 25.12) running dropbear instead of openssh-server, I also do not have any accounts in /etc/passwd|/etc/shadow with "*" for a password hash and an actual shell (all are set to /bin/false).

[–] atmosx 2 days ago

Nope, wasn’t able to reproduced it in my firecracker VM, which isn’t publicly accessible anyway.

[–] f311a 2 days ago

As far as I understand, it wont work on default setups. You need musl-c, no pam and openssh.

[–] zamadatix 2 days ago

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).

[–] Aachen 2 days ago

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

[–] zamadatix 2 days ago

Isn't it the opposite, accounts which have no password and hence had * instead of a hash?

> 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. So if you truly have no users with passwords in your container deployment then those passwordless users aren't vulnerable to this bug, but any of the image types which have a user will likely have root exposed.

> 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...

[–] Aachen 1 day ago

The part in your edit is indeed what I was referring to, sorry that could have been clearer

[–] emayljames 2 days ago

Did you try one incorrect standard password fail first?

[–] ahepp 1 day ago

In Unixese, shadow having ! means the account is "locked", right? I haven't tried the steps to replicate so maybe they did replace the * with a ! or something, but I would try making sure the account is not locked.

[–] justinsaccount 2 days ago

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.