Diagnozuj błędy logowania do SLES PAM bez blokowania dostępu

Komunikat „Błąd uwierzytelniania PAM” nie wskazuje na jedno uniwersalne rozwiązanie. Najpierw zidentyfikuj usługę i użytkowników, którzy nie przeszli pomyślnie, a następnie sprawdź dziennik w odpowiednim momencie. W systemie SUSE Linux Enterprise Server (SLES) napraw potwierdzony globalny problem z PAM za pomocą [brakuje kontekstu] pam-configi zmień plik pojedynczej usługi tylko wtedy, gdy jej własny stos jest nieprawidłowy. Podczas testowania utrzymuj otwartą sesję root lub administracyjną; uszkodzony stos PAM może blokować nowe logowania SSH i konsoli.

Aktualny podręcznik bezpieczeństwa i utwardzania SLES 15 SP7 opisuje PAM jako stos modułów uwierzytelniania, konta, hasła i sesji. To rozróżnienie ma znaczenie: poprawne hasło może przejść etap, autha mimo to zostać odrzucone później przez politykę konta lub regułę specyficzną dla usługi. Sam ogólny komunikat o błędzie nie pozwala na identyfikację, który etap zakończył się niepowodzeniem.

Co dowodzi błąd, a czego nie?

PAM pośredniczy między aplikacją, taką jak sshdlogowanie do konsoli, a skonfigurowanymi metodami uwierzytelniania. Każda usługa obsługująca PAM ma plik w katalogu /etc/pam.d/. Plik usługi może zawierać wspólne pliki SLES, takie jak , , common-authwięc common-accountawaria ograniczona do SSH może mieć inną przyczynę niż awarie wszystkich metod logowania.

Zweryfikowano: Udokumentowany stos SSH systemu SUSE zawiera pam_nologin.sotypowe pliki PAM. Jeśli /etc/nologinistnieje, udokumentowany moduł blokuje logowanie użytkowników innych niż root. Zależne od kontekstu: lokalnie edytowane reguły, usługi katalogowe i zewnętrzne moduły MFA mogą dodać dodatkowe kontrole. Nie można ustalić na podstawie samego komunikatu: że hasło jest nieprawidłowe, że pliki PAM są uszkodzone lub że konto jest zablokowane. Zamiast zastępować stos, należy zacząć od usługi, której dotyczy problem, i jej logu.

Która ścieżka logowania nie działa?

Powtórz błąd raz i zanotuj czas, nazwę użytkownika i metodę: SSH, lokalna konsola tekstowa, logowanie graficzne sudolub su. Jeśli możesz zalogować się jako administrator, sprawdź ostatnie komunikaty systemowe:

sudo journalctl -e

Poradnik rozwiązywania problemów SLES firmy SUSE zaleca sprawdzenie dziennika pod kątem błędów logowania i PAM. Sprawdź dokładny czas próby, aby znaleźć nazwę modułu lub przyczynę – na przykład odrzucone konto, niedostępna usługa katalogowa, brakujący moduł lub błąd pliku/uprawnień. Nie udostępniaj dzienników publicznie bez usunięcia nazw użytkowników, nazw hostów, adresów i innych poufnych informacji.

Jeśli występuje tylko awaria SSH, sprawdź dziennik demona SSH:

sudo journalctl -u sshd

Następnie porównaj ścieżki dostępu. Jeśli użytkownik może uwierzytelnić się na konsoli lokalnej, ale nie przez SSH, skup się na /etc/pam.d/sshdzasadach dostępu SSH lub module specyficznym dla SSH. Jeśli wiele usług odrzuca tych samych użytkowników lokalnych, sprawdź ich współdzielone common-*pliki. Jeśli uwierzytelnienie tylko jednego użytkownika nie powiedzie się, sprawdź stan konta i hasło przed zmianą uwierzytelniania w całym systemie.

Czy jest to konto lokalne czy tożsamość sieciowa?

W przypadku użytkownika lokalnego należy najpierw sprawdzić nazwę użytkownika, układ klawiatury i klawisz Caps Lock. Jeśli konieczne jest zresetowanie danych logowania, należy skorzystać z narzędzia do zmiany hasła zatwierdzonego przez administratora, takiego jak YaST User and Group Management, zamiast edytować je /etc/shadowręcznie. Jeśli wszyscy użytkownicy inni niż root mają zablokowane dostępy przez SSH, /etc/nologinprzed zmianą ustawień PAM należy sprawdzić, czy istnieje plik planowanej konserwacji, taki jak [brakujący element]. Należy go usunąć tylko wtedy, gdy blokada konserwacji okaże się nieaktualna i użytkownik ma odpowiednie uprawnienia.

W przypadku użytkowników LDAP, Active Directory lub innych użytkowników korzystających z usług katalogowych, działające hasło na innym serwerze nie dowodzi, że dany host SLES może nawiązać połączenie z dostawcą tożsamości. SUSE wymienia problemy z siecią i DNS, przesunięcie zegara Kerberos, błędnie skonfigurowane reguły PAM, zasady dostępu do hosta oraz niedostępne katalogi domowe jako możliwe przyczyny. Sprawdź, czy inny użytkownik domeny może się zalogować i czy dany użytkownik może zalogować się do innego hosta. Następnie sprawdź skonfigurowaną usługę tożsamości i łączność z serwerem.

Jeśli host używa SSSD, sprawdź jego usługę i to, czy PAM jest skonfigurowany do jej używania:

systemctl status sssd
sudo pam-config --query --sss

Usługa SSSD może buforować informacje o użytkowniku i umożliwiać uwierzytelnianie, gdy katalog jest tymczasowo niedostępny, ale to zachowanie zależy od konfiguracji i danych uwierzytelniających zapisanych w pamięci podręcznej. Nieaktualna lub brakująca pamięć podręczna to zatem tylko jedna z możliwości, a nie ostateczny wniosek. Przed wyczyszczeniem pamięci podręcznej lub zmianą modułów sprawdź DNS, synchronizację czasu dla Kerberos, dostępność katalogu oraz dzienniki SSSD. Jeśli dostawca tożsamości zgłasza komunikat „Konto zablokowane” lub „Konto wyłączone”, poproś administratora katalogu o sprawdzenie zasad dotyczących tego konta; PAM raportuje decyzję, a niekoniecznie ją tworzy.

Jak naprawić potwierdzony problem z konfiguracją PAM?

Sprawdź plik specyficzny dla usługi i zawarte w nim współdzielone reguły:

sudo grep -nE '^(auth|account|password|session)' /etc/pam.d/sshd
sudo pam-config --query --sss

W systemie SLES pam-configpliki globalne są przechowywane w sekcji /etc/pam.d/common-*; poszczególne pliki usług, takie jak te, /etc/pam.d/sshdktóre są przechowywane oddzielnie. Nie edytuj ręcznie wygenerowanych plików wspólnych, chyba że celowo pam-configje wyłączono. Jeśli potwierdzisz, że ten host ma korzystać z SSSD, a jego reguły PAM SSSD są niedostępne, SUSE zaleca sudo pam-config --add --sssich dodanie. Użyj tej funkcji dopiero po potwierdzeniu, że sam SSSD jest skonfigurowany i uruchomiony, a następnie przetestuj nowe logowanie, gdy aktywna sesja administracyjna pozostaje otwarta.

Częstym, ale ryzykownym błędnym przekonaniem jest to, że pam-config --createjest to nieszkodliwe polecenie naprawy. SUSE twierdzi, że tworzy ono podstawową konfigurację uwierzytelniania Unix i nadpisuje istniejące pliki, którymi nie zarządza, zachowując kopie zapasowe. Może to spowodować usunięcie niestandardowego działania uwierzytelniania MFA lub katalogów. Nie należy uruchamiać tego polecenia jako ogólnego kroku odzyskiwania. W przypadku literówki w pliku usługi, należy przywrócić znaną, dobrą konfigurację usługi, zgodną z wersją, z zaufanej kopii zapasowej lub zmienić konkretny wadliwy wiersz w ramach procesu zmian w organizacji.

Jak można potwierdzić naprawę?

Pozostaw oryginalną sesję roota lub administratora otwartą. Uruchom drugą sesję za pośrednictwem tej samej usługi, która uległa awarii – na przykład nowego połączenia SSH – i przetestuj konto, którego dotyczy problem. Upewnij się, że dziennik nie rejestruje już tej samej odmowy uwierzytelnienia PAM i że inna skonfigurowana metoda uwierzytelniania nadal działa. Jeśli awaria nadal występuje, zapisz dokładny znacznik czasu, usługę, nazwę modułu PAM i odpowiednie zdezynfekowane wiersze dziennika; te dane są bardziej przydatne niż ogólny komunikat o błędzie uwierzytelniania.

Oficjalne źródła

• Podręcznik administratora SUSE SLES 15 SP7: Częste problemy i ich rozwiązania — rozwiązywanie problemów z logowaniem lokalnym i sieciowym.
• Podręcznik bezpieczeństwa i wzmacniania zabezpieczeń systemu SUSE SLES 15 SP7: uwierzytelnianie za pomocą PAM — etapy PAM, stos SSH i pam-config.
• SUSE SLES 15 SP7: Konfigurowanie klientów uwierzytelniania przy użyciu YaST — stan SSSD i zachowanie pamięci podręcznej.
• SUSE SLES 15 SP7: Zabezpieczanie operacji sieciowych za pomocą OpenSSH — przeglądanie komunikatów dziennika sshd.