Wie man PAM-Authentifizierungsfehler auf einem SUSE Linux Enterprise Server behebt

Die Fehlermeldung „PAM-Authentifizierungsfehler“ bedeutet nicht zwangsläufig, dass das Passwort falsch ist. Unter SUSE Linux Enterprise Server (SLES) bilden die Pluggable Authentication Modules (PAM) einen Sicherheitsstapel, der Identität, Kontozugriff, Passwortänderungen und Sitzungseinrichtung überprüft. Ein Fehler kann durch einen Tippfehler, ein deaktiviertes Konto, eine fehlerhafte PAM-Einbindung, einen nicht verfügbaren LDAP- oder Active Directory-Dienst, ein Problem mit der Kerberos-Uhr oder dem DNS oder ein nach der Authentifizierung auftretendes Problem mit der Desktop-Sitzung verursacht werden.

Die sicherste Lösung besteht darin, den fehlerhaften Dienst und die fehlerhafte PAM-Phase zu identifizieren, bevor die Konfiguration geändert wird. Diese Anleitung basiert auf der Dokumentation von SUSE Linux Enterprise Server 15 SP7. Wenn Sie ein anderes SLES-Service-Pack oder ein spezielles Appliance-Image verwenden, überprüfen Sie die entsprechende SUSE-Dokumentation und die installierten Paketversionen, bevor Sie die Befehle anwenden.

Zunächst einmal: Was genau funktioniert nicht – ein einzelner Dienst oder jeder Login?

Notieren Sie Benutzer, genaue Uhrzeit, Host und Einstiegspunkt des Fehlers: SSH, lokale Textkonsole, grafische Anmeldung suoder eine Anwendung. Testen Sie nach Möglichkeit mit einem zweiten bekannten Benutzerkonto. Wenn nur SSH fehlschlägt, die Konsolenanmeldung aber funktioniert, konzentrieren Sie sich auf /etc/pam.d/sshdden SSH-Dienst. Funktionieren lokale Benutzer, aber Verzeichnisbenutzer nicht, untersuchen Sie SSSD, LDAP, Active Directory, Kerberos, DNS oder die Autorisierungsrichtlinie des Hosts. Wenn die Konsolenanmeldung erfolgreich ist, der Desktop den Benutzer aber ablehnt oder zum Anmeldebildschirm zurückleitet, liegt der Fehler möglicherweise in der grafischen Sitzung oder im Home-Verzeichnis und nicht in der Passwortauthentifizierung.

Lassen Sie während der Fehlersuche eine bestehende Root-Shell geöffnet. Wenn Sie remote verbunden sind, halten Sie eine zweite SSH-Sitzung geöffnet und stellen Sie sicher, dass Sie Konsolen- oder Rettungszugriff haben, bevor Sie Änderungen an der PAM-Datei vornehmen. Ein Syntax- oder Kontrollflag-Fehler in einer gemeinsam genutzten PAM-Datei kann neue Anmeldungen für mehrere Dienste blockieren.

1. Lesen Sie das Tagebuch über den gescheiterten Versuch.

Die Fehlerbehebungsanleitung von SUSE empfiehlt, das Systemprotokoll auf Meldungen des Anmeldevorgangs und von PAM zu überprüfen. Suchen Sie in einem kurzen Zeitfenster nahe am Fehler, damit nicht relevante Meldungen die Ursache nicht verdecken.

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

Bei einem reinen SSH-Problem sollte die Betrachtung auf den SSH-Daemon beschränkt werden:

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

Suchen Sie nach dem Dienstnamen, dem PAM-Dienstnamen, dem Modulnamen und danach, ob die Meldung sich auf auth, account, passwordoder bezieht session. Der PAM- authStack prüft die Anmeldeinformationen, accountob der Benutzer Zugriff auf den Dienst hat und sessionbereitet die Benutzerumgebung vor. Eine erfolgreiche Passwortprüfung mit anschließender Kontoverweigerung deutet auf ein anderes Problem hin als ein unbekannter Benutzer oder ein falsches Passwort. Vermeiden Sie es, die ausführliche Fehlersuche auf einem Produktivsystem zu aktivieren, es sei denn, sie ist unbedingt erforderlich; Diagnoseprotokolle können Kontonamen und andere sensible Informationen enthalten.

Den Workflow für die lokale und Netzwerkauthentifizierung finden Sie im SLES-Fehlerbehebungsleitfaden von SUSE .

2. Bestätigen Sie, dass SLES den Benutzer finden kann.

Bevor Sie PAM ändern, prüfen Sie, ob der Namensdienst-Switch des Systems das Konto auflösen kann:

getent passwd user_name
id user_name

Ersetzen Sie dies user_namedurch den betroffenen Login. Falls diese Befehle kein Konto für einen Verzeichnisbenutzer zurückgeben, funktioniert PAM möglicherweise korrekt, während die Identitätssuche fehlschlägt. Prüfen Sie, ob der konfigurierte Identitätsdienst ausgeführt wird, der Host das Verzeichnis erreichen kann und der Benutzer sich auf diesem Host anmelden darf. Bei einer SSSD-basierten Konfiguration überprüfen Sie den Daemon und die aktuellen Protokolle.

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

SUSE dokumentiert SSSD als Anbieter von NSS- und PAM-Schnittstellen und weist darauf hin, dass es Identitätsdaten zwischenspeichern kann. Sollten Benutzer sporadische Fehler melden, vergleichen Sie die Systemzeit und die DNS-Auflösung mit dem Verzeichnis oder der Kerberos-Umgebung. Kerberos ist auf eine korrekte Zeitsynchronisation angewiesen; eine funktionierende Netzwerkverbindung allein garantiert keine erfolgreiche Authentifizierung.

Prüfen Sie auch auf Namenskonflikte. SUSE nennt einen Benutzernamen, der sowohl lokal als auch in einer Netzwerkidentitätsquelle existiert, als mögliche Ursache für Netzwerkauthentifizierungsprobleme. Vergewissern Sie sich, welcher Identitätsquelle das Konto zugeordnet ist, bevor Sie die PAM-Regeln bearbeiten.

3. Überprüfen Sie die PAM-Dienstdatei und den gemeinsam genutzten Stack.

SLES speichert PAM-Dateien pro Dienst in einem Verzeichnis /etc/pam.d. Eine Dienstdatei wie beispielsweise `.ps` /etc/pam.d/sshdenthält üblicherweise gemeinsam genutzte Dateien wie common-auth`.ps`, common-account` common-password.ps`, `.ps` und ` common-session.ps`. Eine fehlerhafte Zeile in einer gemeinsam genutzten Datei kann mehrere Dienste beeinträchtigen; eine fehlerhafte Zeile in der Datei einer Anwendung kann hingegen nur diese Anwendung betreffen.

Lesen Sie die relevanten Dateien und prüfen Sie deren Verknüpfungen, bevor Sie sie bearbeiten:

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

Prüfen Sie auf falsch geschriebene Modulnamen, fehlende Moduldateien, falsche Optionen, unerwartete Reihenfolge und Änderungen, die bei einer kürzlich erfolgten Paket- oder Authentifizierungsaktualisierung vorgenommen wurden. Kontrollflags sind wichtig: requiredSie können einen Fehler protokollieren, aber den Prozess fortsetzen; requisitesie können sofort stoppen; sufficientsie können eine frühzeitige Rückkehr zum Erfolg ermöglichen, wenn kein zuvor benötigtes Modul fehlgeschlagen ist. Kopieren Sie keinen PAM-Stack von einer anderen Distribution oder SLES-Version, ohne dessen Module und Kontrollfluss zu verstehen.

Bevor Sie irgendetwas ändern, erstellen Sie eine Sicherungskopie des aktuellen Verzeichnisses nur im Stammverzeichnis, wobei symbolische Links erhalten bleiben müssen:

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

Vergewissern Sie sich, dass die Sicherung vorhanden ist, und notieren Sie genau, welche Dateien Sie geändert haben. Falls alle Benutzer ausgesperrt sind, verwenden Sie das unterstützte SLES-Wiederherstellungsverfahren und stellen Sie eine bekannte, funktionierende Konfiguration wieder her, anstatt beim Anmelden zu improvisieren.

4. Überprüfen Sie unter SLES, ob pam-config die gemeinsam genutzten Dateien verwaltet.

SUSE bietet pam-configdie Möglichkeit, die globalen PAM-Dateien und die Konfigurationen unterstützter Anwendungen zu verwalten. Dies ist im Allgemeinen sicherer als die manuelle Bearbeitung generierter gemeinsam genutzter Stacks beim Hinzufügen oder Entfernen einer unterstützten Methode. Prüfen Sie zunächst die verfügbaren Module und die aktuelle SSSD-Integration:

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

Wenn der Server SSSD verwendet und die Integration fehlt, beschreibt SUSE in seinen Dokumenten, sudo pam-config --add --ssswie diese hinzugefügt werden kann. Führen Sie diese Schritte erst durch, nachdem Sie das Design der Verzeichnisauthentifizierung bestätigt, den aktuellen Stack überprüft, ein Backup erstellt und einen Wiederherstellungsplan sichergestellt haben. Wenden Sie diese Vorgehensweise nicht pauschal auf jeden Authentifizierungsfehler an. Überprüfen Sie die Konfiguration erneut und testen Sie die Funktion in einer zweiten Sitzung.

Ein besonders riskanter Befehl ist ` suse --config` pam-config --create. SUSE gibt an, dass dieser Befehl eine einfache Unix-Authentifizierungskonfiguration erzeugt und vorhandene, nicht von `suse --config` verwaltete Konfigurationsdateien überschreibt pam-config(wobei Sicherungskopien mit dem .pam-config-backupSuffix `.suse` erstellt werden). Er ist nicht für die routinemäßige Behebung eines einzelnen fehlgeschlagenen Anmeldevorgangs geeignet. Verwenden Sie ihn nur, wenn Sie die Konfiguration bewusst neu erstellen und eine Wiederherstellung geplant haben.

Wenn Ihre Organisation PAM-Dateien absichtlich manuell pflegt, halten Sie sich konsequent an dieses Vorgehen. SUSE weist darauf hin, dass die manuelle Konfiguration die Deaktivierung pam-configdieser Dateien erfordert. Benutzerdefinierte Stacks sollten benötigte Sitzungsmodule beibehalten, gegebenenfalls auch pam_systemd.soals optionales Sitzungsmodul.

5. Separate SSH-, Verzeichnis- und Desktop-Probleme

Wenn nur SSH das Konto ablehnt

Vergleichen Sie die /etc/pam.d/sshdKonfiguration mit einer funktionierenden SLES-Konfiguration und prüfen Sie das SSH-Daemon-Journal zum Zeitpunkt des fehlgeschlagenen Anmeldevorgangs. Stellen Sie sicher, dass das Konto sowohl durch die SSH-Einstellungen und Zugriffskontrollen als auch durch PAM zugelassen ist. Schwächen Sie die SSH-Authentifizierung nicht und entfernen Sie keine Kontoprüfungen, nur um den Fehler zu beheben.

Wenn nur Verzeichnisbenutzer ausfallen

Bestätigen Sie die Kontoabfrage getent, prüfen Sie den SSSD-Status und die Protokolle und verifizieren Sie die Verzeichniserreichbarkeit, DNS, Zeitsynchronisierung, Hostregistrierung und Benutzerzugriffsrichtlinie. Falls ein anderer Verzeichnisbenutzer erfolgreich ist, vergleichen Sie die Gruppen, die Shell, das Home-Verzeichnis und die hostspezifischen Zugriffsregeln des betroffenen Kontos. Die SUSE- Anleitung zum Authentifizierungsclient beschreibt YaST-verwaltetes SSSD und dessen Statusprüfungen.

Wenn die Anmeldung über die Konsole funktioniert, die grafische Sitzung jedoch fehlschlägt

Überprüfen Sie die Anmelde- und Sitzungsprotokolle der grafischen Benutzeroberfläche, die Verfügbarkeit des Home-Verzeichnisses, die Besitzverhältnisse, den freien Speicherplatz und alle Schritte zum Entsperren des verschlüsselten Home-Verzeichnisses. Eine erfolgreiche Anmeldung über die Textkonsole ist ein nützlicher Hinweis darauf, dass das Passwort und die Basisauthentifizierung funktionieren; sie lenkt die Aufmerksamkeit auf die Desktop-Sitzung oder die Benutzerumgebung. Löschen Sie nicht als ersten Schritt Benutzerdateien. Die Fehlerbehebungsanleitung von SUSE empfiehlt, Probleme mit der Desktop-Konfiguration systematisch zu isolieren.

6. Überprüfen Sie die Reparatur, ohne eine Aussperrung zu riskieren.

Öffnen Sie nach einer Änderung eine neue Testsitzung, während die Wiederherstellungsshell weiterhin verfügbar ist. Testen Sie den betroffenen Dienst mit dem betroffenen Benutzerkonto, anschließend mit einem zweiten Benutzerkonto und einem lokalen Administratorkonto. Überprüfen Sie bei der Verzeichnisauthentifizierung die Kontoauflösung, die Dienstintegrität und eine erfolgreiche Anmeldung. Prüfen Sie das Protokoll erneut auf neue PAM-Fehler und entfernen Sie pam-config --deletenach Abschluss der Tests alle temporären Debug-Einstellungen mit der entsprechenden Option.

Prüfen Sie abschließend, ob das Ergebnis die fehlerhafte Phase behebt und nicht nur verschleiert. Ein korrekter Login sollte den vorgesehenen Benutzer authentifizieren, die vorgesehene Kontorichtlinie durchsetzen und eine normale Sitzung herstellen. Bewahren Sie die Sicherungskopie auf, bis Sie diese Ergebnisse überprüft und die endgültige Konfiguration dokumentiert haben.

Wann sollten Sie anhalten und den Rettungsmodus verwenden?

Nehmen Sie keine Änderungen mehr per Fernzugriff vor, wenn der Root-Zugriff verloren geht, mehrere Dienste gleichzeitig ausfallen, der gemeinsam genutzte Stack überschrieben wurde oder Sie nicht feststellen können, welcher Konfigurationsmanager die Dateien besitzt. Die SLES-Dokumentation beschreibt die Verwendung des Root-Zugriffs zur Reparatur der Konfiguration und den Wechsel in den Rettungsmodus, wenn die normale Anmeldung nicht möglich ist. Bei verwalteten Produktionssystemen sollten Sie das Identitäts- oder Plattformteam einbeziehen, bevor Sie einen gemeinsam genutzten Authentifizierungs-Stack neu erstellen.

Die genaue PAM-Dateistruktur, Modulflags, pam-configdas Verhalten und die Wiederherstellungsschritte finden Sie im versionsspezifischen SUSE SLES 15 SP7 PAM-Leitfaden und im SUSE-Leitfaden für häufige Probleme . PAM-Stacks stellen Sicherheitsrichtlinien dar; nehmen Sie daher nur die kleinstmögliche, gerechtfertigte Änderung vor und überprüfen Sie anschließend Zugriff und Einschränkungen.