Obejście hasła w OpenSSH na Alpine: czy dotyczy serwera?

Obejście uwierzytelniania hasłem w OpenSSH na Alpine nie dotyczy każdego serwera ani kontenera z Alpine. Sprawdź, czy działa demon SSH, czy dopuszcza uwierzytelnianie hasłem, czy korzysta z PAM i czy konta spełniają warunki opisane w komunikacie Alpine. Samo używanie kluczy SSH nie dowodzi bezpieczeństwa: uwierzytelnianie hasłem może nadal działać równolegle. Komunikat Alpine.

5 listopada 2026 r. projekt OpenSSH wydał wersję portable 10.6p2 z krytycznym obejściem problemu dla systemów Linux korzystających z musl bez PAM. Według twórców OpenSSH pierwotna przyczyna problemu leży poza sshd. Nadano już identyfikator CVE-2026-123158, choć w komunikacie Alpine początkowo informowano o jego braku. Informacje o wydaniu OpenSSH, opublikowany wpis CVE.

Poniższa tabela zbiera warunki podane przez dostawcę i pomaga ustalić, czy podatność dotyczy danej konfiguracji. Powstała na podstawie komunikatu; nie jest wynikiem skanowania twojej infrastruktury ani odtworzenia podatności. Dane o pakietach przedstawiają stan z 6 listopada. Późniejsze zmiany sprawdzaj w podlinkowanym komunikacie.

Których serwerów SSH na Alpine dotyczy podatność?

Podatna konfiguracja musi spełniać kilka warunków jednocześnie. Sama nazwa Alpine, zainstalowany pakiet OpenSSH czy pozornie stary numer wersji nie wystarczą, by je potwierdzić.

Alpine wskazuje ścieżkę uwierzytelniania bez PAM, włączone logowanie hasłem, konto spełniające wymagania komunikatu ze znakiem * w polu hasła oraz inne konto lokalne ze skrótem hasła zaczynającym się od $5$ lub $6$. Domyślny pakiet openssh-server korzysta ze ścieżki bez PAM. Zainstalowanie openssh-server-pam nie zmienia tego warunku, jeśli UsePAM nadal ma wartość no. Warunki opisane przez dostawcę.

Tabela dotyczy wyłącznie tego konkretnego obejścia. Ocena „nie dotyczy” zakłada, że ustalono aktywną konfigurację dla rozpatrywanego konta i połączenia.

Te oceny są podsumowaniem komunikatu Alpine. Nie określają ogólnego bezpieczeństwa systemu ani nie pozwalają ustalić, czy wcześniej doszło do włamania.

Ważne jest rozróżnienie stanów kont. Alpine odróżnia znak zastępczy * od blokady !; nie zakładaj, że każdy zapis w polu hasła sugerujący wyłączenie konta oznacza to samo. Warunki dotyczące kont sprawdzaj zgodnie z uprawnieniami i procedurami administracyjnymi, bez kopiowania skrótów haseł do zgłoszeń czy na czat. Nie modyfikuj pól haseł jako doraźnego sposobu obejścia problemu.

Ostrożnie interpretuj też zasady dostępu do roota. Ustawienie blokujące bezpośrednie logowanie na roota hasłem nie rozstrzyga, czy zagrożone jest inne konto spełniające warunki. Podobnie sieć prywatna ogranicza grono osób, które mogą dotrzeć do usługi, ale nie zmienia tego, czy jej konfiguracja uwierzytelniania odpowiada opisowi podatności.

Czy klucze SSH zapewniają ochronę?

„Używamy kluczy SSH” i PasswordAuthentication no to dwie różne informacje. Udane logowanie kluczem dowodzi, że uwierzytelnianie kluczem działa. Nie dowodzi, że serwer odrzuca uwierzytelnianie hasłem dla tego użytkownika lub innych użytkowników.

W małym zespole łatwo to przeoczyć: od lat nikt nie wpisuje haseł, choć demon nadal przyjmuje próby logowania hasłem. Sprawdź ustawienie serwera zamiast wyciągać wnioski ze zwyczajów zespołu. Alpine wyraźnie wymienia wyłączone uwierzytelnianie hasłem wśród konfiguracji, których to obejście nie dotyczy. Wskazówki konfiguracyjne Alpine.

To samo rozumowanie dotyczy PAM, mechanizmu uwierzytelniania używanego przez alternatywny pakiet serwera. Potwierdź zarówno pakiet, jak i aktywne ustawienie UsePAM: wpis „PAM” w wykazie pakietów to niepełna informacja, jeśli usługę skonfigurowano tak, by z niego nie korzystała.

Obrazy chmurowe wymagają osobnego sprawdzenia. W komunikacie Alpine tiny-cloud i cloud-init omówiono oddzielnie, więc nie zakładaj, że wszystkie obrazy mają tę samą konfigurację. Ustal ustawienia obrazu i późniejsze zmiany na kontach, a następnie porównaj je z uwagami dostawcy o obrazach chmurowych. Nazwa obrazu bazowego nie powie ci, co administrator zmienił po uruchomieniu.

Które pakiety Alpine zawierają poprawkę?

Alpine przeniosło poprawkę do starszych gałęzi pakietów. Porównaj swoją gałąź i pełny numer rewizji pakietu z tabelą dostawcy. Nie wymagaj, by każda maszyna zgłaszała wersję 10.6p2 wydaną przez projekt OpenSSH.

Wybrane pakiety z poprawką, sprawdzone 6 listopada:

Źródło: tabela pakietów z poprawką Alpine. To wyciąg, nie pełna tabela obsługiwanych wersji. Informacje o pozostałych gałęziach znajdziesz w komunikacie. Przeniesienie poprawki do starszej gałęzi nie przywraca wsparcia dla wydania, którego okres wsparcia się skończył.

Jeśli usługa jest podatna, wykonaj aktualizację pakietów zgodnie z instrukcją Alpine i zrestartuj sshd. Dla usługi Alpine zarządzanej przez OpenRC komunikat podaje:

rc-service sshd restart

Gdy demonem steruje kontener lub inny menedżer usług, zastosuj procedurę właściwą dla tego środowiska. Jeśli nie możesz od razu przeprowadzić aktualizacji, Alpine opisuje wyłączenie uwierzytelniania hasłem i restart usługi jako środek zaradczy. Postępuj zgodnie z instrukcją dostawcy, zamiast kopiować polecenie nadpisujące konfigurację do nieznanego środowiska.

Przed zmianą ustawień zdalnego dostępu zachowaj działającą sesję z logowaniem kluczem i dostęp do konsoli ratunkowej. Zaplanuj osobne, uprawnione logowanie kontrolne, by błąd konfiguracji nie odciął cię od serwera.

Co sprawdzić po aktualizacji?

Sprawdź konfigurację w takim samym kontekście, w jakim działa usługa, a potem potwierdź, że zmiana rzeczywiście weszła w życie. Diagnostyka konfiguracji i nowe logowanie odpowiadają na różne pytania.

Oficjalna dokumentacja opisuje sshd -t jako polecenie sprawdzające konfigurację i klucze, a sshd -T jako sposób wyświetlenia efektywnej konfiguracji po jej wczytaniu. Dodaj -C, gdy oceniasz reguły Match zależne od połączenia. Przykład:

sshd -t
sshd -T -C user=example,addr=192.0.2.10,host=example.test

Użytkownik, adres i nazwa hosta to wartości przykładowe. Zastąp je danymi sprawdzanego połączenia i sprawdź też inne przypadki, w których obowiązują odmienne reguły. Użyj tego samego pliku wykonywalnego, pliku konfiguracji i opcji uruchomienia co działająca usługa. Oficjalna dokumentacja sshd.

Te polecenia uruchamiają nowy proces, zamiast odczytywać ustawienia przechowywane przez działającego demona. Poprawny wynik nie zastępuje więc potwierdzenia, że planowany restart się zakończył i działa usługa z poprawką.

Po zmianie otwórz osobną, uprawnioną sesję z logowaniem kluczem, zachowując dotychczasowy dostęp. Potwierdź, że wybrane konto nadal działa, a usługa ma oczekiwane ustawienia uwierzytelniania. Nie próbuj wykorzystywać obejścia w środowisku produkcyjnym, by upewnić się, że jest bezpieczne. Udane nowe logowanie sprawdza dostęp; nie dowodzi, że uwierzytelnianie hasłem jest wyłączone ani że wcześniej nie doszło do włamania.

Przypisz odpowiedzialność za niewyjaśnione ustawienia

Zapisuj nierozstrzygnięte warunki tak, by były widoczne. Adnotacja „nieznane ustawienie PAM” lub „restart niepotwierdzony” mówi kolejnemu inżynierowi, co trzeba jeszcze ustalić. Ogólna etykieta „Alpine sprawdzone” ukrywa tę pracę.

Jeśli podatna usługa pojawi się w zgłoszeniu podatności, Kit do obsługi zgłoszeń podatności pozwala w jednym miejscu zapisać, kto odpowiada za zgłoszenie, oraz przechowywać ocenę, dyskusję wewnętrzną i zapis weryfikacji poprawki. Dane potwierdzające stan hosta i usługi nadal dostarcza administrator. Obsługa zgłoszenia nie wykrywa automatycznie serwerów Alpine ani nie weryfikuje stanu demona.

Zacznij od usługi, którą zespół może teraz sprawdzić: ustal sposób uwierzytelniania, porównaj wersję pakietu z wersją zawierającą poprawkę Alpine dla właściwej gałęzi i potwierdź wymaganą zmianę w usłudze. Przypisz pozostałe pytania o konfigurację konkretnym osobom i pozostaw je otwarte, aż uda się je rozstrzygnąć.