SLES PAM-Anmeldefehler diagnostizieren, ohne sich selbst auszusperren

Die Fehlermeldung „PAM-Authentifizierungsfehler“ bietet keine allgemeingültige Lösung. Identifizieren Sie zunächst den betroffenen Dienst und die betroffenen Benutzer und überprüfen Sie anschließend das Journal zum entsprechenden Zeitpunkt. Beheben Sie unter SUSE Linux Enterprise Server (SLES) ein bestätigtes globales PAM-Problem über die entsprechende Funktion pam-configund ändern Sie eine einzelne Dienstdatei nur dann, wenn der zugehörige Stack fehlerhaft ist. Halten Sie während der Tests eine funktionierende Root- oder Administrator-Sitzung geöffnet; ein fehlerhafter PAM-Stack kann neue SSH- und Konsolenanmeldungen blockieren.

Der aktuelle Leitfaden zu Sicherheit und Härtung von SLES 15 SP7 beschreibt PAM als einen Stapel von Authentifizierungs-, Konto-, Passwort- und Sitzungsmodulen. Diese Unterscheidung ist wichtig: Ein korrektes Passwort kann zwar eine authStufe erfolgreich durchlaufen, aber später dennoch durch eine Kontorichtlinie oder eine dienstspezifische Regel abgelehnt werden. Eine allgemeine Fehlermeldung allein kann nicht aufzeigen, welche Stufe fehlgeschlagen ist.

Was beweist der Fehler – und was beweist er nicht?

PAM vermittelt zwischen einer Anwendung, wie z. B. sshdder Konsolenanmeldung, und den konfigurierten Authentifizierungsmethoden. Jeder PAM-fähige Dienst verfügt über eine Datei unter /etc/pam.d/. Diese Dienstdatei kann SLES-übliche Dateien wie common-authund enthalten common-account, sodass ein Fehler, der nur SSH betrifft, eine andere Ursache haben kann als Fehler bei allen Anmeldemethoden.

Bestätigt: Der dokumentierte SSH-Stack von SUSE enthält pam_nologin.sodie entsprechenden PAM-Dateien. Falls /etc/nologinvorhanden, verweigert das dokumentierte Modul Anmeldungen für alle Benutzer außer root. Kontextabhängig: Lokal bearbeitete Regeln, Verzeichnisdienste und MFA-Module von Drittanbietern können zusätzliche Prüfungen durchführen. Aus der Meldung allein lässt sich nicht ableiten, ob das Passwort falsch, die PAM-Dateien beschädigt oder das Konto gesperrt ist. Beginnen Sie mit dem betroffenen Dienst und dessen Protokoll, anstatt den gesamten Stack zu ersetzen.

Welcher Anmeldepfad schlägt fehl?

Reproduzieren Sie den Fehler einmal und notieren Sie Uhrzeit, Benutzername und Methode: SSH, lokale Textkonsole, grafische Anmeldung sudooder su. Falls Sie sich als Administrator anmelden können, überprüfen Sie die letzten Systemmeldungen.

sudo journalctl -e

Der SUSE-Leitfaden zur Fehlerbehebung für SLES empfiehlt ausdrücklich, das Protokoll auf Anmelde- und PAM-Fehler zu überprüfen. Suchen Sie etwa zum Zeitpunkt des Anmeldeversuchs nach dem Modulnamen oder der Fehlerursache – beispielsweise nach einem verweigerten Konto, einem nicht verfügbaren Verzeichnisdienst, einem fehlenden Modul oder einem Datei-/Berechtigungsfehler. Geben Sie Protokolle nicht öffentlich weiter, ohne Benutzernamen, Hostnamen, Adressen und andere sensible Daten zu entfernen.

Falls nur SSH fehlschlägt, überprüfen Sie das Journal des SSH-Daemons:

sudo journalctl -u sshd

Vergleichen Sie anschließend die Zugriffspfade. Kann sich ein Benutzer an der lokalen Konsole, aber nicht per SSH authentifizieren, prüfen Sie /etc/pam.d/sshddie SSH-Zugriffsrichtlinie oder ein SSH-spezifisches Modul. Weisen mehrere Dienste dieselben lokalen Benutzer zurück, untersuchen Sie deren freigegebene common-*Dateien. Schlägt die Authentifizierung nur bei einem Benutzer fehl, überprüfen Sie Kontostatus und Passwort, bevor Sie die systemweite Authentifizierung ändern.

Handelt es sich um ein lokales Konto oder eine Netzwerkidentität?

Prüfen Sie bei lokalen Benutzern zuerst Benutzernamen, Tastaturlayout und Feststelltaste. Falls ein Zurücksetzen der Anmeldeinformationen erforderlich ist, verwenden Sie ein vom Administrator freigegebenes Passwort-Tool wie YaST User and Group Management, anstatt die Passwörter /etc/shadowmanuell zu bearbeiten. Wenn allen Benutzern außer Root der SSH-Zugriff verweigert wird, prüfen Sie vor Änderungen an den PAM-Einstellungen, ob eine geplante Wartungsdatei /etc/nologinvorhanden ist. Entfernen Sie diese nur, wenn die Wartungssperre nachweislich abgelaufen ist und Sie dazu berechtigt sind.

Bei LDAP-, Active Directory- oder anderen verzeichnisbasierten Benutzern beweist ein funktionierendes Passwort auf einem anderen Server nicht, dass dieser SLES-Host den Identitätsanbieter erreichen kann. SUSE nennt Netzwerk- und DNS-Probleme, Kerberos-Taktabweichungen, falsch konfigurierte PAM-Regeln, Host-Zugriffsrichtlinien und nicht verfügbare Home-Verzeichnisse als mögliche Ursachen. Testen Sie, ob sich ein anderer Domänenbenutzer anmelden kann und ob sich der betroffene Benutzer an einem anderen Host anmelden kann. Überprüfen Sie anschließend die konfigurierte Identitätsdienst- und Serverkonnektivität.

Wenn der Host SSSD verwendet, überprüfen Sie dessen Dienst und ob PAM für dessen Verwendung konfiguriert ist:

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

SSSD kann Benutzerinformationen zwischenspeichern und die Authentifizierung ermöglichen, während das Verzeichnis vorübergehend nicht erreichbar ist. Dieses Verhalten hängt jedoch von der Konfiguration und den zwischengespeicherten Anmeldeinformationen ab. Ein veralteter oder fehlender Cache ist daher eine mögliche Ursache, aber keine zwingende Schlussfolgerung. Überprüfen Sie DNS, Zeitsynchronisierung für Kerberos, Verzeichniserreichbarkeit und SSSD-Protokolle, bevor Sie den Cache leeren oder Module ändern. Meldet der Identitätsanbieter „Konto gesperrt“ oder „Konto deaktiviert“, sollte der Verzeichnisadministrator die Richtlinie des betreffenden Kontos überprüfen. PAM meldet die Entscheidung lediglich, erstellt sie aber nicht zwangsläufig selbst.

Wie behebt man ein bestätigtes PAM-Konfigurationsproblem?

Überprüfen Sie die dienstspezifische Datei und die darin enthaltenen gemeinsamen Regeln:

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

Unter SLES pam-configwerden globale Dateien unter `/usr/local/bin` verwaltet /etc/pam.d/common-*; individuelle Dienstdateien /etc/pam.d/sshdwerden separat verwaltet. Bearbeiten Sie generierte gemeinsame Dateien nicht manuell, es sei denn, Sie haben pam-configdie Verwendung dieser Dateien explizit deaktiviert. Wenn Sie bestätigen, dass dieser Host SSSD verwenden soll und die zugehörigen SSSD-PAM-Regeln fehlen, finden Sie in der SUSE-Dokumentation Anweisungen sudo pam-config --add --ssszum Hinzufügen dieser Regeln. Verwenden Sie SSSD erst, nachdem Sie sichergestellt haben, dass SSSD konfiguriert ist und ausgeführt wird. Testen Sie anschließend eine neue Anmeldung, während die laufende administrative Sitzung geöffnet bleibt.

Ein weit verbreiteter, aber riskanter Irrtum ist, dass pam-config --createes sich um einen harmlosen Reparaturbefehl handelt. SUSE gibt an, dass er eine grundlegende Unix-Authentifizierungskonfiguration erstellt und vorhandene, nicht von ihm verwaltete Dateien überschreibt, wobei Sicherungskopien erhalten bleiben. Dies kann benutzerdefinierte MFA- oder Verzeichnisauthentifizierungseinstellungen beeinträchtigen. Führen Sie ihn nicht als allgemeinen Wiederherstellungsschritt aus. Bei einem Tippfehler in einer Dienstdatei stellen Sie die korrekte, versionsgerechte Konfiguration des betreffenden Dienstes aus einer vertrauenswürdigen Sicherung wieder her oder korrigieren Sie die fehlerhafte Zeile gemäß dem Änderungsprozess Ihrer Organisation.

Wie lässt sich die Reparatur bestätigen?

Lassen Sie die ursprüngliche Root- oder Administrator-Sitzung geöffnet. Starten Sie eine zweite Sitzung über denselben Dienst, der den Fehler verursacht hat – beispielsweise über eine neue SSH-Verbindung – und testen Sie das betroffene Konto. Vergewissern Sie sich, dass im Protokoll keine PAM-Verweigerung mehr protokolliert wird und eine andere konfigurierte Authentifizierungsmethode weiterhin funktioniert. Falls der Fehler weiterhin besteht, erfassen Sie den genauen Zeitstempel, den Dienstnamen, den Namen des PAM-Moduls und die relevanten anonymisierten Protokollzeilen. Diese Details sind aussagekräftiger als die allgemeine Fehlermeldung „Authentifizierung fehlgeschlagen“.

Offizielle Referenzen

• SUSE SLES 15 SP7 Administrationshandbuch: Häufige Probleme und deren Lösungen – Fehlerbehebung bei lokalen und Netzwerk-Anmeldungen.
• SUSE SLES 15 SP7 Sicherheits- und Härtungsleitfaden: Authentifizierung mit PAM — PAM-Phasen, SSH-Stack und pam-config.
• SUSE SLES 15 SP7: Einrichten von Authentifizierungsclients mit YaST — SSSD-Status und Cache-Verhalten.
• SUSE SLES 15 SP7: Netzwerkoperationen mit OpenSSH absichern – Anzeigen von sshd-Journalmeldungen.