Cum se remediază erorile de autentificare PAM pe serverul SUSE Linux Enterprise

Un mesaj „Eroare de autentificare PAM” nu înseamnă întotdeauna că parola este greșită. Pe SUSE Linux Enterprise Server (SLES), modulele de autentificare conectabile (PAM) formează o stivă care verifică identitatea, accesul la cont, modificările parolei și configurarea sesiunii. O eroare poate proveni dintr-o greșeală de scriere sau un cont dezactivat, o includere PAM nefuncțională, un serviciu LDAP sau Active Directory indisponibil, o problemă de ceas sau DNS Kerberos sau o problemă de sesiune desktop care apare după autentificare.

Cea mai sigură soluție este să identificați ce serviciu și ce etapă PAM a eșuat înainte de a modifica configurația. Acest ghid folosește documentația SUSE Linux Enterprise Server 15 SP7 ca referință. Dacă rulați un alt pachet service pack SLES sau o imagine specializată a dispozitivului, verificați documentația SUSE corespunzătoare și versiunile pachetului instalat înainte de a aplica comenzi.

În primul rând, ce eșuează: un serviciu sau fiecare conectare?

Înregistrați utilizatorul, ora exactă, gazda și punctul de intrare pentru eroare: SSH, o consolă text locală, autentificare grafică susau o aplicație. Testați cu un al doilea cont cunoscut, dacă este posibil. Dacă doar SSH eșuează în timp ce autentificarea în consolă funcționează, concentrați-vă pe /etc/pam.d/sshdși pe serviciul SSH. Dacă utilizatorii locali funcționează, dar utilizatorii din director eșuează, investigați SSSD, LDAP, Active Directory, Kerberos, DNS sau politica de autorizare a gazdei. Dacă o autentificare în consolă reușește, dar desktopul respinge utilizatorul sau revine la ecranul de autentificare, eroarea poate fi în sesiunea grafică sau în directorul principal, mai degrabă decât în ​​autentificarea prin parolă.

Păstrați deschisă o sesiune root existentă în timp ce depanați. Dacă sunteți conectat de la distanță, păstrați deschisă o a doua sesiune SSH și asigurați-vă că aveți acces la consolă sau de salvare înainte de a atinge PAM. O eroare de sintaxă sau de control-flag într-un fișier PAM partajat poate bloca noi conectări pentru mai multe servicii.

1. Citește jurnalul despre încercarea eșuată

Ghidul de depanare SUSE recomandă verificarea jurnalului de sistem pentru mesaje din procesul de conectare și PAM. Interogați o fereastră de timp scurtă, aproape de momentul erorii, astfel încât mesajele fără legătură să nu ascundă cauza:

sudo journalctl -b --since "15 minutes ago"

Pentru o problemă exclusivă SSH, restrângeți vizualizarea la daemonul SSH:

sudo journalctl -b -u sshd --since "15 minutes ago"

Căutați numele serviciului, numele serviciului PAM, numele modulului și dacă mesajul se referă la auth, account, password, sau session. Stiva PAM authverifică acreditările; accountverifică dacă utilizatorul are permisiunea de a accesa serviciul respectiv; sessionpregătește mediul utilizatorului. O verificare reușită a parolei, urmată de un refuz al contului, indică o problemă diferită de un utilizator necunoscut sau o parolă greșită. Evitați activarea depanării detaliate pe un sistem de producție, decât dacă este necesar; jurnalele de diagnosticare pot conține nume de conturi și alte contexte sensibile.

Consultați ghidul de depanare SLES de la SUSE pentru fluxul de lucru pentru autentificarea locală și în rețea.

2. Confirmați că SLES poate găsi utilizatorul

Înainte de a schimba PAM, verificați dacă comutatorul de servicii de nume al sistemului poate rezolva contul:

getent passwd user_name
id user_name

Înlocuiți user_namecu datele de conectare afectate. Dacă aceste comenzi nu returnează niciun cont pentru un utilizator din director, este posibil ca PAM să funcționeze corect în timp ce căutarea identității eșuează. Verificați dacă serviciul de identitate configurat rulează, gazda poate accesa directorul și utilizatorul are permisiunea de a se conecta pe această gazdă. Pentru o configurare bazată pe SSSD, inspectați daemonul și jurnalele recente:

sudo systemctl status sssd
sudo journalctl -b -u sssd --since "15 minutes ago"

SUSE documentează că SSSD oferă atât interfețe NSS, cât și PAM și menționează că poate stoca în cache datele de identitate. Dacă utilizatorii raportează erori intermitente, comparați ora și rezoluția DNS a sistemului local cu directorul sau mediul Kerberos. Kerberos depinde de sincronizarea corectă a orei; o conexiune de rețea funcțională nu dovedește singură că autentificarea va reuși.

Verificați și dacă există coliziuni de nume. SUSE listează un nume de utilizator care există local și într-o sursă de identitate de rețea ca o posibilă cauză a problemelor de autentificare în rețea. Verificați ce sursă de identitate este așteptată să dețină contul înainte de a edita regulile PAM.

3. Inspectați fișierul serviciului PAM și stiva partajată

SLES păstrează fișierele PAM per serviciu în /etc/pam.d. Un fișier de serviciu, cum ar fi , /etc/pam.d/sshdinclude de obicei fișiere partajate precum common-auth, common-account, common-passwordși common-session. O linie greșită într-un fișier partajat poate afecta mai multe servicii; o linie greșită într-un fișier al unei aplicații poate afecta doar aplicația respectivă.

Citiți fișierele relevante și verificați linkurile acestora înainte de a le edita:

sudo ls -l /etc/pam.d/common-*
sudo sed -n '1,160p' /etc/pam.d/sshd
sudo sed -n '1,160p' /etc/pam.d/common-auth
sudo sed -n '1,160p' /etc/pam.d/common-account

Verificați dacă există nume de module scrise greșit, fișiere de module lipsă, opțiuni incorecte, ordine neașteptate și modificări făcute în timpul unei implementări recente de pachete sau autentificare. Indicatorii de control sunt importanți: requiredînregistrează o eroare, dar continuă prin stivă; requisitese pot opri imediat; sufficientpot permite revenirea anticipată a succesului atunci când niciun modul necesar anterior nu a eșuat. Nu copiați o stivă PAM dintr-o altă distribuție sau versiune SLES fără a înțelege modulele și fluxul de control al acesteia.

Înainte de a schimba ceva, faceți o copie de rezervă a directorului curent, doar cu utilizatorul root, păstrând legăturile simbolice:

backup_dir=/root/pam.d.backup.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/pam.d "$backup_dir"

Confirmați existența copiei de rezervă și înregistrați exact fișierele pe care le modificați. Dacă toți utilizatorii sunt blocați, utilizați procedura de salvare SLES acceptată și restaurați dintr-o configurație cunoscută ca fiind bună, în loc să improvizați la promptul de conectare.

4. Pe SLES, verificați dacă pam-config gestionează fișierele partajate

SUSE asigură pam-configmenținerea fișierelor PAM globale și a configurațiilor aplicațiilor acceptate. În general, este mai sigur decât editarea manuală a stivelor partajate generate atunci când se adaugă sau se elimină o metodă acceptată. Mai întâi, verificați modulele disponibile și integrarea SSSD curentă:

sudo pam-config --list-modules
sudo pam-config --query --sss

Dacă serverul folosește intenționat SSSD și integrarea lipsește, SUSE documentează sudo pam-config --add --sssmodalitatea de adăugare a acesteia. Faceți acest lucru numai după confirmarea designului de autentificare a directorului, revizuirea stivei curente, păstrarea copiei de rezervă și asigurarea că aveți o rută de recuperare. Nu rulați acest serviciu ca remediu generic pentru fiecare „eroare de autentificare”. Interogați din nou configurația și testați într-o a doua sesiune.

O comandă deosebit de riscantă este pam-config --create. SUSE spune că aceasta generează o configurație simplă de autentificare Unix și suprascrie fișierele de configurare existente care nu sunt întreținute de pam-config(păstrând în același timp copii de rezervă cu un .pam-config-backupsufix). Nu este o reparație de rutină pentru o singură autentificare eșuată. Folosiți-o numai atunci când intenționați în mod deliberat să reconstruiți configurația și ați planificat recuperarea.

Dacă organizația dumneavoastră întreține în mod intenționat fișierele PAM manual, urmați acest design în mod consecvent. SUSE notează că configurarea manuală necesită dezactivarea pam-configacestor fișiere. Stivele personalizate ar trebui să păstreze modulele de sesiune necesare, inclusiv pam_systemd.soca modul de sesiune opțional, acolo unde este cazul.

5. Probleme separate legate de SSH, director și desktop

Dacă doar SSH respinge contul

Comparați /etc/pam.d/sshdcu o configurație SLES cunoscută ca fiind bună și inspectați jurnalul daemonului SSH la momentul autentificării eșuate. Confirmați că accesul la cont este permis de setările și controalele de acces proprii ale SSH, precum și de PAM. Nu slăbiți autentificarea SSH și nu eliminați verificările contului doar pentru a face eroarea să dispară.

Dacă doar utilizatorii directorului eșuează

Confirmați căutarea în cont cu getent, verificați starea și jurnalele SSSD și verificați accesibilitatea directorului, DNS, sincronizarea orei, înscrierea gazdei și politica de acces a utilizatorilor. Dacă un alt utilizator al directorului reușește, comparați grupurile, shell-ul, directorul principal și regulile de acces specifice gazdei pentru contul afectat. Ghidul clientului de autentificare SUSE descrie SSSD-ul gestionat de YaST și verificările sale de stare.

Dacă autentificarea în consolă funcționează, dar sesiunea grafică eșuează

Verificați jurnalele grafice de conectare și de sesiune, disponibilitatea directorului principal, proprietatea, spațiul liber pe disc și orice pas de deblocare a directorului principal criptat. O conectare reușită prin consolă text este o dovadă utilă că parola și calea de autentificare de bază funcționează; aceasta mută atenția către sesiunea desktop sau mediul utilizatorului. Evitați ștergerea fișierelor utilizatorului ca prim pas. Ghidul de depanare SUSE recomandă izolarea metodică a problemelor de configurare desktop.

6. Verificați reparația fără a risca blocarea instalației

După o modificare, deschideți o nouă sesiune de testare cât timp shell-ul de recuperare rămâne disponibil. Testați serviciul afectat cu contul afectat, apoi testați un al doilea cont și un administrator local. Pentru autentificarea în director, confirmați căutarea în cont și starea serviciului, precum și o conectare reușită. Verificați din nou jurnalul pentru erori PAM noi și eliminați orice setări de depanare temporare cu pam-config --deleteopțiunea corespunzătoare după finalizarea testării.

În cele din urmă, confirmați că rezultatul rezolvă problema etapei de eroare, în loc să o ascundă. O conectare fixă ​​ar trebui să autentifice utilizatorul vizat, să aplice politica contului vizat și să creeze o sesiune normală. Păstrați copia de rezervă până când ați verificat aceste rezultate și ați documentat configurația finală.

Când ar trebui să te oprești și să folosești modul de salvare?

Nu mai faceți modificări la distanță dacă accesul root se pierde, mai multe servicii eșuează simultan, stiva partajată a fost suprascrisă sau nu puteți determina care manager de configurare deține fișierele. Documentația SLES descrie utilizarea accesului root pentru repararea configurației și intrarea în modul de salvare atunci când autentificarea normală nu este disponibilă. Pentru sistemele de producție gestionate, implicați echipa de identitate sau de platformă înainte de a reconstrui o stivă de autentificare partajată.

Pentru structura exactă a fișierului PAM, semnalizările modulelor, comportamentul și pașii de recuperare, utilizați ghidul SUSE SLES 15 SP7 PAM și ghidul SUSE pentru probleme comune,pam-config corespunzătoare versiunii . Stivele PAM reprezintă o politică de securitate; faceți cea mai mică modificare justificată, apoi verificați atât accesul, cât și restricțiile.