# Passwd & Shadow Masterclass: Identitäten schützen

TL;DR / Management Summary Ein Passwort ist unter Linux nur so sicher wie sein Hash. Während /etc/passwd für jeden lesbar ist, enthält /etc/shadow die kryptografischen Geheimnisse und darf nur von Root gelesen werden. In diesem Modul lernen wir, wie wir Passwörter verwalten, wie wir den Lebenszyklus eines Logins mittels chage steuern und warum moderne Hashing-Verfahren (wie YESCRYPT oder SHA-512) heute Pflicht sind.

# 1. Einführung & Architektur

Die Trennung der Geheimnisse.

In den Anfangstagen lagen Passwörter in der passwd. Da dies ein Sicherheitsrisiko war, wurde die shadow Datei eingeführt.

# Die Shadow-Datei Anatomie (Mermaid)

graph LR
    A[Line in /etc/shadow] --> B[Username: root]
    A --> C[Hash: $6$rounds=5000$...]
    A --> D[Last Changed: Days since 1970]
    A --> E[Expiry Info: Min/Max/Warn]
    subgraph "Hash Header"
        C1["$1: MD5"]
        C2["$5: SHA-256"]
        C3["$6: SHA-512"]
        C4["$y: Yescrypt"]
    end
    C --- C1

# 2. passwd: Das Werkzeug des Admins

Sicherer Passwortwechsel.

# Passwort setzen/ändern

sudo passwd johndoe

# Account sperren (ohne Löschen)

# Setzt ein '!' vor den Hash in /etc/shadow -> Login unmöglich
sudo passwd -l johndoe

# Entsperren
sudo passwd -u johndoe

# 3. chage: Passwort-Lebenszyklus steuern

Compliance erzwingen.

Mit chage definieren wir, wie lange ein Passwort gültig ist.

# Passwort-Ablauf setzen

# -M: Max Days, -m: Min Days, -W: Warning Days
sudo chage -m 1 -M 90 -W 7 johndoe

# User zur Änderung beim nächsten Login zwingen

Ideal beim Onboarding neuer Kollegen:

sudo chage -d 0 johndoe

# 4. Day-2 Operations: Hashing Algorithmen

Zukunftssichere Kryptografie.

Moderne Distributionen (wie Arch oder SLES 15) nutzen YESCRYPT. Falls Sie auf einem alten System sind, prüfen Sie die Einstellung in der /etc/login.defs.

# Systemweiten Default ändern

# In /etc/login.defs
ENCRYPT_METHOD YESCRYPT

# 5. Troubleshooting & “War Stories”

Wenn der Login klemmt.

# Story 1: “Der abgelaufene Admin”

Symptom: Ein Admin kann sich per SSH einloggen (Key-Auth), aber sudo schlägt fehl mit “Authentication token expired”. Ursache: Das Passwort des Admins ist abgelaufen. Sudo verlangt ein gültiges Passwort, auch wenn der Login via Key stattfand. Lösung: Passwort via Konsole/Root ändern: passwd admin. Nutzen Sie chage -l admin, um den Status zu prüfen.

# Story 2: “Duplicate Hash Warnung”

Symptom: Ein Security-Scanner meldet, dass zwei User den gleichen Passwort-Hash in /etc/shadow haben. Ursache: Ein Admin hat einen User angelegt und das Passwort durch manuelles Kopieren der Shadow-Zeile “gesetzt”, anstatt passwd zu nutzen. Dies umgeht den Salt (Zufalls-Präfix), der den Hash eigentlich einzigartig machen sollte. Lösung: Ändern Sie das Passwort eines der User mit passwd. Ein gleicher Hash ist ein Indiz für unsichere Passwort-Management-Praktiken.

# 6. Fazit & Empfehlung

• Audit: Führen Sie pwck regelmäßig aus, um die Integrität der Password- und Shadow-Dateien zu prüfen.
• Security: Deaktivieren Sie Passwörter für alle User, die nur via SSH-Key zugreifen sollen: passwd -d <user> und passwd -l <user>.
• Wartung: Nutzen Sie für das Team-Management immer einen zentralen Verzeichnisdienst (Artikel 136).

# Anhang: Cheatsheet