--- title: Alpine Linux Security advisory: OpenSSH-server password... description: An OpenSSH password authentication bypass lets an attacker log into Alpine Linux systems without knowing any password. It affects openssh-server built without... canonical: https://daily.dev/posts/alpine-linux-security-advisory-openssh-server-password-authentication-bypass-wccgpc2r8 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Alpine Linux Security advisory: OpenSSH-server password authentication bypass | daily.dev og:description: An OpenSSH password authentication bypass lets an attacker log into Alpine Linux systems without knowing any password. It affects openssh-server built without... og:url: https://daily.dev/posts/alpine-linux-security-advisory-openssh-server-password-authentication-bypass-wccgpc2r8 og:image: https://api.daily.dev/og/posts/wCCgpC2R8.png og:image:alt: Alpine Linux Security advisory: OpenSSH-server password authentication bypass 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. # Alpine Linux Security advisory: OpenSSH-server password authentication bypass **[Hacker News](https://daily.dev/sources/hn)** · 6 min read · 0 upvotes · 0 comments ## Summary An OpenSSH password authentication bypass lets an attacker log into Alpine Linux systems without knowing any password. It affects openssh-server built without PAM (or with UsePAM no) when PasswordAuthentication is yes, an account exists with a '*' password field, and another account has a $5$ or $6$ hash. Sending a 257 to 1024 byte password triggers musl's crypt() to return '*' as an error, which matches the empty password field. Fixed packages are out for Alpine 3.16 through 3.24 and edge; admins should run 'apk upgrade -U -a' and restart sshd, or set PasswordAuthentication no. No CVE had been assigned at the time of writing. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does sending a very long password let me log into an Alpine Linux account that has no password set? Musl's crypt() function returns the string '*' as an error indicator when a submitted password exceeds 256 bytes. Since accounts with no password also store '*' as their password field, the comparison matches and login succeeds. This only affects openssh-server built without PAM (or openssh-server-pam with UsePAM no) when another local account has a $5$ or $6$ password hash. _daily.dev surfaces advisories like this so you can patch SSH auth bugs before attackers find them._ ### Which Alpine Linux openssh package versions fix the password authentication bypass bug? Fixed versions are 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, 10.0_p1-r11 on 3.22, 9.9_p2-r1 on 3.21, 9.7_p1-r6 on 3.20, 9.6_p1-r3 on 3.19, 9.3_p2-r4 on 3.18, 9.1_p1-r7 on 3.17, and 9.0_p1-r6 on 3.16. Run 'apk upgrade -U -a' then restart sshd with 'rc-service sshd restart', since upgrading alone does not restart the running daemon. _Track which package versions actually patch a vulnerability before you sign off on a fix, via daily.dev._ ### Is my Docker container running openssh-server on Alpine affected by this SSH password bypass vulnerability? No, Docker and other container users are not affected if they do not run sshd inside the container. Systems are also safe if PasswordAuthentication is set to no, if openssh-server-pam runs with UsePAM yes, if accounts are locked with '!' in /etc/shadow, or if no account has a $-style password hash, as with cloud-init images that disable password authentication by default. _Check whether your deployment's SSH config falls inside or outside a disclosed bypass before you assume you're safe, with daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 82 comments across hackernews (as of 2026-11-06). **TL;DR:** Most discussion centers on a long, heated debate over whether a memory-safe language like Rust would have prevented this logic bug, alongside technical dissection of why musl's crypt() returns '*' as a sentinel error value instead of NULL, deviating from POSIX. **Sentiment:** 5% positive · 35% mixed · 60% skeptical **The case for** - Some argue Rust's Result/Option types with #[must_use] would force callers to handle the error case, making this specific sentinel-matching bug far less likely. - The fix was praised as fast, with Alpine shipping patched packages quickly across many supported versions. - Using SSH key-based auth or certificates instead of password auth sidesteps the vulnerability entirely, as several commenters noted doing already. **The pushback** - Many pushed back hard that this is a logic bug, not a memory-safety issue, so switching languages (Rust, Go, etc.) wouldn't inherently have prevented it. - Some noted the Rust-advocacy argument misses that backward-compatibility pressures or poor library design (sentinel values, .unwrap() misuse) can reproduce the same class of bug in any language. - musl's deviation from the POSIX crypt() spec (returning '*' instead of NULL) is seen as a questionable 'fix' for other developers' NULL-check bugs that introduced a worse hidden flaw. - Several are skeptical that this meaningfully indicts Alpine/musl broadly, noting the bug sat latent for a decade and that vulnerabilities occur everywhere, not just in C-based systems. - One commenter suspected the advisory text itself was partly AI-generated based on phrasing patterns, questioning its authenticity. **By community** - hackernews (heated): The thread splits into a long, contentious argument about whether memory-safe languages would prevent this bug, plus a more technical and less divisive side-discussion dissecting musl's crypt() spec deviation and real-world impact. **Hottest debate:** Whether using a language like Rust instead of C would have prevented this specific bug, given it stems from a logic/sentinel-value flaw rather than memory unsafety. **Open questions** - Why did musl choose to deviate from the POSIX crypt() spec by returning '*' instead of NULL, and is this documented anywhere official? - Do other libc implementations besides musl use similar sentinel-value error returns, and do any of them share the same password-field collision risk? - How many real-world Alpine deployments are actually affected, given uncertainty over how common password-auth SSH with the specific account conditions is in practice? **Highlights** > Rust would absolutely have saved you here. Even with `Result`, which is pretty poor design, there's no confusing `Ok(s)` with `Err(s)`. Sure you can go out of your way to write something like let hash = match result { OK(s) => s, Err(s) => s, }; but at that point I feel like the library is forgiven (except for the poor error design). @my-huge-pony does make a good point elsewhere in the thread: if the potential error was not foreseen and the code was written originally to return `String` instead of `Result` then even Rust would be in a pickle. > — [K0nserv on hackernews](https://news.ycombinator.com/item?id=50382610) > musl’s crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password, so the “hash” matches and the login succeeds. Does anyone know why musl does this? Are they the only C library that behaves this way? For a C library that famously tries to adhere to POSIX as much as possible, this seems like a crazy choice. From POSIX standard: Upon successful completion, crypt() shall return a pointer to the encoded string. The first two bytes of the returned value shall be those of the salt argument. Otherwise, it shall return a null pointer and set errno to indicate the error. https://pubs.opengroup.org/onlinepubs/9699919799/functions/c... > — [NewJazz on hackernews · 3 comments](https://news.ycombinator.com/item?id=50380253) > To be fair (as the sshole site mentions) it is also necessary to fake a password hash check to avoid timing side channels revealing to remote clients whether users exist, so returning a sentinel value is not a horrifically unreasonable solution to make sure even naive code does approximately the right thing. Though I am surprised that all of the code examples do not use constant-time strcmp(). Actually, I wonder if even constant-time strncmp() would still leak information about whether the account is disabled because in that case both arguments are much shorter? Food for thought. But yeah, the crypt(3) API is very 80s C, the man page even features a lengthy description of a long-deprecated and utterly broken hashing algorithm using DES that is even implied to be broken in the text itself (and the warning message is so old it refers to "parallel computers" as though they were a new concept). Given that the default mode is to use a broken hashing algorithm, I'm shocked anyone actually uses the libc crypt(3) -- surely it's trivial to just write your own that isn't awful...? > — [cyphar on hackernews · 1 comments](https://news.ycombinator.com/item?id=50381179) > Not really related to the topic, but AI-popular sentences and language structure stand out to people right away these days right? I noticed some. "If you cannot update yet, at least disable password logins: set PasswordAuthentication no in your sshd configuration and restart sshd. Either one closes the hole." (only AI would characterize a critical SSH implementation vulnerability as a hole closing game) An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries. (It sounds like the writer is bragging about the exploit instead of describing it. AI does this) 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. The attacker then sends a very long password (257 to 1024 bytes). One user with a password is enough: it makes every account without one reachable. (same as above made stronger with the 'statement: statement2' format) "Users coming from a directory service through musl-nscd (nslcd, winbind, sssd), since they have no shadow entry." (a human would be more clear about what a shadow entry is and give more context, I think) Hmm the rest of the article (the remaining 70-80%) seems quite human. Anyway, not sure why I spent 10+ minutes on this. It just jumps at me right away. > — [feearent on hackernews · 1 comments](https://news.ycombinator.com/item?id=50382986) > This particular flaw sat latent for a decade. There's a good chance similar flaws will be discovered elsewhere. > — [ceejayoz on hackernews](https://news.ycombinator.com/item?id=50382627) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50379704) · 438 points · 82 comments ## Similar posts on daily.dev - [Critical Remote Code Execution Vulnerability in libssh2 Client Library Require Urgent Mitigation](https://daily.dev/posts/critical-remote-code-execution-vulnerability-in-libssh2-client-library-require-urgent-mitigation-uak3prjwd) · Arctic Wolf · 0 upvotes · 0 comments - [libssh2 CVE-2026-55200 Shows Why Outbound SSH Is an Attack Surface](https://daily.dev/posts/libssh2-cve-2026-55200-shows-why-outbound-ssh-is-an-attack-surface-pza5y7nfo) · Latest Hacking News · 1 upvotes · 0 comments - [Chinese hackers hijack auth flow, spy on isolated network for a decade](https://daily.dev/posts/chinese-hackers-hijack-auth-flow-spy-on-isolated-network-for-a-decade-yeupuqtg0) · BleepingComputer · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#ssh](https://daily.dev/tags/ssh) [View this post on daily.dev](https://daily.dev/posts/alpine-linux-security-advisory-openssh-server-password-authentication-bypass-wccgpc2r8) ```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":"Alpine Linux Security advisory: OpenSSH-server password authentication bypass","url":"https://daily.dev/posts/alpine-linux-security-advisory-openssh-server-password-authentication-bypass-wccgpc2r8","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/alpine-linux-security-advisory-openssh-server-password-authentication-bypass-wccgpc2r8"},"datePublished":"2026-11-05T16:07:26.576Z","dateModified":"2026-11-06T02:51:38.062Z","description":"An OpenSSH password authentication bypass lets an attacker log into Alpine Linux systems without knowing any password. It affects openssh-server built without...","image":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","thumbnailUrl":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","isAccessibleForFree":true,"articleSection":"Hacker News","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":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/alpine-linux-security-advisory-openssh-server-password-authentication-bypass-wccgpc2r8","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,ssh","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Alpine Linux Security advisory: OpenSSH-server password authentication bypass"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/alpine-linux-security-advisory-openssh-server-password-authentication-bypass-wccgpc2r8#faq","mainEntity":[{"@type":"Question","name":"Why does sending a very long password let me log into an Alpine Linux account that has no password set?","acceptedAnswer":{"@type":"Answer","text":"Musl's crypt() function returns the string '*' as an error indicator when a submitted password exceeds 256 bytes. Since accounts with no password also store '*' as their password field, the comparison matches and login succeeds. This only affects openssh-server built without PAM (or openssh-server-pam with UsePAM no) when another local account has a $5$ or $6$ password hash. daily.dev surfaces advisories like this so you can patch SSH auth bugs before attackers find them."}},{"@type":"Question","name":"Which Alpine Linux openssh package versions fix the password authentication bypass bug?","acceptedAnswer":{"@type":"Answer","text":"Fixed versions are 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, 10.0_p1-r11 on 3.22, 9.9_p2-r1 on 3.21, 9.7_p1-r6 on 3.20, 9.6_p1-r3 on 3.19, 9.3_p2-r4 on 3.18, 9.1_p1-r7 on 3.17, and 9.0_p1-r6 on 3.16. Run 'apk upgrade -U -a' then restart sshd with 'rc-service sshd restart', since upgrading alone does not restart the running daemon. Track which package versions actually patch a vulnerability before you sign off on a fix, via daily.dev."}},{"@type":"Question","name":"Is my Docker container running openssh-server on Alpine affected by this SSH password bypass vulnerability?","acceptedAnswer":{"@type":"Answer","text":"No, Docker and other container users are not affected if they do not run sshd inside the container. Systems are also safe if PasswordAuthentication is set to no, if openssh-server-pam runs with UsePAM yes, if accounts are locked with '!' in /etc/shadow, or if no account has a $-style password hash, as with cloud-init images that disable password authentication by default. Check whether your deployment's SSH config falls inside or outside a disclosed bypass before you assume you're safe, with daily.dev."}}]} ```