- cross-posted to:
- linux@lemmy.ml
- cross-posted to:
- linux@lemmy.ml
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’m assuming this is only if you allow password authentication? If you’re only allowing certificate based auth you should be safe, right?
Correct, password authentication must be enabled on the SSH daemon side of things to be vulnerable. The user account being logged into, on the other hand, can’t have a password set. But overall, PW auth must be on. The website OP linked is exceedingly bad at explaining the actual problem, see Alpine’s announcement for better info.
https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
Certificate or key based auth is unaffected
Yep
NO! Exactly the opposite, that is the problem. Key-only is a prerequisite for this.Edit: see also, the first thing that pops up under the link.I was wrong, see below.
The “are you affected?” section directly contradicts this. It outright states you must have password authentication enabled. Otherwise, SSH never gives you a chance to even attempt a password.
Bottom of the page says what to do and gives 2 options to mitigate:
# update. openssh 10.6p2 fixes it. $ apk upgrade openssh # can't update yet? turn password logins off. $ echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf $ rc-service sshd restartSo if you disable password auth and only allow key auth, then you are unaffected (safe).
The introis a bit confusing but it means that if you have password auth on - then even if your regular ssh login requires a key, you are not safe.
Ah. Thanks for the correction. The intro + where I originally learned this from made me overreact a bit, it seems.
NO! Exactly the opposite, that is the problem. Key-only is a prerequisite for this.Edit: see also, the first thing that pops up under the link.I was wrong, see below.
I think there is some confusion and potential for misinformation here. SSH in key-only mode (common configuration) protects you from this problem, because it never accepts or even attempts any passwords at all, regardless of length. SSH in password-allowed mode with at least one user who might be a key-only USER by merit of having a password hash of “*” (not a valid password hash) is a prerequisite for this. That is a very different and very common thing, as most systems come with at least one key-only user by default. But gaining access to that user with an incorrect, invalid password still requires having passwords enabled at all.
To be clear: Password access enabled is a prerequisite, and by extension, password access disabled (key-only) prevents this.
The website you linked clearly defines that all of these conditions must be true for you to be vulnerable, and as far as I can tell, it is exactly correct:
The * account which they suggest potentially being “key only” is the prerequisite you are talking about, but having SSH itself key-only (which is best practice anyway) prevents the attack entirely.
Ah. Thanks for the correction. The intro + where I originally learned this from made me overreact a bit, it seems.
The linked article literally says you need password login enabled at the ssh level. The account however needs to not have a password set
Ah. Thanks for the correction. The intro + where I originally learned this from made me overreact a bit, it seems.