sshole OpenSSH vulnerability: check Alpine and OpenWrt

Originally published on proxymint.

sshole lets long passwords into OpenSSH on musl without PAM. Who is affected, the fixed Alpine and OpenWrt packages, and how to check your logs.

TL;DR

• The accounts at risk are the ones with * in the password field. Key-only users and the tiny-cloud alpine user have it, and when sshd runs on musl without PAM they accept any password over 256 bytes once another account has a real hash. Root has it too, but the default PermitRootLogin keeps it off password logins.
• On Alpine, compare the package release, not the version string. Stable branches got backports, so a patched 3.24 box reports 10.3_p1-r2, and only edge carries 10.6_p2-r0.
• Restart sshd after the upgrade. Alpine's advisory says apk upgrade alone leaves the vulnerable daemon running, which is easy to miss on a box nobody logs into.
• PasswordAuthentication no is the quick workaround. Test a key login in a second session before the restart, since getting it wrong can lock you out of a remote box.

Key takeaways

• Patch, then restart, then check. On Alpine that means apk upgrade -U -a and rc-service sshd restart. OpenWrt needs it only if you replaced Dropbear with the openssh-server package.
• Grep the auth log for passwords on passwordless accounts. An Accepted password for alpine or for a key-only user is the line that matters, and if you find one, rebuild.
• Turn password logins off wherever keys work. It closes this bug and the next password bug too, and it's one line in sshd_config.d.
• Watch the cloud images. Alpine's tiny-cloud images from 3.18.11 to 3.24.3 ship an alpine user with passwordless doas, safe only until any account on the box gets a real password.

Read the full guide on proxymint, with the commands, tables and sources.