PAM-Authentifizierungsmodule: Grundlagen der Login-Kontrolle

1. Was PAM ist und warum es existiert

PAM, Pluggable Authentication Modules, ist eine Abstraktionsschicht, die Anwendungen wie sshd, sudo oder login von der konkreten Implementierung der Authentifizierung entkoppelt. Statt dass jede Anwendung eigene Logik für Passwortprüfung, Kontosperren oder Zwei-Faktor-Verfahren mitbringt, ruft sie lediglich die PAM-Bibliothek auf, und PAM entscheidet anhand einer Konfigurationsdatei, welche Module in welcher Reihenfolge geprüft werden. Diese Entkopplung wurde erstmals bei Solaris eingeführt und ist heute auf praktisch jeder Linux-Distribution als Linux-PAM Standard.

Der praktische Nutzen zeigt sich sofort, wenn man eine neue Sicherheitsmaßnahme einführen will: Ein Administrator, der Kontosperren nach mehreren Fehlversuchen für SSH einführen möchte, muss keine einzige Zeile in sshd selbst ändern, sondern passt lediglich die zugehörige PAM-Konfigurationsdatei an. Dieselbe Änderung wirkt sich, je nach Konfiguration, gleichzeitig auf login, su oder sudo aus, weil alle diese Programme denselben PAM-Mechanismus nutzen.

Historisch wurde PAM 1995 von Sun Microsystems für Solaris entworfen, mit dem ausdrücklichen Ziel, Authentifizierungslogik aus einzelnen Anwendungen herauszulösen und in wiederverwendbare, austauschbare Module zu verschieben. Linux übernahm dieses Konzept wenig später als eigenständige Implementierung namens Linux-PAM, die heute von praktisch jeder größeren Distribution mitgeliefert wird und mittlerweile weit über die ursprüngliche Solaris-Spezifikation hinausgewachsen ist, etwa um Module für Zwei-Faktor-Authentifizierung oder biometrische Verfahren.

Auf Debian- und Ubuntu-basierten Systemen wird PAM über das Paket libpam-runtime gepflegt, auf RHEL-basierten Systemen über pam selbst, in beiden Fällen mit dem Werkzeug pam-auth-update beziehungsweise authselect, das gemeinsame Profile für mehrere Dienste konsistent aktualisiert. Wer PAM ausschließlich manuell in einzelnen pam.d-Dateien pflegt, ohne diese Werkzeuge zu nutzen, riskiert, dass ein späteres Paket-Update die manuellen Änderungen überschreibt, weil Paketmanager die von ihnen verwalteten Konfigurationsdateien beim Upgrade aktualisieren.

2. Die PAM-Stack-Struktur: auth, account, password, session

Jede PAM-Konfiguration gliedert sich in vier funktional getrennte Management-Gruppen. Die Gruppe auth prüft, ob die vorgelegten Anmeldedaten tatsächlich korrekt sind, etwa durch Passwortvergleich oder Abfrage eines zweiten Faktors. Die Gruppe account prüft unabhängig davon, ob das Konto überhaupt aktuell zum Login berechtigt ist, etwa ob es nicht abgelaufen, gesperrt oder zeitlich beschränkt ist. Die Gruppe password kommt nur bei einer Passwortänderung zum Einsatz und prüft neue Passwörter gegen Richtlinien. Die Gruppe session schließlich läuft beim Einrichten und Beenden einer Sitzung, etwa um Umgebungsvariablen zu setzen oder Anmeldungen zu protokollieren.

Diese vier Gruppen sind bewusst unabhängig voneinander. Ein Modul in auth kann ein Passwort erfolgreich validieren, während ein Modul in account den Login trotzdem verweigert, weil das Konto zum Beispiel außerhalb der erlaubten Zeitfenster liegt. Diese Trennung erlaubt feingranulare Kontrolle: Man kann Passwortprüfung, Kontostatusprüfung und Sitzungsverwaltung völlig unabhängig voneinander konfigurieren und austauschen, ohne die jeweils anderen Bereiche zu beeinflussen.

# Inspect which PAM service file handles a given application
cat /etc/pam.d/sshd | grep -v '^#'

# Each line has the shape: <group> <control-flag> <module> [arguments]
# auth    required   pam_env.so
# auth    [success=1 default=ignore] pam_unix.so nullok_secure
# account required   pam_unix.so
# password sufficient pam_unix.so obscure sha512
# session required   pam_limits.so

3. Control-Flags: required, requisite, sufficient, optional

Jede Zeile einer PAM-Konfiguration trägt neben Gruppe und Modul ein Control-Flag, das festlegt, wie das Ergebnis dieses Moduls den Gesamtausgang des Stacks beeinflusst. required bedeutet, dass das Modul erfolgreich sein muss, ein Fehlschlag aber erst nach Auswertung aller weiteren Module derselben Gruppe zum Gesamtfehlschlag führt, was verhindert, dass ein Angreifer aus dem Zeitpunkt des Abbruchs Rückschlüsse ziehen kann. requisite verhält sich ähnlich streng, bricht bei einem Fehlschlag aber sofort ab, ohne weitere Module derselben Gruppe zu prüfen.

sufficient bedeutet, dass ein Erfolg dieses Moduls ausreicht, um die gesamte Gruppe als erfolgreich zu werten, sofern kein vorheriges required-Modul bereits fehlgeschlagen ist, wird aber bei einem Fehlschlag einfach übersprungen und die Prüfung mit dem nächsten Modul fortgesetzt. optional schließlich beeinflusst das Gesamtergebnis nur dann, wenn es das einzige Modul der Gruppe ist, in der Praxis wird es meist für Module verwendet, die lediglich Zusatzinformationen liefern, etwa Umgebungsvariablen setzen, ohne über Erfolg oder Misserfolg des Logins zu entscheiden.

# /etc/pam.d/sshd — excerpt illustrating control-flag semantics
# 1. Try key-based/2FA module first, sufficient to succeed alone
auth    sufficient   pam_google_authenticator.so nullok
# 2. Fall back to standard Unix password check, must also succeed
auth    required     pam_unix.so try_first_pass
# 3. requisite: abort immediately if the account is locked out
account requisite    pam_faillock.so
# 4. required: account must not be expired, checked regardless
account required     pam_unix.so

4. Wichtige Module im Überblick

Das Modul pam_unix.so ist das grundlegendste PAM-Modul und prüft Anmeldedaten gegen /etc/passwd und /etc/shadow, deckt also die klassische Unix-Passwortauthentifizierung ab und kommt in praktisch jeder auth- und account-Konfiguration vor. Das Modul pam_faillock.so zählt fehlgeschlagene Login-Versuche pro Benutzer und sperrt das Konto nach einer konfigurierbaren Anzahl von Fehlversuchen für eine bestimmte Zeit, eine direkte Alternative zu externen Werkzeugen wie fail2ban, allerdings auf Kontoebene statt auf Netzwerkebene.

Das Modul pam_limits.so setzt Ressourcenlimits für eine Sitzung basierend auf /etc/security/limits.conf, etwa die maximale Anzahl offener Dateien oder Prozesse pro Benutzer. Das Modul pam_env.so setzt Umgebungsvariablen aus /etc/security/pam_env.conf beim Sitzungsstart. Für Zwei-Faktor-Authentifizierung kommt pam_google_authenticator.so zum Einsatz, das zeitbasierte Einmalpasswörter nach dem TOTP-Standard prüft. Jedes dieser Module lässt sich unabhängig kombinieren, was PAM zu einem äußerst flexiblen Baukasten macht.

Für PHP-FPM- und Datenbank-Workloads auf Produktivservern ist besonders pam_limits.so praxisrelevant, weil ohne saubere Limits ein einzelner Benutzerprozess bei einem plötzlichen Traffic-Spitzenwert alle verfügbaren Dateideskriptoren des Systems verbrauchen und damit auch andere Dienste auf demselben Server beeinträchtigen kann. Eine explizite Grenze über limits.conf verhindert genau dieses Szenario, ohne dass der Anwendungscode selbst etwas davon wissen muss.

# /etc/security/limits.conf — resource limits enforced by pam_limits.so
# <domain>  <type>  <item>       <value>
www-data    soft    nofile        65536
www-data    hard    nofile        65536
www-data    soft    nproc         4096
deploy      hard    nproc         2048

5. /etc/pam.d/ Dateien lesen und verstehen

Jede Anwendung, die PAM nutzt, besitzt eine eigene Datei unter /etc/pam.d/, benannt nach dem sogenannten Service-Namen der Anwendung, etwa /etc/pam.d/sshd oder /etc/pam.d/sudo. Viele dieser Dateien binden über die Direktive @include common-auth gemeinsame Konfigurationsdateien wie /etc/pam.d/common-auth ein, um Redundanz zu vermeiden, wenn dieselbe Grundkonfiguration für mehrere Dienste gelten soll. Das bedeutet in der Praxis, dass eine Änderung an common-auth gleichzeitig alle Dienste betrifft, die diese Datei einbinden, was für konsistente Sicherheitsrichtlinien sorgt, aber bei unbedachten Änderungen auch unerwartete Nebenwirkungen auf andere Dienste haben kann.

Die Reihenfolge der Zeilen innerhalb einer Gruppe ist entscheidend, denn PAM wertet sie strikt von oben nach unten aus. Ein sufficient-Modul, das versehentlich vor einem notwendigen required-Modul steht, kann dazu führen, dass sich ein Login als erfolgreich meldet, obwohl eine spätere, eigentlich zwingende Prüfung nie erreicht wird. Deshalb gilt die Regel, PAM-Konfigurationsdateien nur mit vollem Verständnis der Reihenfolge zu ändern und Änderungen stets zuerst in einer zweiten, parallel geöffneten Root-Sitzung zu testen, bevor man die aktuelle Sitzung beendet.

6. Praxisbeispiel: Login-Sperre nach Fehlversuchen mit faillock

Die Datei /etc/security/faillock.conf steuert das Verhalten von pam_faillock.so zentral, ohne dass die Modulzeile in jeder einzelnen /etc/pam.d/-Datei mit Argumenten überladen werden muss. Die Direktive deny legt fest, nach wie vielen Fehlversuchen ein Konto gesperrt wird, unlock_time legt die Sperrdauer in Sekunden fest, und fail_interval definiert das Zeitfenster, innerhalb dessen Fehlversuche gezählt werden. Diese zentrale Konfigurationsdatei ist seit den neueren Versionen von pam_faillock der empfohlene Weg gegenüber der älteren Praxis, Argumente direkt in die PAM-Zeilen zu schreiben.

Ein gesperrtes Konto lässt sich mit faillock --user benutzername einsehen und mit faillock --user benutzername --reset vorzeitig entsperren, was besonders hilfreich ist, wenn sich ein legitimer Benutzer versehentlich selbst ausgesperrt hat, etwa durch mehrfach falsch eingegebene Passwörter nach einem Systemwechsel. Wichtig ist, den Root-Benutzer standardmäßig von dieser Sperre auszunehmen oder zumindest einen alternativen Zugangsweg offenzuhalten, damit man sich nicht selbst dauerhaft aus einem Server aussperrt.

# /etc/security/faillock.conf — central faillock configuration
deny = 5
unlock_time = 900
fail_interval = 600
even_deny_root
root_unlock_time = 60

# /etc/pam.d/common-auth — enable faillock in the auth stack
auth required pam_faillock.so preauth
auth [success=1 default=ignore] pam_unix.so
auth [default=die] pam_faillock.so authfail
auth sufficient pam_faillock.so authsucc

7. Zwei-Faktor-Authentifizierung mit pam_google_authenticator

Das Paket libpam-google-authenticator stellt ein PAM-Modul bereit, das zeitbasierte Einmalpasswörter nach dem TOTP-Standard prüft, kompatibel mit gängigen Authenticator-Apps. Jeder Benutzer führt einmalig google-authenticator aus, wodurch ein geheimer Schlüssel in ~/.google_authenticator abgelegt und ein QR-Code zum Scannen ausgegeben wird. Anschließend wird das Modul in der jeweiligen auth-Gruppe eingehängt, typischerweise in Kombination mit pam_unix.so, sodass ein erfolgreicher Login sowohl das Passwort als auch den zeitlich begrenzten Code erfordert.

Eine kritische Konfigurationsentscheidung betrifft die SSH-Serverkonfiguration selbst: ChallengeResponseAuthentication yes in /etc/ssh/sshd_config muss gesetzt sein, damit OpenSSH die PAM-Konversation für den zweiten Faktor überhaupt zulässt, und diese Einstellung muss zusammen mit UsePAM yes aktiv sein. Fehlt eine dieser beiden Einstellungen, wird das PAM-Modul niemals aufgerufen, selbst wenn die PAM-Konfigurationsdatei selbst korrekt ist, ein Fehler, der in der Praxis viele Administratoren zunächst stundenlang an der falschen Stelle suchen lässt.

8. PAM-Probleme debuggen

Ein weiteres nützliches Werkzeug ist pamtester, mit dem sich einzelne PAM-Dienste isoliert von der eigentlichen Anwendung testen lassen, etwa pamtester sshd benutzername authenticate, um zu prüfen, ob die Authentifizierung für einen bestimmten Dienst grundsätzlich funktioniert, ohne tatsächlich eine SSH-Verbindung aufbauen zu müssen. Das reduziert die Feedback-Schleife beim Testen von Konfigurationsänderungen erheblich, weil kein vollständiger Verbindungsaufbau nötig ist.

# Test a specific PAM service in isolation, without a real SSH connection
sudo pamtester sshd deployuser authenticate

# Check whether an account is currently locked by faillock
faillock --user deployuser

# Watch PAM related log entries live while reproducing a login issue
sudo journalctl -f | grep -i pam

# Temporarily enable verbose debug output for a single module
# (add "debug" as an argument to the module line in the pam.d file first)
sudo journalctl -f -u sshd

Der wichtigste Debugging-Kanal für PAM ist das Systemlog, das über journalctl -u sshd oder allgemeiner über journalctl | grep pam eingesehen werden kann. Viele Module unterstützen zusätzlich ein debug-Argument in der PAM-Konfigurationszeile selbst, das deutlich ausführlichere Meldungen ins Log schreibt, etwa welches konkrete Modul einen Login abgelehnt hat und aus welchem Grund. Diese Option sollte in der Produktion nur temporär aktiviert werden, weil sie potenziell sensible Details wie Benutzernamen bei Fehlversuchen protokolliert.

Ein häufiger Fehler beim Debuggen ist, eine PAM-Konfigurationsdatei direkt zu bearbeiten und die aktuelle SSH-Sitzung zu schließen, bevor die Änderung getestet wurde. Ist die neue Konfiguration fehlerhaft, kann sich niemand mehr per SSH anmelden, auch nicht der Administrator selbst. Die sichere Praxis ist deshalb, vor jeder Änderung eine zweite Root-Sitzung offen zu halten, in einem separaten Terminal, und die Änderung erst nach einem erfolgreichen Test-Login aus einer neuen Sitzung heraus als abgeschlossen zu betrachten.

Ein zusätzliches Sicherheitsnetz bietet eine geplante, zeitversetzte Rückstellung: Ein per Cron oder systemd-Timer eingerichteter Job, der die vorherige Version der pam.d-Datei nach fünf Minuten automatisch wiederherstellt, sofern kein manueller Abbruch erfolgt ist, verhindert eine dauerhafte Aussperrung selbst dann, wenn die zweite Root-Sitzung aus irgendeinem Grund nicht verfügbar war. Dieses Muster wird in vielen Automatisierungswerkzeugen für Konfigurationsänderungen an sicherheitskritischen Diensten standardmäßig eingesetzt.

9. Module im Vergleich und Reihenfolge-Fallstricke

Die Tabelle oben zeigt, dass verschiedene Module bewusst unterschiedliche Management-Gruppen bedienen und deshalb an unterschiedlichen Stellen im Login-Ablauf greifen. Ein verbreiteter Konfigurationsfehler ist, ein account-Modul wie pam_faillock.so versehentlich nur in der auth-Gruppe einzutragen, wodurch die Sperrprüfung bei bereits erfolgreich authentifizierten, aber gesperrten Konten übersprungen wird, weil account-Module unabhängig von auth-Modulen ausgewertet werden.

Ebenso kritisch ist die Reihenfolge innerhalb derselben Gruppe: Ein sufficient-Modul für Zwei-Faktor-Authentifizierung, das vor der Sperrprüfung steht, kann dazu führen, dass ein korrekt eingegebener zweiter Faktor den gesamten Auth-Stack als erfolgreich abschließt, bevor pam_faillock.so überhaupt geprüft wurde. Die robuste Reihenfolge platziert Sperrprüfungen konsequent vor jeder tatsächlichen Anmeldedatenprüfung, wie im Beispiel des vorherigen Abschnitts mit preauth gezeigt.

Ein weiterer Vergleichspunkt betrifft die Wartbarkeit: Module wie pam_unix.so und pam_limits.so benötigen kaum Pflege, sobald sie einmal korrekt eingerichtet sind, während pam_faillock.so und pam_google_authenticator.so regelmäßige Kontrolle verlangen, etwa um versehentlich dauerhaft gesperrte Konten oder abgelaufene TOTP-Schlüssel nach einem Gerätewechsel zu erkennen. Wer PAM produktiv betreibt, sollte deshalb periodisch mit faillock --user und einem Blick in journalctl prüfen, ob die konfigurierten Module tatsächlich wie beabsichtigt greifen.

10. Zusammenfassung

PAM entkoppelt Anwendungen von der konkreten Authentifizierungslogik über einen konfigurierbaren Stack aus vier Management-Gruppen: auth, account, password und session. Control-Flags wie required, requisite, sufficient und optional steuern, wie das Ergebnis eines einzelnen Moduls den Gesamtausgang beeinflusst, und die Reihenfolge der Zeilen innerhalb einer Gruppe ist dabei entscheidend für das tatsächliche Verhalten.

Module wie pam_unix.so, pam_faillock.so und pam_google_authenticator.so decken die häufigsten praktischen Anforderungen ab: Passwortprüfung, Sperren nach Fehlversuchen und Zwei-Faktor-Authentifizierung. Wer PAM-Konfigurationen ändert, sollte immer eine zweite Root-Sitzung offen halten, bis die Änderung erfolgreich getestet wurde, denn ein Fehler in der PAM-Konfiguration kann den kompletten Login-Zugang zu einem Server blockieren.

11. FAQ: PAM-Authentifizierungsmodule