В OpenSSH на системах с musl раскрыли уязвимость sshhole

5 ноября 2026 года Хабр сообщил о раскрытии уязвимости sshhole в OpenSSH на системах с библиотекой musl Linux. При определённой конфигурации она позволяет войти в учётную запись, для которой не предусмотрен парольный доступ, введя вместо пароля строку длиной более 256 символов. Проблема существовала с 2016 года; исправление вошло в OpenSSH 10.6p2.

При каких условиях возможен вход

Уязвимость затрагивает не каждую установку OpenSSH на musl. Сервер sshd должен работать без PAM, а вход по паролю — оставаться разрешённым. В Alpine пакет openssh-server по умолчанию настроен без PAM; парольная авторизация тоже разрешена по умолчанию. В другой конфигурации отказ от PAM может быть задан параметром UsePAM no.

Есть и условие, связанное с учётными записями. У пользователя, в которого пытаются войти, в поле пароля должен стоять символ *, а у другого пользователя на той же системе — полноценный пароль. При таком сочетании для первой записи принимается любой пароль длиной от 257 до 1024 символов. Знать действительный пароль или подбирать его не нужно.

Это важно для записей, доступ к которым обычно организован без пароля: например, для пользователей, работающих только с SSH-ключами, или пользователей из LDAP. В числе примеров также указан root в Alpine. Само использование ключей не защищает от этого сценария, если сервер продолжает принимать парольную авторизацию и выполнены остальные условия.

Musl используется в Alpine, OpenWrt, Buildroot и Yocto, а также во множестве Docker-образов. Однако выбор библиотеки сам по себе не означает, что в систему можно войти описанным способом. По данным источника, дистрибутивы на glibc, включая Debian, Ubuntu и Fedora, не затронуты. То же относится к системам с PAM, серверу dropbear и реализации OpenSSH из OpenBSD.

Что проверить на серверах и в образах

Для разработчиков и администраторов первая задача — выяснить, в каких используемых системах запущен sshd и какие сборки OpenSSH там установлены. Проверка нужна и для серверов, и для образов, задействованных при развёртывании сайта. После определения затронутых установок имеет смысл отдельно посмотреть, не было ли успешных входов по паролю в учётные записи, для которых такой способ доступа не предполагался.

Хабр приводит способ сопоставить запись об авторизации в /var/log/messages с данными пользователя в /etc/shadow. В примере журнал содержит Accepted password для alpine, хотя в поле пароля этой учётной записи указан *. Такое сочетание — повод разбирать конкретный вход: сообщение в журнале показывает, что сервер принял пароль там, где обычный парольный доступ не ожидался.

Отдельный случай — официальные образы Alpine для AWS и Azure. В них указанная настройка присутствует у пользователя по умолчанию alpine. Этот пользователь также может выполнять команды через doas без ввода пароля. Поэтому вход в его учётную запись в описанных условиях фактически даёт права root. Для владельца сайта это причина включить в проверку не только опубликованный сервер, но и инфраструктуру, через которую сайт развёртывают.

Исправление доступно в OpenSSH 10.6p2. Если обновиться пока нельзя, в материале предложено отключить парольный вход параметром PasswordAuthentication no и перезапустить sshd. Прежде чем менять конфигурацию, команде стоит учесть, кто и какие процессы используют парольную авторизацию: такая мера меняет привычный способ подключения. Вопрос касается не только доступа разработчиков, но и порядка обслуживания системы после изменения настроек.

Моё мнение: важна проверка, а не название образа

Я бы не превращал эту новость в общее утверждение о безопасности Alpine. Здесь полезнее провести инвентаризацию систем с SSH-доступом, проверить используемые сборки и сопоставить результат с условиями эксплуатации. Название базового образа даёт отправную точку, но не заменяет проверку конфигурации и журналов. Похожий подход полезен и при разборе других сообщений об уязвимостях серверного ПО: сначала определить применимость к своей системе, затем выбирать действие.

Для меня конечная точка — обновление до версии с исправлением. Отключение входа по паролю до обновления выглядит разумной временной мерой, если заранее понятно, как после неё будут подключаться администраторы и работать процессы развёртывания. Исправление должно закрывать уязвимость, не создавая неожиданного перерыва в обслуживании сайта.

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. Раскрыта уязвимость sshhole в OpenSSH на базе musl Linux — доступ к учётным записям, не защищённым паролем habr.com

Об авторе

Фаррух Умаров

технический архитектор

Занимаюсь архитектурой веб-сервисов и миграциями CMS. В работе ценю измеримую производительность и понятный путь обновления без ночных сюрпризов.

Все публикации автора