Ing. Calogero Bono
5 listopada 2026 ukazał się OpenSSH 10.6p2, który naprawia błąd o nazwie «*sshole». Dotyczy serwerów SSH na Linuksie z biblioteką musl, jak Alpine Linux, z wyłączonym PAM. Kto dotrze do portu SSH, może wejść na konto bez hasła, wysyłając bardzo długie hasło. Ma to znaczenie, bo wystarczy jedno połączenie, a oficjalne obrazy chmurowe Alpine mogą dać dostęp jako root.
Kilka pojęć, zanim przejdziemy do faktów. musl to alternatywna biblioteka C wobec glibc, używana w Alpine, OpenWrt, Buildroot i Yocto. crypt() to funkcja, która przekształca hasło w jego hash. PAM to modułowy system uwierzytelniania Linuksa. /etc/shadow to plik przechowujący hashe haseł. doas to narzędzie, podobne do sudo, służące do uzyskania uprawnień root.
Jak działa błąd *sshole?
Konto Linuksa bez hasła ma gwiazdkę zamiast hasha w /etc/shadow. Żadne hasło nie powinno go otworzyć. Według BleepingComputer, zmiana w OpenSSH z 2016 roku, wprowadzona by naprawić CVE-2016-6210 dotyczące enumeracji użytkowników, sprawia, że hash jest obliczany także dla tych kont.
Tu wchodzi musl. Jak wyjaśnia ostrzeżenie Alpine, funkcja crypt() w musl zwraca * jako sygnał błędu, jeśli klucz przekracza 256 bajtów. Ta gwiazdka pokrywa się z tą zapisaną w koncie, więc porównanie się udaje. Badacz Özgün Kültekin twierdzi, że błąd istnieje od 2016 roku.
Kto naprawdę jest zagrożony?
Potrzeba kilku warunków jednocześnie. Według Alpine pakiet openssh-server jest skompilowany bez PAM albo używany jest openssh-server-pam z UsePAM no. PasswordAuthentication musi być włączone, jak domyślnie. Potrzebne jest konto z * i co najmniej jedno z haszem $5$ lub $6$. Wystarczy jeden użytkownik z hasłem, by pozostałe konta stały się osiągalne.
Alpine sprawdziło wersje od 3.21 do 3.24 i edge, a także starsze 3.16-3.20. Nie są dotknięte kontenery bez sshd, systemy z PasswordAuthentication no oraz systemy z aktywnym PAM. Debian, Ubuntu i Fedora, które używają glibc, nie są podatne, pisze BleepingComputer.
Dlaczego obrazy chmurowe Alpine budzą obawy?
Oficjalne obrazy tiny-cloud, od 3.18.11 do 3.24.3, mają użytkownika alpine z hasłem * i doas bez hasła. Alpine zaznacza, że przy pierwszym uruchomieniu są bezpieczne. Stają się podatne, gdy pojawi się hash $6$, na przykład gdy administrator ustawi hasło konsoli albo gdy user-data doda użytkownika z hashed_passwd.
Wtedy atakujący uzyskuje powłokę jako alpine, a przez doas zostaje rootem. Obrazy skonfigurowane przez cloud-init, który ustawia PasswordAuthentication no, nie są dotknięte. Co do roota, domyślne PermitRootLogin prohibit-password chroni go tylko bezpośrednio.
Jak to naprawić i jak sprawdzić, czy doszło do ataku?
Poprawka jest w OpenSSH 10.6p2. Na Alpine używa się apk upgrade -U -a, a potem restartuje sshd, bo aktualizacja nie zastępuje działającego demona. Alpine opublikowało poprawione pakiety aż do wersji 3.16, także dla wydań, które nie są już wspierane.
Jeśli nie możesz zaktualizować, ustaw PasswordAuthentication no i zrestartuj sshd, po sprawdzeniu, czy logowanie kluczem działa. Aby poszukać śladów, przejrzyj w /var/log/messages wpisy «Accepted password» dla kont bez hasła. Alpine dodaje, że jeśli nie można wykluczyć dostępu, maszynę należy uznać za przejętą. Dla uprawnień kont warto też przeczytać przewodnik o uprawnieniach w Linuksie.
Ograniczenia, które warto znać
Alpine zaznacza, że w chwili publikacji nie przypisano jeszcze żadnego CVE. OpenSSH pisze, że przyczynę trzeba szukać poza sshd, ale wykorzystać ją można przez sshd i właśnie tam jest ona omijana. Nie ma danych o trwających atakach w realnym świecie. Informacje o 17 600 testach z agentami AI pochodzą od badacza, przytoczone przez BleepingComputer, i nie zostały niezależnie zweryfikowane.
Co zmienia się dla osób pracujących z technologiami cyfrowymi
Jeśli zarządzasz serwerami Alpine, routerami OpenWrt albo systemami embedded z Yocto i Buildroot, sprawdź, czy sshd dopuszcza hasła i czy są konta z *. Wiele osób używa Alpine w kontenerach bez sshd i nie są one dotknięte. Kto ma maszyny chmurowe z obrazami tiny-cloud, musi sprawdzić każdą już działającą instancję. Serwer zarządzany z regularnymi aktualizacjami ogranicza tego typu ryzyko, o czym piszemy na stronie o hostingu i zarządzanych serwerach. Warto też śledzić powiązany przypadek exploitów generowanych przez AI, o którym pisaliśmy w tym artykule.
Nasza opinia
Ta historia pokazuje, jak krucha bywa granica między komponentami, które sobie ufają. OpenSSH dodała w 2016 roku uzasadnioną obronę, musl wybrało typową wartość błędu, a razem otworzyły furtkę na dziesięć lat. Zastanawia też, że błąd znaleziono za pomocą agentów AI. Sama OpenSSH ostrzega, że błędy znalezione przez AI są często ponownie odkrywane przez innych, więc czekanie jest ryzykowne. Najskuteczniejsze rozwiązanie pozostaje takie samo jak zawsze, klucze zamiast haseł.
Najczęstsze pytania
Czy Debian i Ubuntu są podatne na *sshole?
Nie. Używają glibc, a nie biblioteki musl. BleepingComputer potwierdza, że systemy z uwierzytelnianiem PAM nie są podatne, ale Alpine precyzuje, że openssh-server-pam z UsePAM no jest bezpieczny, a z UsePAM yes już nie.
Wystarczy zaktualizować pakiet openssh?
Nie, trzeba też zrestartować sshd. Alpine zaznacza, że aktualizacja nie zastępuje demona, który już działa, więc podatna wersja pozostałaby aktywna.
Czy mogę się chronić bez aktualizacji?
Tak, tymczasowo. Ustaw PasswordAuthentication no w konfiguracji sshd i zrestartuj usługę. Najpierw sprawdź, czy logowanie kluczem działa.
Czy także root jest narażony?
Tylko w pewnych przypadkach. Przy PermitRootLogin prohibit-password, czyli wartości domyślnej, root nie jest bezpośrednio dostępny. Staje się dostępny, jeśli włączone jest PermitRootLogin yes albo jeśli inny użytkownik może zostać rootem, na przykład przez doas.
Czy istnieje CVE dla tego błędu?
Na razie nie, według Alpine. Ostrzeżenie mówi, że w chwili pisania nie przypisano żadnego identyfikatora. Punktem odniesienia są informacje o wydaniu OpenSSH 10.6p2.
Co obserwować po OpenSSH 10.6p2
OpenSSH zapowiedziało częstsze wydania, by poprawki szybciej docierały do użytkowników. Błąd zostawia kilka otwartych kwestii, które warto śledzić.
- Sprawdź, czy zostanie przypisane CVE i czy twoje narzędzia do skanowania je rozpoznają.
- Obserwuj, kiedy producenci firmware'u opartego na OpenWrt, Buildroot i Yocto opublikują aktualizacje.
- Przygotuj procedurę instalowania drobnych wydań OpenSSH bez czekania na zaplanowane wersje.
