sshhole в OpenSSH позволяла обходить парольную аутентификацию на Alpine Linux
В OpenSSH обнаружена уязвимость CVE-2026-123158, получившая название sshhole. На Linux-системах с musl libc и отключенным PAM определенная конфигурация учетных записей позволяла пройти парольную аутентификацию с некорректно длинным паролем, не зная настоящего секрета пользователя. Alpine Linux выпустил исправленные пакеты 5 ноября 2026 года, а разработчики OpenSSH закрыли проблему в версии 10.6p2. Обычные системы Debian, Ubuntu и Fedora на glibc этим конкретным механизмом не затронуты.Почему OpenSSH принимал неправильный пароль
Проблема возникает не в криптографии SSH, а на стыке OpenSSH и функции crypt() библиотеки musl. В предупреждении Alpine Linux объясняется, что для учетных записей без обычного парольного хеша OpenSSH все равно выполняет вычисления, чтобы по времени ответа нельзя было определить существование конкретного пользователя.У таких аккаунтов в системном файле паролей может находиться символ `*`, означающий, что обычный пароль для входа не установлен. Одновременно musl при ошибке обработки чрезмерно длинного пароля тоже возвращала `*`. В результате OpenSSH мог ошибочно воспринять два одинаковых значения как успешное совпадение.
Это побочный эффект двух защитных механизмов. OpenSSH пытался скрыть существование пользователей от атак по времени ответа, а musl ограничивала обработку чрезмерно длинного ввода для защиты от чрезмерного расходования ресурсов. При определенном сочетании настроек эти решения создали новый путь обхода аутентификации.
Какие серверы действительно уязвимы
Название OpenSSH может создать впечатление очень широкого охвата, однако проблема возникает только при определенной конфигурации. Система должна использовать musl libc, sshd должен работать без PAM, парольная аутентификация должна оставаться разрешенной, а среди доступных пользователей должна присутствовать учетная запись со специальным значением `*` вместо нормального парольного хеша.Alpine Linux является главным практическим примером, поскольку стандартный пакет openssh-server там собран без PAM. Alpine подтвердил проблему в ветках 3.16-3.24 и edge и выпустил исправления в том числе для старых выпусков, которые уже не получают обычных обновлений.
Отдельное внимание разработчики обращают на некоторые tiny-cloud образы Alpine. В них существует пользователь alpine без обычного пароля, который в ряде конфигураций может получать административные права через doas. При включенной парольной аутентификации такая комбинация повышала последствия успешного обхода - доступ к обычной учетной записи мог закончиться получением root.
При этом root в стандартной конфигурации OpenSSH дополнительно защищен настройкой PermitRootLogin prohibit-password. Поэтому утверждение, что sshhole автоматически открывает прямой root-вход на любой Alpine-сервер, неверно.
Почему обычный OpenWrt не нужно считать уязвимым автоматически
В публикациях об sshhole часто рядом с Alpine перечисляют OpenWrt, Buildroot и Yocto как системы, использующие musl. Но наличие musl само по себе недостаточно.Стандартная установка OpenWrt использует собственный компактный SSH-сервер Dropbear. В документации OpenWrt установка OpenSSH описана именно как отдельная замена стандартного Dropbear. Следовательно, обычный роутер с заводской конфигурацией OpenWrt не использует уязвимый код OpenSSH.
Проверять необходимо устройства, где OpenSSH был установлен отдельно и используется как сервер вместо Dropbear. Дополнительно должны выполняться остальные условия, связанные с PAM, парольной аутентификацией и типом учетной записи.
Debian, Ubuntu, Fedora и большинство других распространенных серверных дистрибутивов используют glibc, поэтому описанная особенность musl crypt() к ним не относится. Не затронуты и системы, где OpenSSH работает с PAM или парольная аутентификация полностью отключена.
Как закрыть CVE-2026-123158
5 ноября разработчики выпустили OpenSSH 10.6p2 с защитой от ошибочного совпадения. Alpine одновременно подготовил исправленные пакеты для всех проверенных веток. В актуальных стабильных сериях исправления вошли в Alpine 3.21.10, 3.22.8, 3.23.8 и 3.24.4.Администраторам Alpine недостаточно просто установить обновленный пакет. Уже работающий процесс sshd продолжает использовать старый код до перезапуска, поэтому после обновления SSH-службу необходимо явно перезапустить.
Если обновление временно невозможно, Alpine рекомендует отключить парольную аутентификацию через параметр PasswordAuthentication no и оставить только проверенный вход по ключам. Перед изменением конфигурации необходимо убедиться, что ключевой доступ действительно работает, чтобы не потерять административный доступ к серверу.
Alpine также советует проверить журналы sshd на неожиданные успешные парольные входы в учетные записи, которым пароль вообще не назначался. Если исключить посторонний доступ невозможно, сервер следует рассматривать как потенциально скомпрометированный и отдельно проверять новые учетные записи, файлы, authorized_keys и использование административных прав.
Итог
sshhole оказалась необычной уязвимостью не самого протокола SSH, а взаимодействия нескольких защитных решений. OpenSSH маскировал существование пользователей, musl возвращала специальное значение при ошибке обработки пароля, а учетные записи без пароля использовали тот же символ в системном хеше. Совпадение этих условий позволяло ошибочно принять аутентификацию.Уязвимость получила идентификатор CVE-2026-123158, а исправление уже доступно в OpenSSH и Alpine Linux. Главный практический вывод для администраторов - проверить именно конфигурацию sshd, а не считать уязвимым любое устройство с Linux или musl. Для OpenWrt это особенно важно: стандартный Dropbear к данной ошибке OpenSSH не относится.
Редакция PavRC