Ing. Calogero Bono
5 ноября 2026 года вышел OpenSSH 10.6p2, который исправляет баг под названием «*sshole». Он касается SSH-серверов на Linux, использующих библиотеку musl, например Alpine Linux, при отключённом PAM. Тот, кто подключается к SSH-порту, может войти в аккаунт без пароля, отправив очень длинный пароль. Это важно, потому что для атаки достаточно одного подключения, а официальные облачные образы Alpine могут давать доступ root.
Несколько терминов, прежде чем перейти к фактам. musl — альтернативная C-библиотека вместо glibc, которую используют Alpine, OpenWrt, Buildroot и Yocto. crypt() — функция, которая превращает пароль в его хеш. PAM — модульная система аутентификации Linux. /etc/shadow — файл, где хранятся хеши паролей. doas — инструмент, похожий на sudo, для получения прав root.
Как работает баг *sshole?
Учётная запись Linux без пароля имеет звёздочку вместо хеша в /etc/shadow. Ни один пароль её не должен открыть. По данным BleepingComputer, изменение OpenSSH 2016 года, созданное для исправления CVE-2016-6210 по перечислению пользователей, заставляет вычислять хеш и для таких учёток.
Здесь вступает musl. Как объясняет предупреждение Alpine, crypt() в musl возвращает * как сигнал ошибки, если ключ длиннее 256 байт. Эта звёздочка совпадает с сохранённой в учётной записи, и сравнение проходит. Исследователь Özgün Kültekin говорит, что дефект существует с 2016 года.
Кто на самом деле в зоне риска?
Нужно сочетание нескольких условий. По данным Alpine, пакет openssh-server собран без PAM либо используется openssh-server-pam с UsePAM no. PasswordAuthentication должен быть включён, как по умолчанию. Нужна учётная запись с * и хотя бы одна другая с хешем $5$ или $6$. Достаточно одного пользователя с паролем, чтобы все остальные стали доступны.
Alpine проверила версии с 3.21 по 3.24 и edge, а также старые 3.16–3.20. Не затронуты контейнеры без sshd, системы с PasswordAuthentication no и системы с включённым PAM. Debian, Ubuntu и Fedora, которые используют glibc, не уязвимы, пишет BleepingComputer.
Почему облачные образы Alpine вызывают беспокойство?
В официальных образах tiny-cloud, начиная с 3.18.11 по 3.24.3, есть пользователь alpine с паролем * и doas без пароля. Alpine уточняет, что при первом запуске они безопасны. Уязвимыми они становятся, когда появляется хеш $6$, например если администратор задаёт консольный пароль или если user-data добавляет пользователя с hashed_passwd.
Тогда злоумышленник получает оболочку как alpine, а через doas становится root. Образы, настроенные через cloud-init, которые пишут PasswordAuthentication no, не затронуты. Для root значение по умолчанию PermitRootLogin prohibit-password защищает только прямой вход.
Как исправить и проверить атаку?
Исправление есть в OpenSSH 10.6p2. На Alpine выполняется apk upgrade -U -a, затем перезапуск sshd, поскольку обновление не заменяет уже работающий демон. Alpine выпустила исправленные пакеты вплоть до 3.16, в том числе для снятых с поддержки выпусков.
Если обновить нельзя, установи PasswordAuthentication no и перезапусти sshd, предварительно убедившись, что вход по ключу работает. Чтобы искать следы, проверь в /var/log/messages строки «Accepted password» для учёток без пароля. Alpine добавляет, что если исключить вход нельзя, машину стоит считать скомпрометированной. По правам учёток полезно также руководство по правам доступа в Linux.
Ограничения, которые стоит знать
Alpine пишет, что на момент публикации CVE не был присвоен. OpenSSH указывает, что причина лежит вне sshd, но эксплуатируется через sshd, где её и можно обойти. Данных о реальных атаках пока нет. Утверждения о 17 600 тестах с ИИ-агентами исходят от исследователя, их передаёт BleepingComputer, и независимо они не проверены.
Что это меняет для тех, кто работает с цифровыми системами
Если ты управляешь серверами Alpine, роутерами OpenWrt или встраиваемыми системами на Yocto и Buildroot, проверь, разрешает ли sshd пароли и есть ли аккаунты с *. Многие используют Alpine в контейнерах без sshd, и они не затронуты. Если у тебя облачные машины на образах tiny-cloud, проверь каждый уже запущенный экземпляр. Сервер под управлением с регулярными обновлениями снижает такой риск, об этом мы писали на странице про хостинг и управляемые серверы. Стоит также следить за связанной историей эксплойтов, созданных ИИ, о которой мы писали в этой статье.
Наше мнение
Этот случай показывает, насколько хрупка граница между компонентами, которые доверяют друг другу. OpenSSH добавила законную защиту в 2016 году, musl выбрала распространённое значение ошибки, и вместе они открыли дверь на десять лет. Показательно и то, что баг нашли с помощью ИИ-агентов. Сама OpenSSH предупреждает, что такие баги часто переоткрываются другими, так что ждать опасно. Самое надёжное средство по-прежнему то же, что всегда – ключи вместо паролей.
Частые вопросы
Уязвимы ли Debian и Ubuntu к *sshole?
Нет. Они используют glibc, а не musl. BleepingComputer подтверждает, что системы с аутентификацией через PAM не уязвимы, а Alpine уточняет, что openssh-server-pam с UsePAM no не уязвим, тогда как с UsePAM yes — тоже нет.
Достаточно обновить пакет openssh?
Нет, нужно ещё перезапустить sshd. Alpine уточняет, что обновление не заменяет уже запущенного демона, поэтому уязвимая версия продолжит работать.
Можно ли защититься без обновления?
Да, временно. Установи PasswordAuthentication no в конфигурации sshd и перезапусти службу. Сначала убедись, что вход по ключу работает.
Root тоже под угрозой?
Только в некоторых случаях. При PermitRootLogin prohibit-password, значении по умолчанию, root напрямую недоступен. Он становится уязвимым, если включён PermitRootLogin yes или если другой пользователь может стать root, например через doas.
Есть ли CVE для этого бага?
Пока нет, по данным Alpine. В предупреждении сказано, что на момент написания идентификатор не был присвоен. Ориентироваться стоит на примечания к выпуску OpenSSH 10.6p2.
Что отслеживать после OpenSSH 10.6p2
OpenSSH объявила о более частых выпусках, чтобы исправления быстрее доходили до пользователей. Баг оставляет открытыми несколько вопросов, за которыми стоит следить.
- Проверь, будет ли присвоен CVE и распознают ли его твои сканеры безопасности.
- Узнай, когда производители прошивок на базе OpenWrt, Buildroot и Yocto выпустят обновления.
- Подготовь процедуру установки минорных выпусков OpenSSH, не дожидаясь плановых версий.
