# *sshole е критичен бъг в OpenSSH и Alpine Linux позволява отдалечен достъп без парола: Как да се защитите

Христо Ласков · 06.11.2026, 11:48

Говорим си за AI slop, обаче нищо не може да бъде добрият стар човешки мързел.

Именно той най-вероятно е причината за критична уязвимост в OpenSSH. Благодарение на нея, неоторизирани нападатели да отворят ssh сесия без парола на сървъри с Alpine Linux и други системи, използващи C библиотеката musl. За успешна атака са нужни единствено мрежов достъп до SSH порта, името на акаунт, конфигуриран само с SSH ключ, и въвеждане на произволна парола с дължина между 257 и 1024 байта. Пробивът успява от първия опит.

Екипът на OpenSSH пусна спешна версия 10.6p2 за отстраняване на проблема, а проектът Alpine публикува коригирани пакети за всички поддържани и по-стари издания (от 3.16 нагоре). За уязвимостта все още няма назначен CVE идентификатор.

## Защо прекалено дългата парола отваря вратата
Проблемът се корени в начина, по който демонът sshd комуникира със стандартната C библиотека musl, когато OpenSSH работи без модула PAM (Pluggable Authentication Module). В Alpine стандартният пакет openssh-server е компилиран без PAM по подразбиране.

Когато даден акаунт няма парола, в системния файл /etc/shadow стойността за хеш съдържа само символа *. Тъй като този запис е твърде кратък за посоляване (salt), sshd заема солта от друг локален акаунт, който притежава реален хеш от типа $5$ (SHA-256) или $6$ (SHA-512). При обработката на въведената парола функцията crypt() на musl отказва да валидира низове над 256 байта и връща именно * като код за грешка. Този резултат съвпада напълно със съхранения в shadow файла *, поради което sshd приема влизането за успешно.

## Кои системи са застрашени
Според бюлетина за сигурност на Alpine даден сървър е уязвим само ако са изпълнени едновременно следните четири условия:

- използва се пакетът openssh-server (без PAM) или openssh-server-pam с настройка UsePAM no;

- настройката PasswordAuthentication е зададена на yes (активна по подразбиране в OpenSSH);

- на машината съществува акаунт със символ * в полето за парола (потребители с автентикация само с SSH ключ, служебни потребители през musl-nscd, или стандартният потребител alpine в облачните изображения);

- съществува поне още един локален акаунт с паролен хеш от тип $5$ или $6$ (например създадена конзолна парола от администратор).

Системи, базирани на glibc (като Debian, Ubuntu, RHEL), инсталации с изключена автентикация с парола или акаунти, заключени с удивителен знак (!) в shadow файла, **не са засегнати**. Платформи като OpenWrt по подразбиране ползват Dropbear, който не съдържа този дефект.

## Стъпки за защита и коригиране
За да защитите уязвимите машини, приложете следните конкретни мерки:

- **Обновете пакетите и рестартирайте sshd:** Инсталирането на новия пакет в Alpine не рестартира работещата услуга автоматично. Изпълнете в терминала:
apk upgrade -U -a
rc-service sshd restart

- **Забранете автентикацията с парола:** Ако не можете да приложите ъпдейта веднага, уверете се, че входът с публичен ключ работи, оставете текущата сесия отворена и задайте PasswordAuthentication no в конфигурационните файлове (в /etc/ssh/sshd_config или в директорията /etc/ssh/sshd_config.d/). Проверете синтаксиса с sshd -t и рестартирайте демона.

## Как да проверите за евентуален пробив
Прегледайте системните логове във /var/log/messages за записи от вида Accepted password for за акаунти, които не би трябвало да имат парола (като alpine, root или потребители само с ключ). Ако откриете подобни индикатори, проверете използването на команди през doas/sudo, новосъздадени файлове и модификации в authorized_keys. При невъзможност да потвърдите легитимен достъп, експертите препоръчват машината да се третира като напълно компрометирана.

---

Canonical: https://freedomonline.bg/kritichen-bag-v-openssh-i-alpine-linux-pozvolyava-otdalechen-dostap-bez-parola-kak-da-se-zashtitite/