Проект Sshole рассказывает об ошибке аутентификации, возникавшей на стыке OpenSSH, Alpine Linux и musl. Проблему обнаружили при сравнении сборок sshd с разными libc, PAM и механизмами хранения паролей. На более чем 17 тысячах необычных сценариев входа результаты совпадали у всех конфигураций, кроме OpenSSH с musl без PAM: эта связка принимала некоторые попытки, которые остальные варианты отклоняли. Автор признаётся, что массовое тестирование выполнялось с помощью agent swarms.
История начинается с устройства блокировки учётных записей Unix. Ещё в 1980 году Билл Джой поставил звёздочку вместо хеша пароля системной учётной записи daemon. Звёздочка не является корректным хешем, поэтому ни один пароль не должен совпасть с ней. Позже хеши переместились из общедоступного /etc/passwd в /etc/shadow, но служебное значение сохранилось.
Другой фрагмент истории связан с функцией crypt(). Спецификация допускала возврат NULL при неподдерживаемом алгоритме или другой ошибке, а программы, не проверявшие этот результат, могли аварийно завершаться. В 2012 году musl изменила поведение: вместо NULL функция стала возвращать звёздочку, которая по замыслу никогда не совпадает с настоящим паролем. В том же месяце ограничение длины пароля в sha512-crypt добавило ещё один путь к такому результату.
В 2016 году OpenSSH исправил CVE-2016-6210, позволявший различать существующих и несуществующих пользователей по времени ответа. Для несуществующего пользователя sshd начал выполнять фиктивное вычисление хеша, заимствуя параметры другой учётной записи. Это выровняло время отказа, но в определённых условиях задействовало и записи, заблокированные звёздочкой.
Отдельная линия изменений касалась Alpine. После CVE-2019-5021, связанной с пустым root-паролем в Docker-образах, учётную запись заблокировали символом !. Однако без PAM это мешало и входу по SSH-ключам, поэтому в Alpine 3.16 в 2022 году root перевели на звёздочку. В сочетании с особенностями musl это создало условия для найденной ошибки.
Причина долгого молчания частично объясняется покрытием тестов: OpenSSH проверяют преимущественно на OpenBSD и glibc, musl не тестирует sshd, а большинство дистрибутивов используют PAM и не проходят проблемный путь. Есть ли реальные случаи эксплуатации, неизвестно. Автор лишь указывает на несколько близких обсуждений за прошедшие годы и на обзор безопасности OpenSSH в октябре 2026 года, где исправление оказалось всего в нескольких строках от самой ошибки.