{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/hnrss-org/2026-11-05-alpine-linux-security-advisory-openssh-server-password/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "**If you run `sshd` on Alpine Linux, update `openssh` now and restart `sshd`.** Upgrading the package alone does not replace the running daemon.\n\nIf you cannot update yet, at least disable password logins: set `PasswordAuthentication no` in your sshd configuration and restart `sshd`. Either one closes the hole.\n\n## What is the problem?\n\nAn 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.\n\nThe 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.\n\nDetails are in the [OpenSSH 10.6p2 release notes](https://www.openssh.com/releasenotes.html). No CVE identifier had been assigned at the time of writing.\n\n## Who is affected?\n\nYou are affected if all of the following are true:\n\n- You run the Alpine `openssh-server` package, which is built without PAM, or you run `openssh-server-pam` with `UsePAM no`. (`openssh-server-pam` with `UsePAM yes` is not affected.)\n- `PasswordAuthentication` is `yes` (the OpenSSH default, unless you changed it).\n- The machine has an account whose password field is `*`. This includes:\n - `root`, which ships as `root:*` in the base image since about Alpine 3.16. OpenSSH’s default `PermitRootLogin prohibit-password` protects root, so root is only reachable if `PermitRootLogin yes` is set. That does not help if another account that can log in is able to become root, for example through `doas`.\n - Any key-only user created with `adduser` without a password, or with `usermod -p '*'`.\n - Users coming from a directory service through musl-nscd (nslcd, winbind, sssd), since they have no shadow entry.\n - The `alpine` user in the official **tiny-cloud** images (see below).\n- At least one local account has a `$5$` or `$6$` password hash.\n\nAffected releases: every Alpine release we checked, 3.21 through 3.24 and edge, and the older releases that no longer receive regular updates (3.16 to 3.20).\n\n### Who is not affected?\n\n- **Docker and other container users** that do not run `sshd` in the container.\n- Systems with `PasswordAuthentication no`.\n- Systems using `openssh-server-pam` with `UsePAM yes` (with `UsePAM no` you are affected).\n- Locked accounts: those with `!` as the password field in `/etc/shadow` (a line starting `user:!:`). They cannot log in with a password or a key.\n- Systems where no account has a `$`-style password hash.\n- Cloud images configured through cloud-init, which writes `PasswordAuthentication no`.\n\n## How can I fix it?\n\n### 1\\. Update\n\n```\napk upgrade -U -a\n```\n\nAlpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package (see the [release announcement](https://alpinelinux.org/posts/alpine-3.21.10-3.22.8-3.23.8-3.24.4-released/)). The fixed package versions are:\n\n| Branch | Fixed `openssh` version |\n| ------ | ----------------------- |\n| edge | 10.6\\_p2-r0 |\n| 3.24 | 10.3\\_p1-r2 |\n| 3.23 | 10.2\\_p1-r1 |\n| 3.22 | 10.0\\_p1-r11 |\n| 3.21 | 9.9\\_p2-r1 |\n| 3.20 | 9.7\\_p1-r6 |\n| 3.19 | 9.6\\_p1-r3 |\n| 3.18 | 9.3\\_p2-r4 |\n| 3.17 | 9.1\\_p1-r7 |\n| 3.16 | 9.0\\_p1-r6 |\n\n**Restart `sshd` after upgrading** (`rc-service sshd restart`). Upgrading the package does not restart a running `sshd`, so you must do it after.\n\n### 2\\. If you cannot update: disable password authentication\n\nBefore you start, make sure your SSH key login works, and keep your current session open until you have tested a new login.\n\nRun these as root. The first two commands create a drop-in file. Alpine’s default `sshd_config` reads that directory from 3.19 onward; older releases ignore it. The `sed` command changes `yes` to `no` on every `PasswordAuthentication` line in `/etc/ssh/sshd_config`, whatever the spacing, including lines inside a `Match` block. It also adds `PasswordAuthentication no` at the top of the file, for the case where there was no such line, and saves the original as `/etc/ssh/sshd_config.bak`. The last two commands check the configuration, restart the daemon, and show the result:\n\n```\nmkdir -p /etc/ssh/sshd_config.d\necho 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf\nsed -i.bak -e '1i PasswordAuthentication no' \\\n -e 's/^\\(\\s*PasswordAuthentication[^y#]*\\)yes/\\1no/i' \\\n /etc/ssh/sshd_config\nsshd -t && rc-service sshd restart\nsshd -T | grep -i passwordauthentication\n```\n\nThe last command should print `passwordauthentication no`. To undo, delete `/etc/ssh/sshd_config.d/00-no-passwords.conf` and copy `/etc/ssh/sshd_config.bak` back over `/etc/ssh/sshd_config`.\n\n## Cloud images (tiny-cloud)\n\nThe official tiny-cloud images (the qcow2, VHD and AMI artifacts) from **3.18.11 through 3.24.3** ship an `alpine` user with a `*` password field and passwordless `doas`. They are safe on first boot. They become exploitable as soon as any `$6$` hash exists on the machine, for example when an admin sets a console password, or user-data adds a user with `hashed_passwd`. An attacker then gets a shell as `alpine` and can use `doas` to become root.\n\nImages built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Images from earlier point releases do not, so on every running instance, update `openssh` or disable password authentication.\n\n## Releases that are no longer supported (3.21 and older)\n\nThese releases have the same bug. 3.21 reached its end of support on 2026-11-01, but we have published fixed packages for each release all the way back to 3.16.\n\n## How do I know if I was attacked?\n\nLook in `/var/log/messages` for `sshd` lines reading `Accepted password for` an account that has no password (`alpine`, `root`, or any key-only user). Review `doas` use and recently created users, files and authorized keys on exposed machines. If you cannot rule out a login, treat the machine as compromised.\n\n## How could this happen?\n\nWhen sshd is built without PAM, it checks a password by hashing the attempt with `crypt()` (the C library function that turns a password into its stored hash) and comparing the result to the stored password field. For an account whose stored field is too short to contain a salt (the random prefix of a hash), sshd borrows the salt of another account.\n\nmusl’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.\n\nOpenSSH 10.6p2 avoids the problem in sshd. The stable-branch packages above carry a patch for the same problem.\n\n## Credits\n\nReported by Özgün Kültekin of [Wakefield](https://wakefield.co). Thanks to Damien Miller and Darren Tucker of the OpenSSH project for the fix and the 10.6p2 release, to Timo Teräs for help analyzing the issue, and to Natanael Copa, who built and uploaded the updated packages.\n", "authors": [ "pantalaimon" ], "captured_at": "2026-11-05T17:57:26.867095589+00:00", "category": "news", "content_html": "

If you run sshd on Alpine Linux, update openssh now and restart sshd. Upgrading the package alone does not replace the running daemon.

\n

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.

\n

What is the problem?

\n

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.

\n

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.

\n

Details are in the OpenSSH 10.6p2 release notes. No CVE identifier had been assigned at the time of writing.

\n

Who is affected?

\n

You are affected if all of the following are true:

\n\n

Affected releases: every Alpine release we checked, 3.21 through 3.24 and edge, and the older releases that no longer receive regular updates (3.16 to 3.20).

\n

Who is not affected?

\n\n

How can I fix it?

\n

1. Update

\n
apk upgrade -U -a\n
\n

Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package (see the release announcement). The fixed package versions are:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
BranchFixed openssh version
edge10.6_p2-r0
3.2410.3_p1-r2
3.2310.2_p1-r1
3.2210.0_p1-r11
3.219.9_p2-r1
3.209.7_p1-r6
3.199.6_p1-r3
3.189.3_p2-r4
3.179.1_p1-r7
3.169.0_p1-r6
\n

Restart sshd after upgrading (rc-service sshd restart). Upgrading the package does not restart a running sshd, so you must do it after.

\n

2. If you cannot update: disable password authentication

\n

Before you start, make sure your SSH key login works, and keep your current session open until you have tested a new login.

\n

Run these as root. The first two commands create a drop-in file. Alpine’s default sshd_config reads that directory from 3.19 onward; older releases ignore it. The sed command changes yes to no on every PasswordAuthentication line in /etc/ssh/sshd_config, whatever the spacing, including lines inside a Match block. It also adds PasswordAuthentication no at the top of the file, for the case where there was no such line, and saves the original as /etc/ssh/sshd_config.bak. The last two commands check the configuration, restart the daemon, and show the result:

\n
mkdir -p /etc/ssh/sshd_config.d\necho 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf\nsed -i.bak -e '1i PasswordAuthentication no' \\\n  -e 's/^\\(\\s*PasswordAuthentication[^y#]*\\)yes/\\1no/i' \\\n  /etc/ssh/sshd_config\nsshd -t && rc-service sshd restart\nsshd -T | grep -i passwordauthentication\n
\n

The last command should print passwordauthentication no. To undo, delete /etc/ssh/sshd_config.d/00-no-passwords.conf and copy /etc/ssh/sshd_config.bak back over /etc/ssh/sshd_config.

\n

Cloud images (tiny-cloud)

\n

The official tiny-cloud images (the qcow2, VHD and AMI artifacts) from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. They are safe on first boot. They become exploitable as soon as any $6$ hash exists on the machine, for example when an admin sets a console password, or user-data adds a user with hashed_passwd. An attacker then gets a shell as alpine and can use doas to become root.

\n

Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Images from earlier point releases do not, so on every running instance, update openssh or disable password authentication.

\n

Releases that are no longer supported (3.21 and older)

\n

These releases have the same bug. 3.21 reached its end of support on 2026-11-01, but we have published fixed packages for each release all the way back to 3.16.

\n

How do I know if I was attacked?

\n

Look in /var/log/messages for sshd lines reading Accepted password for an account that has no password (alpine, root, or any key-only user). Review doas use and recently created users, files and authorized keys on exposed machines. If you cannot rule out a login, treat the machine as compromised.

\n

How could this happen?

\n

When sshd is built without PAM, it checks a password by hashing the attempt with crypt() (the C library function that turns a password into its stored hash) and comparing the result to the stored password field. For an account whose stored field is too short to contain a salt (the random prefix of a hash), sshd borrows the salt of another account.

\n

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.

\n

OpenSSH 10.6p2 avoids the problem in sshd. The stable-branch packages above carry a patch for the same problem.

\n

Credits

\n

Reported by Özgün Kültekin of Wakefield. Thanks to Damien Miller and Darren Tucker of the OpenSSH project for the fix and the 10.6p2 release, to Timo Teräs for help analyzing the issue, and to Natanael Copa, who built and uploaded the updated packages.

\n", "content_markdown": "**If you run `sshd` on Alpine Linux, update `openssh` now and restart `sshd`.** Upgrading the package alone does not replace the running daemon.\n\nIf you cannot update yet, at least disable password logins: set `PasswordAuthentication no` in your sshd configuration and restart `sshd`. Either one closes the hole.\n\n## What is the problem?\n\nAn 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.\n\nThe 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.\n\nDetails are in the [OpenSSH 10.6p2 release notes](https://www.openssh.com/releasenotes.html). No CVE identifier had been assigned at the time of writing.\n\n## Who is affected?\n\nYou are affected if all of the following are true:\n\n- You run the Alpine `openssh-server` package, which is built without PAM, or you run `openssh-server-pam` with `UsePAM no`. (`openssh-server-pam` with `UsePAM yes` is not affected.)\n- `PasswordAuthentication` is `yes` (the OpenSSH default, unless you changed it).\n- The machine has an account whose password field is `*`. This includes:\n - `root`, which ships as `root:*` in the base image since about Alpine 3.16. OpenSSH’s default `PermitRootLogin prohibit-password` protects root, so root is only reachable if `PermitRootLogin yes` is set. That does not help if another account that can log in is able to become root, for example through `doas`.\n - Any key-only user created with `adduser` without a password, or with `usermod -p '*'`.\n - Users coming from a directory service through musl-nscd (nslcd, winbind, sssd), since they have no shadow entry.\n - The `alpine` user in the official **tiny-cloud** images (see below).\n- At least one local account has a `$5$` or `$6$` password hash.\n\nAffected releases: every Alpine release we checked, 3.21 through 3.24 and edge, and the older releases that no longer receive regular updates (3.16 to 3.20).\n\n### Who is not affected?\n\n- **Docker and other container users** that do not run `sshd` in the container.\n- Systems with `PasswordAuthentication no`.\n- Systems using `openssh-server-pam` with `UsePAM yes` (with `UsePAM no` you are affected).\n- Locked accounts: those with `!` as the password field in `/etc/shadow` (a line starting `user:!:`). They cannot log in with a password or a key.\n- Systems where no account has a `$`-style password hash.\n- Cloud images configured through cloud-init, which writes `PasswordAuthentication no`.\n\n## How can I fix it?\n\n### 1\\. Update\n\n```\napk upgrade -U -a\n```\n\nAlpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package (see the [release announcement](https://alpinelinux.org/posts/alpine-3.21.10-3.22.8-3.23.8-3.24.4-released/)). The fixed package versions are:\n\n| Branch | Fixed `openssh` version |\n| ------ | ----------------------- |\n| edge | 10.6\\_p2-r0 |\n| 3.24 | 10.3\\_p1-r2 |\n| 3.23 | 10.2\\_p1-r1 |\n| 3.22 | 10.0\\_p1-r11 |\n| 3.21 | 9.9\\_p2-r1 |\n| 3.20 | 9.7\\_p1-r6 |\n| 3.19 | 9.6\\_p1-r3 |\n| 3.18 | 9.3\\_p2-r4 |\n| 3.17 | 9.1\\_p1-r7 |\n| 3.16 | 9.0\\_p1-r6 |\n\n**Restart `sshd` after upgrading** (`rc-service sshd restart`). Upgrading the package does not restart a running `sshd`, so you must do it after.\n\n### 2\\. If you cannot update: disable password authentication\n\nBefore you start, make sure your SSH key login works, and keep your current session open until you have tested a new login.\n\nRun these as root. The first two commands create a drop-in file. Alpine’s default `sshd_config` reads that directory from 3.19 onward; older releases ignore it. The `sed` command changes `yes` to `no` on every `PasswordAuthentication` line in `/etc/ssh/sshd_config`, whatever the spacing, including lines inside a `Match` block. It also adds `PasswordAuthentication no` at the top of the file, for the case where there was no such line, and saves the original as `/etc/ssh/sshd_config.bak`. The last two commands check the configuration, restart the daemon, and show the result:\n\n```\nmkdir -p /etc/ssh/sshd_config.d\necho 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf\nsed -i.bak -e '1i PasswordAuthentication no' \\\n -e 's/^\\(\\s*PasswordAuthentication[^y#]*\\)yes/\\1no/i' \\\n /etc/ssh/sshd_config\nsshd -t && rc-service sshd restart\nsshd -T | grep -i passwordauthentication\n```\n\nThe last command should print `passwordauthentication no`. To undo, delete `/etc/ssh/sshd_config.d/00-no-passwords.conf` and copy `/etc/ssh/sshd_config.bak` back over `/etc/ssh/sshd_config`.\n\n## Cloud images (tiny-cloud)\n\nThe official tiny-cloud images (the qcow2, VHD and AMI artifacts) from **3.18.11 through 3.24.3** ship an `alpine` user with a `*` password field and passwordless `doas`. They are safe on first boot. They become exploitable as soon as any `$6$` hash exists on the machine, for example when an admin sets a console password, or user-data adds a user with `hashed_passwd`. An attacker then gets a shell as `alpine` and can use `doas` to become root.\n\nImages built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Images from earlier point releases do not, so on every running instance, update `openssh` or disable password authentication.\n\n## Releases that are no longer supported (3.21 and older)\n\nThese releases have the same bug. 3.21 reached its end of support on 2026-11-01, but we have published fixed packages for each release all the way back to 3.16.\n\n## How do I know if I was attacked?\n\nLook in `/var/log/messages` for `sshd` lines reading `Accepted password for` an account that has no password (`alpine`, `root`, or any key-only user). Review `doas` use and recently created users, files and authorized keys on exposed machines. If you cannot rule out a login, treat the machine as compromised.\n\n## How could this happen?\n\nWhen sshd is built without PAM, it checks a password by hashing the attempt with `crypt()` (the C library function that turns a password into its stored hash) and comparing the result to the stored password field. For an account whose stored field is too short to contain a salt (the random prefix of a hash), sshd borrows the salt of another account.\n\nmusl’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.\n\nOpenSSH 10.6p2 avoids the problem in sshd. The stable-branch packages above carry a patch for the same problem.\n\n## Credits\n\nReported by Özgün Kültekin of [Wakefield](https://wakefield.co). Thanks to Damien Miller and Darren Tucker of the OpenSSH project for the fix and the 10.6p2 release, to Timo Teräs for help analyzing the issue, and to Natanael Copa, who built and uploaded the updated packages.\n", "dateCreated": "2026-11-05T17:57:26.867095589+00:00", "date_created": "2026-11-05T14:44:20+00:00", "date_modified": "2026-11-05T14:44:20+00:00", "date_published": "2026-11-05T14:44:20+00:00", "description": "If you run sshd on Alpine Linux, update openssh now and restart sshd. Upgrading the package alone does not replace the running daemon. If you cannot update yet, at least disable password logins: set PasswordAuthentication no in your sshd…", "external_url": "https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/", "git": { "commit": "20068632b65d2830a2d54f25ca1d90d697bea2c0", "path": "items/hnrss-org/2026/11/2026-11-05-alpine-linux-security-advisory-openssh-server-password.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/20068632b65d2830a2d54f25ca1d90d697bea2c0/items/hnrss-org/2026/11/2026-11-05-alpine-linux-security-advisory-openssh-server-password.md" }, "id": "urn:aggr:item:faa3b3b6eb5cb0c3b37b7c1ea366b0f24f1aada2", "isBasedOn": { "@id": "https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/" }, "mainEntity": { "@id": "https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/hnrss-org/2026-11-05-alpine-linux-security-advisory-openssh-server-password/#webpage" }, "author": [ { "@type": "Person", "name": "pantalaimon" } ], "dateModified": "2026-11-05T14:44:20+00:00", "datePublished": "2026-11-05T14:44:20+00:00", "headline": "Alpine Linux Security Advisory: OpenSSH-server password authentication bypass", "image": { "@type": "ImageObject", "caption": null, "height": 90, "url": "https://alpinelinux.org/alpinelinux-logo.svg", "width": 160 }, "timeRequired": "PT5M", "url": "https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/", "wordCount": 1097 }, "name": "Archived snapshot: Alpine Linux Security Advisory: OpenSSH-server password authentication bypass", "preview": { "alt": null, "color": null, "height": 90, "placeholder": { "data_url": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNk+A8AAQUBAScY42YAAAAASUVORK5CYII=", "hash": "" }, "url": "https://alpinelinux.org/alpinelinux-logo.svg", "width": 160 }, "reading_minutes": 5, "replicated_at": null, "source": "hnrss-org", "source_name": "Hacker News: Front Page", "summary": null, "tags": [], "temporalCoverage": "2026-11-05T17:57:26.867095589+00:00", "title": "Alpine Linux Security Advisory: OpenSSH-server password authentication bypass", "url": "https://aggr.aymericbeaumet.com/items/hnrss-org/2026-11-05-alpine-linux-security-advisory-openssh-server-password/", "word_count": 1097 }