Timing side channel in OpenSSH password authentication with locked accounts on musl libc

What happened and what to do

The post by theknell, published on the oss-sec list on 6 November 2026, answers a question about password authentication behaviour when there is no salt to reuse. The author set up OpenSSH 10.6p2 built with --without-pam and a shadow file in which no account has a valid password: the fields use locking markers such as *, !, !! and *LK*, plus a locked yescrypt hash. Password authentication remained enabled. There were 60 interleaved samples per account, measuring only the time of the authentication request, with glibc/libxcrypt and with musl. The author states that scripts and raw data are available on request.

For a company exposing SSH with password authentication, this case calls for practical verification rather than assumption: inventory hosts that use musl or glibc, test locked and nonexistent accounts with repeated, comparable measurements, and record the PAM and authentication configuration. A collection pipeline can validate versions and libraries in each image, and a dashboard can track which accounts and servers still accept passwords. As an immediate defensive step, the company can move to key-based authentication, reducing exposure regardless of the test outcome.

How the consultancy can help

Diagnosis of SSH server exposure to this scenario: inventory of OpenSSH versions, C libraries (musl or glibc) and PAM and password authentication configuration, with a controlled test plan. Implementation of automated collection and a monitoring dashboard, operated in the client's environment.

Next step

If your company runs SSH with password authentication or musl-based images, send a short description of your environment and receive a scoped proposal for diagnosis and implementation.