sammlung:pam_sshd

Inhaltsverzeichnis

PAM-Konfiguration für SSHD erklärt

PAM-Konfiguration für SSHD erklärt

Die PAM-Konfiguration für den SSH-Dienst (sshd) ist typischerweise sehr schlank und nutzt include-Direktiven, um zentrale Authentifizierungsregeln wiederzuverwenden. Diese Seite erklärt den Aufbau am Beispiel einer Standard-SSHD-Konfiguration.

Die SSHD PAM-Konfiguration

Datei: /etc/pam.d/sshd

#%PAM-1.0

auth      include   system-remote-login
account   include   system-remote-login
password  include   system-remote-login
session   include   system-remote-login

Zeilenweise Erklärung

1. PAM-Version Header

#%PAM-1.0

Element	Bedeutung
#%PAM-1.0	Gibt die verwendete PAM-Version an. Dies ist eine Kommentarzeile, die die PAM-Bibliothek informiert
Zweck	Kompatibilitätskennzeichnung, sollte bei allen PAM-Konfigurationsdateien vorhanden sein

2. Die vier Modultypen

Die Konfiguration definiert für jeden der vier PAM-Modultypen eine Regel:

auth      include   system-remote-login

Element	Bedeutung
auth	Modultyp: Authentifizierung - prüft Benutzeridentität (Passwort, Keys, etc.)
include	Control Flag: Bindet eine andere PAM-Konfigurationsdatei ein
system-remote-login	Name der einzubindenden Konfigurationsdatei (/etc/pam.d/system-remote-login)

account   include   system-remote-login

Element	Bedeutung
account	Modultyp: Account-Management - prüft ob Zugriff erlaubt ist (z.B. Account gesperrt, Zeitbeschränkungen)

password  include   system-remote-login

Element	Bedeutung
password	Modultyp: Passwort-Management - wird bei Passwortänderungen verwendet

session   include   system-remote-login

Element	Bedeutung
session	Modultyp: Session-Management - Aktionen vor/nach Login (z.B. Logs, Home-Verzeichnis mounten)

Was bedeutet "include"?

Das include Control Flag hat eine besondere Funktion:

Es bindet eine andere PAM-Konfigurationsdatei vollständig ein
Alle Regeln der eingebundenen Datei werden verarbeitet, als wären sie direkt hier geschrieben
Bei Fehler in der eingebundenen Datei wird der Stack trotzdem fortgesetzt (anders als bei substack)
Dies ermöglicht zentrale, wiederverwendbare Konfigurationen

Vorteil: Änderungen an system-remote-login gelten automatisch für alle Dienste, die sie einbinden (SSH, FTP, etc.)

Speicherort

# Datei ansehen
cat /etc/pam.d/system-remote-login
 
# Oder mit sudo falls Rechte fehlen
sudo cat /etc/pam.d/system-remote-login

Arch Linux / Manjaro:

#%PAM-1.0

auth      required  pam_tally2.so        onerr=succeed  file=/var/log/tallylog
auth      required  pam_shells.so
auth      required  pam_nologin.so
auth      include   system-login

account   required  pam_tally2.so
account   required  pam_access.so
account   required  pam_nologin.so
account   include   system-login

password  include   system-login

session   optional  pam_motd.so          motd=/etc/motd
session   optional  pam_mail.so          dir=/var/spool/mail standard quiet
session   include   system-login

Debian / Ubuntu:

#%PAM-1.0

auth       required   pam_env.so
auth       required   pam_unix.so nullok
auth       required   pam_nologin.so

account    required   pam_unix.so
account    required   pam_nologin.so

password   required   pam_unix.so sha512 shadow

session    required   pam_limits.so
session    required   pam_unix.so
session    optional   pam_motd.so
session    optional   pam_lastlog.so

Red Hat / CentOS / Fedora:

#%PAM-1.0

auth       required   pam_sepermit.so
auth       include    password-auth

account    required   pam_nologin.so
account    include    password-auth

password   include    password-auth

session    optional   pam_keyinit.so force revoke
session    include    password-auth
session    optional   pam_motd.so

Was wird tatsächlich geprüft?

Bei einem SSH-Login durchläuft PAM folgende Schritte (vereinfacht):

1. Auth-Phase (Authentifizierung)

pam_shells.so: Prüft ob die Shell des Benutzers in /etc/shells erlaubt ist
pam_nologin.so: Prüft ob /etc/nologin existiert (verhindert Login außer für root)
pam_unix.so: Prüft Passwort gegen /etc/shadow oder akzeptiert SSH-Key
pam_tally2.so / pam_faillock.so: Zählt Fehlversuche und sperrt bei zu vielen

2. Account-Phase (Zugriffsprüfung)

pam_unix.so: Prüft ob Account abgelaufen oder gesperrt ist
pam_access.so: Prüft /etc/security/access.conf für Zugriffsbeschränkungen
pam_nologin.so: Erneute Prüfung in Account-Phase
pam_time.so: (Falls konfiguriert) Prüft zeitbasierte Zugriffsbeschränkungen

3. Password-Phase (Passwortänderung)

Wird nur relevant wenn Passwort geändert werden soll (passwd-Kommando)
pam_unix.so: Handhabt die eigentliche Passwortänderung
pam_pwquality.so: (Falls konfiguriert) Prüft Passwortstärke

4. Session-Phase (Session-Setup)

pam_limits.so: Setzt Ressourcen-Limits aus /etc/security/limits.conf
pam_unix.so: Loggt Login-Event
pam_motd.so: Zeigt Message of the Day (/etc/motd)
pam_lastlog.so: Zeigt letzten Login und speichert aktuellen
pam_umask.so: Setzt umask für die Session

Praktische Beispiele

1. Nachvollziehen was beim SSH-Login passiert

# SSHD PAM-Konfiguration anzeigen
cat /etc/pam.d/sshd
 
# Eingebundene Datei anzeigen
cat /etc/pam.d/system-remote-login
 
# Falls weitere includes vorhanden, diese auch anzeigen
cat /etc/pam.d/system-login
cat /etc/pam.d/password-auth

# PAM-Aktivitäten im Journal
sudo journalctl -u sshd | grep pam
 
# Authentifizierungs-Logs
sudo tail -f /var/log/auth.log        # Debian/Ubuntu
sudo tail -f /var/log/secure          # RHEL/CentOS
 
# Fehlgeschlagene Login-Versuche
sudo journalctl -u sshd | grep "Failed password"

3. SSHD PAM-Konfiguration anpassen

Warnung: Änderungen sollten vorsichtig vorgenommen werden. Immer eine offene SSH-Session zum Testen behalten!

Beispiel: Zwei-Faktor-Authentifizierung hinzufügen

#%PAM-1.0

# Google Authenticator VOR system-remote-login
auth      required  pam_google_authenticator.so

auth      include   system-remote-login
account   include   system-remote-login
password  include   system-remote-login
session   include   system-remote-login

Beispiel: Zusätzliche Session-Logs

#%PAM-1.0

auth      include   system-remote-login
account   include   system-remote-login
password  include   system-remote-login
session   include   system-remote-login

# Zusätzliches Logging nach includes
session   optional  pam_exec.so /usr/local/bin/log-ssh-session.sh

4. Eigene include-Datei für Remote-Zugriffe erstellen

# Eigene Konfiguration für alle Remote-Dienste
sudo nano /etc/pam.d/my-remote-login

Inhalt von my-remote-login:

#%PAM-1.0

# Strenge Regeln für Remote-Zugriff
auth      required  pam_faillock.so preauth deny=3 unlock_time=1800
auth      required  pam_unix.so
auth      required  pam_faillock.so authfail deny=3 unlock_time=1800

account   required  pam_faillock.so
account   required  pam_unix.so
account   required  pam_time.so

password  required  pam_pwquality.so retry=3 minlen=12
password  required  pam_unix.so sha512 shadow

session   required  pam_limits.so
session   required  pam_unix.so
session   optional  pam_lastlog.so

Dann in /etc/pam.d/sshd:

#%PAM-1.0

auth      include   my-remote-login
account   include   my-remote-login
password  include   my-remote-login
session   include   my-remote-login

Unterschiede zwischen Distributionen

Distribution	Haupt-Include-Datei	Besonderheiten
Arch Linux	system-remote-login	Nutzt system-login als zweite Ebene
Debian/Ubuntu	common-auth, common-account, common-password, common-session	Mehrere separate includes pro Typ
RHEL/CentOS	password-auth, system-auth	password-auth für Remote, system-auth für lokal
SUSE	common-auth-pc	Eigenes Schema mit -pc (Pluggable Client)

Include-Hierarchie verstehen

Arch Linux Beispiel:

/etc/pam.d/sshd
    └── include: system-remote-login
            └── include: system-login
                    └── required: pam_unix.so, pam_systemd.so, etc.

Debian/Ubuntu Beispiel:

/etc/pam.d/sshd
    ├── auth    → include: common-auth
    ├── account → include: common-account
    ├── password→ include: common-password
    └── session → include: common-session

Debugging und Troubleshooting

PAM-Debug aktivieren

# In jeder Zeile "debug" hinzufügen
auth      required  pam_unix.so debug
 
# Logs anzeigen
sudo journalctl -u sshd -f

Häufige Probleme

Problem	Ursache	Lösung
SSH-Login funktioniert nicht	Tippfehler in PAM-Config	Include-Dateien prüfen, Syntax kontrollieren
„Permission denied“ trotz richtigem Passwort	pam_nologin aktiv	/etc/nologin entfernen oder als root einloggen
Alle Logins geblockt	Fehlerhafte include-Datei	Im Notfall mit init=/bin/bash booten und korrigieren
Key-Auth funktioniert, Passwort nicht	pam_unix.so fehlt in auth	Include-Dateien prüfen, pam_unix.so ergänzen

Test-Strategie

# 1. Aktuelle Config sichern
sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.backup
sudo cp /etc/pam.d/system-remote-login /etc/pam.d/system-remote-login.backup
 
# 2. Änderungen vornehmen
sudo nano /etc/pam.d/sshd
 
# 3. SSH-Dienst neu laden (NICHT beenden!)
sudo systemctl reload sshd
 
# 4. In NEUER Session testen (alte Session OFFEN lassen!)
ssh user@localhost
 
# 5. Bei Problemen: Aus alter Session zurückrollen
sudo cp /etc/pam.d/sshd.backup /etc/pam.d/sshd
sudo systemctl reload sshd

Sicherheitshinweise

Niemals ohne Backup: Immer Kopie der Originaldatei erstellen
Offene Session: Bei Remote-Änderungen immer eine aktive SSH-Session offen halten
Schrittweise testen: Nie mehrere Änderungen gleichzeitig
Root-Zugang sichern: Alternative Zugangswege offen halten (Konsole, IPMI, VNC)
Vorsicht mit required: Ein fehlendes required-Modul verhindert alle Logins
Logs überwachen: Nach Änderungen sofort Logs prüfen

Best Practices

Zentrale Konfiguration: include nutzen statt alles in sshd zu schreiben
Dokumentation: Änderungen mit Kommentaren versehen (# am Zeilenanfang)
Modular arbeiten: Eigene include-Dateien für spezifische Anforderungen
Testing: Erst in Testumgebung, dann produktiv
Version Control: /etc/pam.d/ in Git versionieren
Monitoring: PAM-Fehler in Monitoring-System aufnehmen

Siehe auch

cli, authentication, security, remote-access