sshole
- ID
- 43401
- Status
- summarized
- Published
- 05 Nov 2026, 8:19 PM
- Fetched
- 06 Nov 2026, 6:18 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://sshhole.com/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.5
- Created
- 06 Nov 2026, 6:19 PM
- Tags
- Audience
- developerssaas_founders
What happened
OpenSSH on musl-based Linux (Alpine, OpenWrt, Buildroot, Yocto, many Docker images) has since 2016 accepted any password longer than 256 characters for accounts whose password field is `*` — root, key-only deploy users, LDAP users, and Alpine's default AWS/Azure user. The chain: musl's `crypt()` returns `*` when SHA-512 crypt fails on >256-byte input, so sshd compares `*` to the stored `*` and authenticates. The write-up traces the `*` convention to 1980 Unix and the musl commits from 2012.
Why it matters
If you run sshd inside an Alpine/musl container or appliance and rely on `*` to lock accounts, password auth is not actually disabled for >256-char inputs; set `PasswordAuthentication no` and `KbdInteractiveAuthentication no`, or patch/upgrade, and check whether your images even include openssh-server.
Discussion angle
Which of your Alpine-based services actually run sshd, and can you switch them to `PasswordAuthentication no` instead of relying on `*` to lock accounts?