SYSTEMD-CRYPTSETUP(8) systemd-cryptsetup SYSTEMD-CRYPTSETUP(8)

systemd-cryptsetup, systemd-cryptsetup@.service - Logik für vollständige Plattenverschlüsselung

ÜBERSICHT

systemd-cryptsetup [OPTIONEN…] attach DATENTRÄGER QUELLGERÄT [SCHLÜSSELDATEI] [KONFIG]

systemd-cryptsetup [OPTIONEN…] detach DATENTRÄGER

systemd-cryptsetup@.service

system-systemd\x2dcryptsetup.slice

systemd-cryptsetup wird zum Einrichten (mit attach) und Herunterbringen (mit detach) des Zugriffs auf ein verschlüsseltes Blockgerät verwandt. Es ist hauptsächlich zum Einsatz mit systemd-cryptsetup@.service(8) während der frühen Systemstartphase gedacht, kann aber auch händisch aufgerufen werden. Die positionsabhängigen Argumente DATENTRÄGER, QUELLGERÄT, SCHLÜSSELDATEI und CRYPTTAB-OPTIONEN haben die gleiche Bedeutung wie die Felder in crypttab(5).

systemd-cryptsetup@.service(8) ist ein Dienst, der für den Zugriff auf verschlüsselte Blockgeräte verantwortlich ist Er wird für jedes Gerät, das der Entschlüsselung bedarf, instanziiert.

systemd-cryptsetup@.service(8)-Instanzen sind Teil der Scheibe system-systemd\x2dcryptsetup.slice, die erst sehr spät im Herunterfahrprozess zerstört wird. Dies ermöglicht es verschlüsselten Geräten, im Betrieb zu bleiben, bis die Dateisysteme ausgehängt wurden.

Systemd-cryptsetup@.service erfragt gemäß der Passwordagent-Logik[1] die Festplattenpasswörter, damit die Eingabe des Passworts durch den Benutzer während des Systemstarts und im laufenden Betrieb nach dem korrekten Mechanismus geschieht.

In der frühen Phase des Systemstarts und beim Neuladen der Konfiguration der Systemverwaltung wird die /etc/crypttab von systemd-cryptsetup-generator(8) in Systemd-cryptsetup@.service-Units übersetzt.

Um einen Datenträger zu entsperren, wird ein Passwort oder ein binärer Schlüssel benötigt. systemd-cryptsetup@.service versucht, ein geeignetes Passwort oder einen binären Schlüssel zu erlangen, indem in dieser Reihenfolge folgender Mechanismus durchlaufen wird:

1. Falls (mittels der dritten Spalte in /etc/crypttab) explizit eine Schlüsseldatei konfiguriert ist, wird ein daraus eingelesener Schlüssel verwandt. Falls (mittels der Option pkcs11-uri=, fido2-device= oder tpm2-device=) ein PKCS#11-Token oder TPM2-Gerät konfiguriert ist, wird der Schlüssel vor der Verwendung entschlüsselt.
2. Falls auf diese Weise keine Schlüsseldatei explizit konfiguriert ist, wird eine Schlüsseldatei automatisch aus /etc/cryptsetup-keys.d/Datenträger.key und /run/cryptsetup-keys.d/Datenträger.key geladen, falls diese vorhanden sind. Auch hier gilt, dass jeder so gefundene Schlüssel vor der Verwendung entschlüsselt wird, falls ein PKCS#11-/FIDO2-/TPM2-Token/Gerät konfiguriert ist.
3. Falls die Option try-empty-password angegeben ist, wird das Entsperren des Datenträgers mit einem leeren Passwort versucht.
4. Dann wird der Kernel-Schlüsselbund auf ein geeignetes zwischengespeichertes Passwort aus vorherigen Versuchen übeprüft.
5. Schließlich wird der Benutzer nach einem Passwort gefragt, möglicherweise mehrfach, außer die Option headless ist gesetzt.

Falls kein geeigneter Schlüssel mittels eines der oben beschriebenen Mechanismen erlangt werden kann, schlägt die Aktivierung des Datenträgers fehl.

systemd(1), systemd-cryptsetup-generator(8), crypttab(5), systemd-cryptenroll(1), cryptsetup(8), Von Systemd durchgeführte TPM2-PCR-Messungen[2]

1.
Passwortagent-Logik
https://systemd.io/PASSWORD_AGENTS/
2.
Von Systemd durchgeführte TPM2-PCR-Messungen
https://systemd.io/TPM2_PCR_MEASUREMENTS

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.

systemd 255