--- title: OpenSSH on musl Linux without PAM can accept logins it... description: OpenSSH on Linux systems using musl libc without PAM can accept logins that should be rejected, including accounts with a locked `*` password field. Alpine... canonical: https://daily.dev/posts/openssh-on-musl-linux-without-pam-can-accept-logins-it-should-reject-nmuhpvoh8 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: OpenSSH on musl Linux without PAM can accept logins it should reject | daily.dev og:description: OpenSSH on Linux systems using musl libc without PAM can accept logins that should be rejected, including accounts with a locked `*` password field. Alpine... og:url: https://daily.dev/posts/openssh-on-musl-linux-without-pam-can-accept-logins-it-should-reject-nmuhpvoh8 og:image: https://api.daily.dev/og/posts/NMUHPVoh8.png og:image:alt: OpenSSH on musl Linux without PAM can accept logins it should reject og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # OpenSSH on musl Linux without PAM can accept logins it should reject **[Collections](https://daily.dev/sources/collections)** · 3 min read · 1 upvotes · 0 comments ## Summary OpenSSH on Linux systems using musl libc without PAM can accept logins that should be rejected, including accounts with a locked `*` password field. Alpine Linux is the best-known example of an affected system. The bug traces to musl's `crypt()` returning `*` on failure instead of NULL since 2012, which breaks code expecting NULL. Testing roughly 17,600 logins across builds found only musl without PAM was affected; glibc, PAM-based, and non-Linux systems were not. OpenSSH 10.6p2 ships a workaround, and Damien Miller urges affected users to set `PasswordAuthentication=no` immediately or disable SSH until updated. Alpine will backport the fix back to Alpine 3.16 from May 2022. ## Content A flaw nicknamed *sshole lets an attacker log into an account that has no usable password by sending an oversized password over SSH. It affects Linux systems where sshd is linked against musl libc and runs without PAM. Alpine Linux is the best-known example. OpenWrt, Buildroot and Yocto systems can be affected too. OpenSSH 10.6p2 ships a workaround. Alpine has published fixed packages. The issue is tracked as CVE-2026-123158 and rated high severity (CVSS 8.1). Alpine's advisory said no CVE had been assigned when it was written. ## How it works Accounts that can't use a password usually have `*` in the password field. When sshd checks a password, it calls `crypt()` and compares the result to that stored field. musl's `crypt()` returns `*` on failure instead of NULL, and it has done so since 2012. It fails when the password is too long, roughly over 256 bytes. Alpine's advisory gives the triggering range as 257 to 1024 bytes. OpenSSH then compares `*` against the stored `*`, finds a match, and lets the attacker in. The researcher who found the bug tested sshd across several builds with about 17,600 logins. Only musl without PAM accepted logins it should have rejected. Reports trace the bug to a 2016 OpenSSH patch. According to Alpine's advisory, an attack needs all of these: - openssh-server built without PAM, or running with `UsePAM no` - `PasswordAuthentication yes` - an account whose password field is `*` - another account that has a `$5$` or `$6$` hash ## Who is affected The bug does not affect non-Linux systems, Linux systems using glibc (Debian, Ubuntu, RHEL), or systems where PAM handles password authentication. The maintainer of Dropbear SSH confirmed separately that Dropbear is not affected. Alpine's official AWS and Azure cloud images are a particular worry. They ship an `alpine` account with passwordless `doas` privileges, so an attacker could go from the bypass to root. ## What to do Upgrade OpenSSH to 10.6p2 and restart sshd. On Alpine, run `apk upgrade -U -a` and then restart sshd. Fixed packages exist for Alpine 3.16 through 3.24 and edge. Alpine is backporting the fix all the way to 3.16, released in May 2022. If you can't patch right away, set `PasswordAuthentication no`. OpenSSH developer Damien Miller told affected admins to do that immediately, or to disable SSH entirely. ## Disclosure Özgün Kültekin of Wakefield reported the flaw, and Alpine developers turned around an updated release quickly. Miller said the root cause lies outside OpenSSH, but the team could still deliver a mitigation fast. He also pointed to how quickly AI agents have been rediscovering bugs lately as a reason to shorten embargo periods. I think that last point matters more than the bug itself. A decade-old edge case in a C library was waiting for someone to try a long password, and the window for quiet fixes is shrinking. ## Questions this post answers ### Why does OpenSSH on Alpine Linux accept logins it should reject? Because musl libc's crypt() function returns the string '*' on failure instead of NULL, which has been the case since 2012. Code expecting NULL on failure instead compares against '*', and since '*' is also used to mark a locked account's password field, the check can incorrectly succeed, letting locked accounts log in on systems using musl without PAM enabled. _Admins patching SSH on Alpine can track fixes like this through daily.dev before they get burned by auth bypasses._ ### How do I fix the OpenSSH musl login bypass vulnerability on Alpine Linux? Update to OpenSSH 10.6p2, which ships a workaround for the bug. Until you can update, set PasswordAuthentication=no or disable SSH entirely, as urged by OpenSSH developer Damien Miller. Alpine Linux plans to backport the fix as far back as Alpine 3.16, released in May 2022. _daily.dev helps sysadmins catch urgent SSH mitigations like this before they fall behind on patching._ ### Which systems are affected by the OpenSSH musl crypt() authentication bug? Only Linux systems using musl libc with PAM disabled are affected, with Alpine Linux being the best-known example. Testing across builds covering about 17,600 logins found that non-Linux systems, Linux systems using glibc, and Linux systems using PAM for password authentication were not affected. _Teams auditing their Linux auth stack can follow security advisories like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 3 discussions and 278 comments across hackernews (as of 2026-11-05). **TL;DR:** Sshole: Discussion largely confirms the bug is real but narrow (musl without PAM, password accounts with '*' hashes), with many commenters unable to reproduce it on stock Alpine due to already-patched openssh packages, while a sizable side-debate rages over musl's design choices, C's error-handling footguns, and the writeup's AI-generated style. Alpine Linux Security advisory: OpenSSH-server password authentication bypass: Most discussion centers on a long, heated tangent about whether a memory-safe language like Rust would have prevented this logic bug, with many arguing it's a design/spec issue rather than a memory-safety issue; there's also real concern about how widely this will affect Alpine-based Docker deployments. OpenSSH 10.6p2 has been released with a workaround for a critical vulnerability: Discussion centers on the musl-specific root cause of the vulnerability, with many noting the exploit requires a narrow combination of conditions (musl, no PAM, password auth enabled, a '*' hash account alongside a real password) while others argue those conditions are common enough to matter; there's also a long tangent on password vs key authentication and disaster-recovery scenarios. **Sentiment:** 9% positive · 35% mixed · 56% skeptical **The case for** - Several note the practical blast radius is small since most default setups (Alpine with PAM off and stock sshd config) aren't affected or have already been patched. - Some note Alpine's security team responded and shipped fixes very quickly. - Some argue disabling PasswordAuthentication is simply good general security practice regardless of this bug. - Some appreciate that the writeup explains the vulnerability in an accessible way. - A few argue the sentinel-value trick was a reasonable (if flawed) attempt to avoid crashing naive callers that didn't check for NULL. **The pushback** - Many tried to reproduce the exploit on various Alpine/OpenWrt/musl setups and failed, suggesting the practical impact is narrower than implied. - Many argue returning '*' as an error sentinel instead of NULL was a clear deviation from the POSIX spec and a design mistake. - Several argue the required conditions (musl + no PAM + password auth + a '*' hash account + another valid password) are all ANDed, so the practical impact is much smaller than headlines suggest. - Commenters argue musl's decision to silently return '*' instead of NULL on crypt() failure was a flawed 'convenience' patch that traded a crash for a silent security hole. - Several push back hard on the idea that Rust or another language would have prevented this, calling it a logic bug unrelated to memory safety. **By community** - hackernews (heated): A technical debate over who is actually affected (password auth vs. passwordless accounts) escalates into broader arguments about musl's trustworthiness, C's error handling, and the AI-generated writeup's style and scroll-jacking UX. **Hottest debate:** Sshole: Whether the bug meaningfully affects systems with password authentication disabled, versus only passwordless accounts — a distinction several commenters say is being conflated and could lead to bad 'fixes'. **Open questions** - Which other real-world deployments (beyond Alpine containers and SFTP servers) actually run musl without PAM with password auth enabled? - Do other libc implementations (e.g. libxcrypt) exhibit the same '*' sentinel behavior, and if so, since when? - Is the exploit actually reliably triggerable on default Alpine installs given its use of '!' rather than '*' as the shadow placeholder? - Why did several testers fail to reproduce the exploit on current Alpine releases — is it already patched everywhere that matters? - Would constant-time string comparison alone have been sufficient to avoid the underlying timing side-channel concerns? **Highlights** > "unfortunately, a large portion of programs which call crypt are not prepared for its failure and do not check that the return value is non-null before using it. thus, always "succeeding" but giving an unmatchable hash is reportedly a better behavior than failing on error." [1] [1] https://git.musl-libc.org/cgit/musl/commit/?id=b3c4cc121f70f... > — [red75prime on hackernews · 1 comments](https://news.ycombinator.com/item?id=50378659) > Alpine matches the first. Disabling PAM has been "generally good security advice" for decades; I remember suggestions to not use it in the 2000s. Password logins are often enabled, especially on multi-user and default setups. If alpine uses the * feature, it's going to be pretty common. Gentoo has it, as does Ubuntu. If password logins are enabled, you're almost guaranteed to have at least one user with a password (root on all my boxes has one, even if I never use it and it's random garbage). So the cheese lines up pretty well, this affects quite a bit. If password logins are enabled, someone almost certainly has a password. > — [bombcar on hackernews](https://news.ycombinator.com/item?id=50380335) > Bug > are password logins still on? they are by default You > This particular bug works even with password authentication turned off. No. The bug is related to password authentication. If you do not have password authentication then you are not affected. What freaks some people out is they chose parameters where they do have password authentication but they expect to always fail. That's a bad choice, like OK you did fit a cheap manual keyhole, but you threw the keys away thinking now nobody can open that - you realise somebody with a cheap jiggler can open it right ? > — [tialaramex on hackernews](https://news.ycombinator.com/item?id=50378820) > 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" > — [scandinavian on hackernews · 7 comments](https://news.ycombinator.com/item?id=50378561) > I keep saying that no one should be using alpine or musl, but people keep replying that static linking is totally worth it. > — [0x457 on hackernews · 2 comments](https://news.ycombinator.com/item?id=50382006) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50378228) · 473 points · 146 comments - [hackernews](https://news.ycombinator.com/item?id=50379704) · 382 points · 67 comments - [hackernews](https://news.ycombinator.com/item?id=50377221) · 136 points · 65 comments ## Similar posts on daily.dev - [\*sshole: OpenSSH Authentication Bypass Gives Attackers Root on Alpine Linux](https://daily.dev/posts/sshole-openssh-authentication-bypass-gives-attackers-root-on-alpine-linux-4fddo68hd) · Orca Security Blog · 0 upvotes · 0 comments --- Tags: [#linux](https://daily.dev/tags/linux), [#authentication](https://daily.dev/tags/authentication), [#ssh](https://daily.dev/tags/ssh) [View this post on daily.dev](https://daily.dev/posts/openssh-on-musl-linux-without-pam-can-accept-logins-it-should-reject-nmuhpvoh8) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"OpenSSH on musl Linux without PAM can accept logins it should reject","url":"https://daily.dev/posts/openssh-on-musl-linux-without-pam-can-accept-logins-it-should-reject-nmuhpvoh8","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/openssh-on-musl-linux-without-pam-can-accept-logins-it-should-reject-nmuhpvoh8"},"datePublished":"2026-11-05T13:04:56.737Z","dateModified":"2026-11-05T19:27:55.944Z","description":"OpenSSH on Linux systems using musl libc without PAM can accept logins that should be rejected, including accounts with a locked `*` password field. Alpine...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/038562c4e63eb9aa81d5138097d2e5a0?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/038562c4e63eb9aa81d5138097d2e5a0?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/openssh-on-musl-linux-without-pam-can-accept-logins-it-should-reject-nmuhpvoh8","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"linux,authentication,ssh","timeRequired":"PT3M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"OpenSSH on musl Linux without PAM can accept logins it should reject"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/openssh-on-musl-linux-without-pam-can-accept-logins-it-should-reject-nmuhpvoh8#faq","mainEntity":[{"@type":"Question","name":"Why does OpenSSH on Alpine Linux accept logins it should reject?","acceptedAnswer":{"@type":"Answer","text":"Because musl libc's crypt() function returns the string '*' on failure instead of NULL, which has been the case since 2012. Code expecting NULL on failure instead compares against '*', and since '*' is also used to mark a locked account's password field, the check can incorrectly succeed, letting locked accounts log in on systems using musl without PAM enabled. Admins patching SSH on Alpine can track fixes like this through daily.dev before they get burned by auth bypasses."}},{"@type":"Question","name":"How do I fix the OpenSSH musl login bypass vulnerability on Alpine Linux?","acceptedAnswer":{"@type":"Answer","text":"Update to OpenSSH 10.6p2, which ships a workaround for the bug. Until you can update, set PasswordAuthentication=no or disable SSH entirely, as urged by OpenSSH developer Damien Miller. Alpine Linux plans to backport the fix as far back as Alpine 3.16, released in May 2022. daily.dev helps sysadmins catch urgent SSH mitigations like this before they fall behind on patching."}},{"@type":"Question","name":"Which systems are affected by the OpenSSH musl crypt() authentication bug?","acceptedAnswer":{"@type":"Answer","text":"Only Linux systems using musl libc with PAM disabled are affected, with Alpine Linux being the best-known example. Testing across builds covering about 17,600 logins found that non-Linux systems, Linux systems using glibc, and Linux systems using PAM for password authentication were not affected. Teams auditing their Linux auth stack can follow security advisories like this on daily.dev."}}]} ```