Luka w OpenSSH na Alpine: logowanie bez hasła. Co zrobić

Na Alpine Linuxie OpenSSH bez PAM wpuszczał każdego, kto dosięgnął portu SSH, na konto bez hasła, jeśli ten wpisał dowolne hasło o długości od 257 do 1024 bajtów. Warunek: na tej samej maszynie jest choć jedno konto z prawdziwym hasłem, a logowanie hasłem jest włączone, jak domyślnie. Alpine opisało to w biuletynie z 5 listopada 2026 roku i tego samego dnia wydało poprawione pakiety dla wszystkich wydań od 3.16. Po aktualizacji trzeba zrestartować sshd, bo działający demon dalej używa starego kodu. Debiana, Ubuntu i RHEL, które działają na glibc i sprawdzają hasła przez PAM, luka nie dotyczy. Numeru CVE jeszcze nie nadano, a ani Alpine, ani OpenSSH nie informują o wykorzystaniu luki w atakach. Stan na 5 listopada 2026 roku, godz. 17:10, według biuletynu Alpine, notatek do wydania OpenSSH 10.6p2 i opisu odkrywcy.

Co naprawia OpenSSH 10.6p2

Wydanie 10.6p2 z 5 listopada 2026 roku zawiera jedną poprawkę bezpieczeństwa. Notatki do wydania opisują ją jako “critical security workaround that affects Linux systems that use the musl libc and PAM disabled”. Po polsku: krytyczne obejście problemu w Linuksach z biblioteką musl i wyłączonym PAM. Musl to biblioteka standardowa języka C, na której stoi Alpine, a PAM to moduł, przez który system zwykle sprawdza hasła.

Autorzy poprawki zaznaczają, że przyczyna leży poza sshd. Błąd “is exploitable via sshd and can be avoided there”, czyli da się go wykorzystać przez sshd i tam da się go zablokować. Lukę zgłosił Özgün Kültekin z firmy Wakefield.

Alpine wydało równolegle biuletyn bezpieczeństwa i nowe wydania 3.21.10, 3.22.8, 3.23.8 oraz 3.24.4. Według biuletynu atak “takes one connection, works every time, and needs no retries”, czyli wymaga jednego połączenia, działa za każdym razem i nie potrzebuje powtórzeń. Do 17:10 numeru CVE nie było ani w biuletynie, ani w bazie luk Alpine.

Kogo dotyczy luka w OpenSSH na Alpine Linux

Luka dotyczy maszyny, która spełnia jednocześnie cztery warunki z biuletynu Alpine:

Działa na niej pakiet openssh-server, który Alpine buduje bez PAM, albo openssh-server-pam z ustawieniem UsePAM no.
PasswordAuthentication ma wartość yes. To wartość domyślna.
Istnieje konto, które w polu hasła ma sam znak *, czyli konto bez ustawionego hasła.
Co najmniej jedno inne lokalne konto ma hash hasła zaczynający się od $5$ albo $6$ .

Napastnik musi znać nazwę konta z gwiazdką. Wystarczy jeden użytkownik z hasłem, żeby otworzyć wszystkie konta bez hasła. Alpine sprawdziło wydania 3.16–3.24 i edge. Błąd jest w każdym z nich.

Konta z gwiazdką są w Alpine częste. Biuletyn wymienia:

root, który od mniej więcej wydania 3.16 ma w obrazie bazowym wpis root:*; chroni go domyślne PermitRootLogin prohibit-password, ale nie chroni, gdy inne konto może zostać rootem, na przykład przez doas;
użytkowników logujących się tylko kluczem, założonych przez adduser bez hasła albo przez usermod -p '*';
użytkowników z usługi katalogowej przez musl-nscd (nslcd, winbind, sssd), bo nie mają wpisu w /etc/shadow;
użytkownika alpine w oficjalnych obrazach chmurowych tiny-cloud.

Obrazy chmurowe z kontem alpine i doas

Oficjalne obrazy tiny-cloud od 3.18.11 do 3.24.3 (pliki qcow2, VHD i AMI) mają konto alpine z gwiazdką i doas bez hasła. Po pierwszym uruchomieniu są bezpieczne. Według Alpine stają się podatne, gdy na maszynie pojawi się dowolny hash $6$ . Wystarczy, że administrator ustawi hasło do konsoli albo dane startowe doda użytkownika z hashed_passwd. Napastnik loguje się wtedy jako alpine, a przez doas zostaje rootem.

Kogo luka nie dotyczy: Debian, Ubuntu, Docker bez sshd

Debian, Ubuntu, Fedora i RHEL nie są podatne, bo używają glibc i sprawdzają hasła przez PAM. Odkrywca wymienia też Dropbeara i OpenBSD jako bezpieczne. Biuletyn Alpine dodaje do listy niepodatnych:

kontenery Dockera i inne, w których nie działa sshd;
systemy z PasswordAuthentication no;
openssh-server-pam z UsePAM yes;
konta zablokowane, czyli z ! w polu hasła w /etc/shadow;
maszyny, na których żadne konto nie ma hasha zaczynającego się od $;
obrazy chmurowe konfigurowane przez cloud-init, który zapisuje PasswordAuthentication no.

Sam obraz alpine w Dockerze niczego nie wystawia. Problem ma kontener, w którym ktoś uruchomił własny sshd na Alpine i zostawił logowanie hasłem. OpenWrt według listy pakietów domyślnych w kodzie źródłowym projektu instaluje Dropbeara. Sprawdzić trzeba router, na którym Dropbeara zastąpiono OpenSSH. Urządzenia budowane na Buildroot czy Yocto mogą być podatne, jeśli działają na musl i spełniają wszystkie cztery warunki opisane wyżej. Ich konfigurację i komunikaty producenta trzeba sprawdzić osobno.

Jak sprawdzić serwer z Alpine w minutę

Trzy polecenia wpisane jako root pokażą, czy konfiguracja serwera spełnia warunki luki:

Wpisz apk list --installed 'openssh*'. Zobaczysz, czy masz openssh-server, czy openssh-server-pam, i w jakiej wersji. Opcję --installed opisuje podręcznik apk-list.
Wpisz sshd -T | grep -i passwordauthentication. Polecenie sshd -T wypisuje konfigurację, z którą sshd faktycznie działa. Wynik passwordauthentication yes oznacza, że ten warunek jest spełniony. Jeśli konfiguracja ma bloki Match, dopisz parametry połączenia, na przykład sshd -T -C user=deploy,addr=198.51.100.7. Według podręcznika sshd dopiero wtedy polecenie uwzględni pasujące bloki Match.
Na pakiecie z PAM wpisz sshd -T | grep -i usepam. Wynik usepam no oznacza, że spełniony jest warunek braku PAM. Według podręcznika no to wartość domyślna, więc wystarczy brak wiersza UsePAM yes w konfiguracji. Na pakiecie bez PAM ten wiersz się nie pokaże, bo tej opcji tam nie ma. To ustaliliśmy w kodzie źródłowym sshd (plik servconf.c).

Konta z gwiazdką i konta z hasłem wypisze awk:

awk -F: '$2 == "*" {print $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow

Pierwsze polecenie podaje konta bez hasła, drugie konta z hashem $5$ albo $6$ . Oba sprawdziliśmy 5 listopada na pliku testowym (GNU Awk 5.0). Serwer jest podatny do czasu aktualizacji, gdy spełnia cztery warunki naraz. Działa pakiet bez PAM albo usepam no, passwordauthentication ma wartość yes, a oba polecenia awk zwracają nazwy kont.

Jak załatać: aktualizacja i restart sshd

Zaktualizuj pakiety i zrestartuj sshd, bo według Alpine “upgrading the package does not restart a running sshd”. Dwa polecenia z biuletynu:

apk upgrade -U -a
rc-service sshd restart

Wersje pakietu z poprawką według biuletynu Alpine:

Gałąź Alpine	Wersja pakietu z poprawką
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Źródło: biuletyn Alpine z 5 listopada 2026 roku, odczyt tego dnia o 16:46. Wydanie 3.21 straciło wsparcie 1 listopada, ale Alpine i tak wydało dla niego poprawkę, tak samo jak dla 3.16–3.20. Obrazy chmurowe zbudowane z 3.21.10, 3.22.8, 3.23.8, 3.24.4 i nowszych mają już poprawiony pakiet. Na maszynach uruchomionych ze starszych obrazów aktualizację trzeba zrobić ręcznie.

Gdy nie możesz zaktualizować: wyłącz logowanie hasłem

Wyłączenie logowania hasłem też zamyka lukę. Najpierw sprawdź, że logujesz się kluczem, i nie zamykaj bieżącej sesji, zanim nie przetestujesz nowego logowania. Polecenia z biuletynu Alpine, jako root:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

Ostatnie polecenie ma wypisać passwordauthentication no. Katalog sshd_config.d Alpine czyta od wydania 3.19, dlatego sed zmienia też główny plik, także wewnątrz bloków Match. Kopia oryginału ląduje w /etc/ssh/sshd_config.bak. Logowanie wyłącznie kluczem warto mieć i tak, co opisaliśmy w poradniku o zabezpieczaniu serwera VPS.

Jak sprawdzić, czy ktoś się już zalogował

Przejrzyj /var/log/messages i szukaj wierszy sshd Accepted password for przy koncie, które nie ma hasła: alpine, root albo użytkowniku logującym się tylko kluczem. Pomoże polecenie grep "Accepted password" /var/log/messages, które sprawdziliśmy na testowym dzienniku. Biuletyn zaleca też przejrzeć użycie doas, niedawno założonych użytkowników, zmienione pliki i klucze w authorized_keys. Jeśli nie da się wykluczyć logowania, Alpine każe traktować maszynę jako przejętą. W praktyce oznacza to postawienie jej od nowa z kopii sprzed incydentu.

Jak działa obejście hasła w musl

Bez PAM sshd sprawdza hasło sam. Liczy funkcją crypt() skrót wpisanego hasła i porównuje go z polem w /etc/shadow. Konto z samą gwiazdką nie ma soli, czyli losowego początku skrótu. Wtedy sshd pożycza sól innego konta. Według odkrywcy to poprawka luki CVE-2016-6210 z 2016 roku, która pozwalała po czasie odpowiedzi rozpoznać, czy użytkownik istnieje.

Musl odrzuca w crypt() klucze dłuższe niż 256 bajtów i zwraca wtedy błąd w postaci znaku *. Dokładnie to samo stoi w polu hasła każdego konta bez hasła. Porównanie wychodzi zgodne i sshd wpuszcza. Według Alpine OpenSSH 10.6p2 omija problem w sshd, a pakiety dla starszych gałęzi dostały łatkę na to samo.

Kültekin opisał na stronie sshhole.com historię błędu z odnośnikami do zmian w musl, w kodzie sshd i w pakietach Alpine. Zbudował sshd we wszystkich wariantach (glibc, musl, z PAM i bez) i według własnego opisu wypróbował na nich około 17 600 nietypowych logowań. Pracował z pomocą wielu agentów AI (“agent swarms”). Wszystkie warianty dawały ten sam wynik poza jednym: musl bez PAM wpuszczał tam, gdzie nie powinien. Zespół OpenSSH od października pisze w notatkach do wydań, że dostaje dużo zgłoszeń znalezionych przez AI lub z jej pomocą. Wydania z poprawkami mają wychodzić częściej, bo błędy wskazane przez AI odkrywali potem niezależnie inni badacze.

{ dla firm }

Co możemy zrobić dla Twojej firmy?

Budujemy strony, sklepy i aplikacje, łączymy systemy z KSeF i księgowością, wdrażamy automatyzacje i agentów AI, a na koniec dbamy o widoczność w Google. Zaczynamy od rozmowy o tym, co dziś zabiera Twojemu zespołowi najwięcej czasu.

strony i sklepyaplikacjeKSeF i integracjeautomatyzacjeagenci AISEO

Zobacz, co robimy dla firm → Software house, który prowadzi ten blog

Podsumowanie

OpenSSH na Alpine Linux bez PAM wpuszczał na konta bez hasła każdego, kto podał hasło dłuższe niż 256 bajtów. Warunkiem było włączone logowanie hasłem i choć jedno konto z prawdziwym hasłem. Alpine wydało poprawione pakiety dla wydań od 3.16 do edge, a OpenSSH wydanie 10.6p2. Podatne mogą być między innymi obrazy chmurowe z kontem alpine i doas oraz kontenery z własnym sshd, jeśli spełniają wszystkie cztery warunki. Debian, Ubuntu i RHEL tej luki nie mają. Na każdej maszynie z Alpine i sshd zrób dziś apk upgrade -U -a i rc-service sshd restart. Jeśli nie możesz, ustaw PasswordAuthentication no. Potem sprawdź w /var/log/messages, czy konto bez hasła nie przyjęło logowania hasłem. Przy Debianie i Ubuntu zostaje osobna sprawa z tego tygodnia, czyli luka w APT.