Musl libc and OpenSSH permit unauthenticated login on Alpine when SHA-256/512 hashes and '*' shadow entries coexist without PAM

The flaw stems from sshd borrowing the salt from a SHA-256 or SHA-512 entry in /etc/shadow for a separate account marked with '*' and then failing to enforce length or presence checks under musl's crypt implementation. Alpine maintainers confirmed the condition requires an active account, no PAM, and PermitRootLogin prohibit-password defaults. One successful connection grants the session without retries.

Checkpoint testing isolated the requirement for an existing hash entry rather than a placeholder, showing that certificate-only accounts remain reachable when the hash field contains valid SHA-2 data. This configuration appears in container base images and embedded deployments that disable PAM for size. Default Alpine builds meet all prerequisites.

The interaction was missed in prior musl and OpenSSH reviews because each component passed its isolated test vectors. Operational impact concentrates on minimal images used in orchestration fleets where passwordless service accounts with doas rights are common. Exploitation leaves standard audit logs intact.

Alpine has issued updated packages; distributions using musl without PAM must recompile OpenSSH against their libc or enable PAM. No other libc is affected.