Diagnosticați erorile de conectare la SLES PAM fără a vă bloca accesul

Un mesaj „Eroare de autentificare PAM” nu indică o soluție universală. Mai întâi identificați ce serviciu și utilizatori eșuează, apoi verificați jurnalul la momentul corespunzător. Pe SUSE Linux Enterprise Server (SLES), reparați o problemă PAM globală confirmată prin pam-configși modificați un fișier de serviciu individual numai atunci când propria stivă este greșită. Mențineți deschisă o sesiune root sau administrativă funcțională în timpul testării; o stivă PAM defectă poate bloca noi conectări SSH și la consolă.

Ghidul actual de securitate și consolidare SLES 15 SP7 descrie PAM ca o stivă de module de autentificare, cont, parolă și sesiune. Această distincție contează: o parolă corectă poate trece de authetapă și totuși poate fi respinsă ulterior de o politică de cont sau de o regulă specifică serviciului. Un mesaj generic de eroare nu poate identifica singur ce etapă a eșuat.

Ce dovedește eroarea — și ce nu dovedește?

PAM mediază între o aplicație, cum ar fi sshdsau autentificarea în consolă, și metodele de autentificare configurate. Fiecare serviciu compatibil PAM are un fișier sub /etc/pam.d/. Fișierul serviciului poate include fișiere comune SLES, cum ar fi common-authși common-account, astfel încât o eroare izolată la SSH poate avea o cauză diferită față de eșecurile din toate metodele de autentificare.

Verificat: Stiva SSH documentată de SUSE include pam_nologin.sofișiere PAM comune. Dacă /etc/nologinexistă, modulul documentat refuză autentificările altor utilizatori în afară de root. Depinde de context: regulile editate local, serviciile de directoare și modulele MFA terțe pot adăuga verificări suplimentare. Nu se stabilește doar prin mesaj: că parola este greșită, că fișierele PAM sunt corupte sau că contul este blocat. Începeți cu serviciul afectat și jurnalul său în loc să înlocuiți stiva.

Care cale de conectare eșuează?

Reproduceți eroarea o dată și notați ora, numele de utilizator și metoda: SSH, consolă text locală, autentificare grafică, sudo, sau su. Dacă vă puteți conecta ca administrator, verificați mesajele recente de sistem:

sudo journalctl -e

Ghidul de depanare SLES de la SUSE recomandă în mod specific verificarea jurnalului pentru erori de conectare și PAM. Verificați ora exactă a încercării de a găsi numele modulului sau motivul - cum ar fi un cont refuzat, un serviciu de director indisponibil, un modul lipsă sau o eroare de fișier/permisiune. Nu partajați public jurnalele fără a elimina numele de utilizator, numele de gazdă, adresele și alte detalii sensibile.

Dacă doar SSH eșuează, verificați jurnalul daemonului SSH:

sudo journalctl -u sshd

Apoi comparați căile de acces. Dacă un utilizator se poate autentifica la consola locală, dar nu prin SSH, concentrați-vă pe /etc/pam.d/sshd, politica de acces SSH sau un modul specific SSH. Dacă mai multe servicii resping aceiași utilizatori locali, inspectați common-*fișierele lor partajate. Dacă un singur utilizator eșuează, verificați starea contului și parola înainte de a modifica autentificarea la nivel de sistem.

Este acesta un cont local sau o identitate de rețea?

Pentru un utilizator local, verificați mai întâi numele de utilizator, aspectul tastaturii și tastatura Caps Lock. Dacă este necesară o resetare a credențialelor, utilizați instrumentul de gestionare a parolelor aprobat de administrator, cum ar fi YaST User and Group Management, în loc să editați /etc/shadowmanual. Dacă toți utilizatorii non-root sunt refuzați prin SSH, verificați dacă /etc/nologinexistă un fișier de întreținere planificată, cum ar fi PAM, înainte de a modifica PAM; eliminați-l numai dacă se confirmă că blocul de întreținere este învechit și sunteți autorizat.

Pentru LDAP, Active Directory sau un alt utilizator bazat pe director, o parolă funcțională pe un alt server nu dovedește că această gazdă SLES poate ajunge la furnizorul de identitate. SUSE listează problemele de rețea și DNS, deviația de ceas Kerberos, regulile PAM configurate greșit, politica de acces la gazdă și directoarele principale indisponibile printre cauzele posibile. Testați dacă un alt utilizator de domeniu se poate conecta și dacă utilizatorul afectat se poate conecta la o altă gazdă. Apoi verificați serviciul de identitate configurat și conectivitatea serverului.

Când gazda folosește SSSD, verificați serviciul său și dacă PAM este configurat să îl utilizeze:

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

SSSD poate stoca în cache informațiile utilizatorilor și poate permite autentificarea în timp ce directorul este temporar inaccesibil, dar acest comportament depinde de configurația sa și de acreditările stocate în cache. Prin urmare, o memorie cache învechită sau lipsă este o posibilitate, nu o concluzie. Verificați DNS, sincronizarea timpului pentru Kerberos, accesibilitatea directorului și jurnalele SSSD înainte de a goli memoria cache sau de a modifica modulele. Dacă furnizorul de identitate raportează „Cont blocat” sau „Cont dezactivat”, solicitați administratorului directorului să verifice politica contului respectiv; PAM raportează decizia, nu o creează neapărat.

Cum ar trebui să remediați o problemă de configurare PAM confirmată?

Inspectați fișierul specific serviciului și regulile partajate pe care le include:

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

Pe SLES, pam-configfișierele globale sunt menținute sub /etc/pam.d/common-*; fișierele individuale de service, cum ar fi, /etc/pam.d/sshdsunt menținute separat. Nu editați manual fișierele comune generate decât dacă pam-configle-ați dezactivat în mod deliberat. Dacă confirmați că această gazdă ar trebui să utilizeze SSSD și că regulile sale SSSD PAM lipsesc, SUSE documentează sudo pam-config --add --ssspentru a le adăuga. Folosiți-l numai după ce confirmați că SSSD în sine este configurat și rulează, apoi testați o nouă autentificare în timp ce sesiunea administrativă funcțională rămâne deschisă.

O concepție greșită des întâlnită, dar riscantă, este că pam-config --createaceastă comandă de reparare este inofensivă. SUSE spune că creează o configurație de autentificare Unix de bază și suprascrie fișierele preexistente pe care nu le gestionează, păstrând copii de rezervă. Acest lucru poate elimina comportamentul personalizat de autentificare a directorului sau de autenticare a autentificarii. Nu o executați ca un pas generic de recuperare. Pentru o greșeală de scriere a fișierului de serviciu, restaurați configurația cunoscută, corespunzătoare versiunii, a serviciului respectiv dintr-o copie de rezervă de încredere sau modificați linia defectuoasă specifică din procesul de modificare al organizației dvs.

Cum poți confirma reparația?

Lăsați deschisă sesiunea inițială root sau de administrator. Porniți o a doua sesiune prin același serviciu care a eșuat — cum ar fi o nouă conexiune SSH — și testați contul afectat. Confirmați că jurnalul nu mai înregistrează aceeași refuzare PAM și că o altă metodă de autentificare configurată funcționează în continuare. Dacă eroarea persistă, capturați marcajul temporal exact, serviciul, numele modulului PAM și liniile de jurnal igienizate relevante; aceste detalii sunt mai utile decât mesajul generic „eșec de autentificare”.

Referințe oficiale

• Ghid de administrare SUSE SLES 15 SP7: Probleme frecvente și soluțiile acestora — depanarea conectării locale și la rețea.
• Ghid de securitate și consolidare pentru SUSE SLES 15 SP7: Autentificare cu PAM — Etape PAM, stiva SSH și pam-config.
• SUSE SLES 15 SP7: Configurarea clienților de autentificare folosind YaST — Starea SSSD și comportamentul memoriei cache.
• SUSE SLES 15 SP7: Securizarea operațiunilor de rețea cu OpenSSH — vizualizarea mesajelor de jurnal sshd.