В 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. У роботі ціную вимірювану продуктивність і зрозумілий шлях оновлення без нічних сюрпризів.

Усі публікації автора