CRYPTTAB(5) crypttab CRYPTTAB(5) BEZEICHNUNG crypttab - Konfiguration fur verschlusselte Blockgerate UBERSICHT /etc/crypttab BESCHREIBUNG Die Datei /etc/crypttab beschreibt verschlusselte Blockgerate, die wahrend der fruhen Systemstartphase eingerichtet werden. Leere Zeilen und Zeilen, die mit dem Zeichen >>#<< beginnen, werden ignoriert. Jede andere verbleibende Zeile beschreibt ein verschlusseltes Blockgerat. Felder werden durch Leeraum begrenzt. Jede Zeile hat die Form Datentragername verschlusseltes_Gerat Schlusseldatei Optionen Die ersten zwei Felder sind verpflichtend, die verbleibenden zwei optional. Die Einrichtung eines verschlusselten Blockgerates mittels dieser Datei kann in vier Verschlusselungsmodi erfolgen: LUKS, TrueCrypt, BitLocker und einfach. Siehe cryptsetup(8) fur weitere Informationen uber jeden Modus. Wenn kein Modus in dem Optionsfeld festgelegt wurde und das Blockgerat eine LUKS-Signatur enthalt, dann wird es als LUKS-Gerat geoffnet. Andernfalls wird angenommen, dass es in rohem DM-Crypt-Format (einfacher Modus) ist. Die vier Felder von /etc/crypttab sind wie folgt definiert: 1. Das erste Feld enthalt den Namen des resultierenden Datentragers mit entschlusselten Daten; sein Blockgerat wird unterhalb von /dev/mapper/ eingerichtet. 2. Das zweite Feld enthalt einen Pfad zu dem darunterliegenden Blockgerat oder der Datei oder eine Festlegung eines Blockgerates mittels >>UUID=<< gefolgt von der UUID. 3. Das dritte Feld gibt einen absoluten Pfad auf eine Datei mit dem Verschlusselungsschlussel an. Optional kann dem Pfad >>:<< und eine /etc/fstab-artige Gerateangabe folgen (z.B. beginnend mit >>LABEL=<< oder ahnlichem). In diesem Fall wird der Pfad relativ zu der Wurzel des festgelegten Geratedateisystems angenommen. Falls das Feld nicht vorhanden oder >>none<< oder >>-<< lautet, wird eine Schlusseldatei, die nach dem zu entsperrenden Datentrager benannt ist (d.h. der ersten Spalte der Zeile), der >>.key<< angehangt ist, automatisch aus den Verzeichnissen /etc/cryptsetup-keys.d/ und /run/cryptsetup-keys.d/ geladen, falls vorhanden. Andernfalls muss das Passwort wahrend des Systemstarts manuell eingegeben werden. Fur die Verschlusselung des Auslagerungsbereichs kann /dev/urandom als Schlusseldatei verwandt werden, was zu einem zufalligen Schlussel fuhrt. Falls sich der festgelegte Schlusseldateipfad auf ein AF_UNIX-Datenstrom-Socket im Dateisystem bezieht, wird der Schlussel beschafft, indem eine Verbindung zu dem Socket aufgebaut und er aus der Verbindung gelesen wird. Dies ermoglicht der Implementierung eines Dienstes, die Schlusselinformationen dynamisch bereitzustellen, zu dem Zeitpunkt, zu dem sie benotigt werden. Details sind weiter unten beschrieben. 4. Das vierte Feld, falls vorhanden, ist eine Kommata-getrennte Liste von Optionen. Die unterstutzten Optionen sind nachfolgend aufgefuhrt. SCHLUSSELBESCHAFFUNG Es werden sechs verschiedene Mechanismen zur Beschaffung des Entschlusselungs-Schlussels oder der Passphrase zum Entsperren des verschlusselten Datentragers unterstutzt. Konkret: 1. Am offensichtlichsten ist, dass der Benutzer interaktiv wahrend der Datentrageraktivierung (d.h. typischerweise beim Systemstart) danach gefragt und gebeten werden kann, die notwendigen Passphrasen einzugeben. 2. Der (entschlusselte) Schlussel kann aus einer Datei auf der Platte, moglicherweise einem Wechselmedium, eingelesen werden. Das dritte Feld jeder Zeile kodiert den Ort, Details sind weiter oben beschrieben. 3. Der (entschlusselte) Schlussel kann von einem anderen Dienst erbeten werden, indem anstelle einer Schlusseldatei im dritten Feld ein AF_UNIX-Dateisystem-Socket festgelegt wird. Details sind weiter oben und nachfolgend beschrieben. 4. Der Schlussel kann uber ein PKCS#11-kompatibles Hardware-Token oder eine Smartcard beschafft werden. In diesem Fall wird ein verschlusselter Schlussel auf einer Platte/einem Wechselmedium gespeichert und mittels AF_UNIX beschafft, oder in dem LUKS2-JSON-Token-Metadatenkopf gespeichert. Der verschlusselte Schlussel wird dann durch den PKCS#11-Token mittels eines darauf gespeicherten RSA-Schlussels entschlusselt und dann fur das Entsperren des verschlusselten Datentragers verwandt. Verwenden Sie die nachfolgend beschriebene Option pkcs11-uri=, um diesen Mechanismus zu verwenden. 5. Auf ahnliche Weise kann der Schlussel mittels eines FIDO2-kompatiblen Hardware-Security-Tokens (der die Erweiterung >>hmac-secret<< implementieren muss) beschafft werden. In diesem Fall wird ein zufallig erstellter Schlussel wahrend der Registrierung auf der Platte/dem Wechsellaufwerk gespeichert und mittels AF_UNIX beschafft, oder in dem LUKS2-JSON-Token-Metadatenkopf gespeichert. Der zufallige Schlussel wird mit einer indizierten Hash-Funktion (HMAC) auf dem FIDO2-Token gehasht, wobei ein auf dem Token gespeicherter geheimer Schlussel verwandt wird, der diesen nie verlasst. Der daraus entstandene Hash-Wert wird dann als Schlussel benutzt, um den verschlusselte Datentrager zu entsperren. Verwenden Sie die nachfolgend beschriebene Option fido2-device=, um diesen Mechanismus zu verwenden. 6. Auf ahnliche Weise kann der Schlussel mittels eines TPM2-Sicherheits-Chips beschafft werden. In diesem Fall wird (wahrend der Registrierung) ein zufallig erstellter Schlussel, der durch einen asymmetrischen, vom TPM2-Chip abgeleiteten Schlussel verschlusselt wurde, auf der Platte/dem Wechsellaufwerk gespeichert und mittels AF_UNIX beschafft, oder in dem LUKS2-JSON-Token-Metadatenkopf gespeichert. Verwenden Sie die nachfolgend beschriebene Option tpm2-device=, um diesen Mechanismus zu verwenden. Fur die letzteren funf Mechanismen ist die Quelle fur das Schlusselmaterial, das zum Entsperren des Datentragers verwandt wird, primar in dem dritten Feld jeder /etc/crypttab-Zeile kodiert, kann aber auch in /etc/cryptsetup-keys.d/ und /run/cryptsetup-keys.d/ (siehe oben) oder in den LUKS2-JSON-Token-Datenkopf (im Falle der letzteren drei) konfiguriert werden. Verwenden Sie das Werkzeug systemd-cryptenroll(1), um PKCS#11-, FIDO2- und TPM2-Gerate in LUKS2-Datentragern zu registrieren. UNTERSTUTZTE OPTIONEN Die folgenden Optionen konnen im vierten Feld jeder Zeile verwandt werden: cipher= Legt die zu verwendende Chiffre fest. Siehe cryptsetup(8) fur mogliche Werte und den Vorgabewert dieser Option. Eine Chiffre mit unvorhersagbaren IV-Werten, wie >>aes-cbc-essiv:sha256<<, wird empfohlen. Eingebettete Kommata in der Festlegung der Chiffre mussen durch vorangestellte Ruckwartsschragstriche maskiert werden, wie im nachfolgenden Beispiel gezeigt. Hinzugefugt in Version 186. discard Erlaubt die Durchleitung von Discard-Anfragen an das verschlusselte Blockgerat. Dies verbessert die Leistung bei SSD-Speichern, hat aber Auswirkungen auf die Sicherheit. Hinzugefugt in Version 207. hash= Legt den fur Passworter zu verwendenden Hash fest. Siehe cryptsetup(8) fur mogliche Werte und den Vorgabewert dieser Option. Hinzugefugt in Version 186. header= Verwendet ein abgetrenntes (separates) Metadatengerat oder -datei, in der die Kopfzeilen, die den oder die Hauptschlussel enthalten, gespeichert sind. Diese Option ist nur fur LUKS- und TrueCrypt/VeraCrypt-Gerate relevant. Siehe cryptsetup(8) fur mogliche Werte und den Vorgabewert dieser Option. Optional kann dem Pfad ein >>:<< und eine /etc/fstab-Geratespezifikation folgen (z.B. beginnend mit >>UUID=<< oder ahnlich). In diesem Fall ist der Pfad relativ zu der Dateisystemwurzel des Gerats. Das Gerat wird automatisch nur fur die LUKS-Gerateaktivierungsdauer eingehangt. Hinzugefugt in Version 219. keyfile-offset= Legt die Anzahl der am Anfang der Schlusseldatei zu uberspringenden Byte fest. Siehe cryptsetup(8) fur mogliche Werte und den Vorgabewert dieser Option. Hinzugefugt in Version 187. keyfile-size= Legt die maximale Anzahl der aus der Schlusseldatei zu lesenden Byte fest. Siehe cryptsetup(8) fur mogliche Werte und den Vorgabewert dieser Option. Diese Option wird im einfachen Verschlusselungsmodus ignoriert, da dann die Schlusseldateigrosse durch die Schlusselgrosse gegeben ist. Hinzugefugt in Version 188. keyfile-erase Falls aktiviert, wird die angegebene Schlusseldatei geloscht, nachdem der Datentrager aktiviert wurde oder wenn die Aktivierung fehlschlug. Dies ist insbesondere nutzlich, wenn die Schlusseldatei vor der Aktivierung nur fluchtig erlangt wurde (z.B. uber eine Datei in /run/, die durch einen vor der Aktivierung ausgefuhrten Dienst erzeugt wurde) und nach der Verwendung entfernt werden muss. Standardmassig aus. Hinzugefugt in Version 246. key-slot= Legt die Schlusselposition, mit der die Passphrase oder der Schlussel verglichen werden soll, fest. Falls die Schlusselposition nicht auf die ubergebene Passphrase oder den Schlussel passt, aber eine andere passen wurde, schlagt die Einrichtung des Gerates dennoch fehl. Diese Option impliziert luks. Siehe cryptsetup(8) fur mogliche Werte. Die Vorgabe ist, alle Schlusselpositionen sequenziell durchzuprobieren. Hinzugefugt in Version 209. keyfile-timeout= Legt die Zeituberschreitung fur das Gerat, auf dem die Schlusseldatei liegt oder das Gerat, das als Schlusseldatei verwandt wird, fest und fallt auf ein Passwort zuruck, falls auf dieses Gerat nicht zugegriffen werden kann. Siehe systemd-cryptsetup-generator(8) fur Schlusseldateien auf externen Geraten. Hinzugefugt in Version 243. luks Erzwingt den LUKS-Modus. Wenn dieser Modus verwandt wird, werden die folgenden Optionen ignoriert, da sie durch die LUKS-Kopfzeilen auf dem Gerat bereitgestellt werden: cipher=, hash=, size=. Hinzugefugt in Version 186. bitlk Entschlusselt BitLocker-Gerat. Entschlusselungsparameter werden durch Cryptsetup aus dem BitLocker-Header abgeleitet. Hinzugefugt in Version 246. _netdev Markiert, dass dieses Kryptogerat Netzwerk benotigt. Es wird nach der Verfugbarkeit des Netzwerkes gestartet, ahnlich wie mit _netdev markierte systemd.mount(5)-Units. Die Dienste-Unit zur Einrichtung dieses Gerates wird zwischen remote-fs-pre.target und remote-cryptsetup.target einsortiert, statt zwischen cryptsetup-pre.target und cryptsetup.target. Tipp: Falls dieses Gerat fur einen in fstab(5) festgelegten Einhangepunkt verwandt wird, sollte die Option _netdev auch fur den Einhangepunkt verwandt werden. Andernfalls konnte eine Abhangigkeitsschleife erstellt werden, bei der der Einhangepunkt durch local-fs.target hereingezogen, wahrend der Dienst zur Konfiguration des Netzwerkes normalerweise nach dem Einhangen des lokalen Dateisystems gestartet wird. Hinzugefugt in Version 235. noauto Dieses Gerat wird nicht zu cryptsetup.target hinzugefugt. Das bedeutet, dass es beim Systemstart nicht automatisch entsperrt wird, ausser etwas anderes zieht es herein. Falls insbesondere das Gerat als Einhangepunkt verwandt wird, wird es wahrend des Systemstarts automatisch entsperrt, ausser der Einhangepunkt selbst ist auch mit noauto deaktiviert. Hinzugefugt in Version 186. nofail Dieses Gerat wird keine harte Abhangigkeit von cryptsetup.target sein. Es wird weiterhin hereingezogen und gestartet, aber das System wird nicht darauf warten, dass das Gerat auftaucht und entsperrt wird und der Systemstart wird nicht fehlschlagen, falls das nicht klappt. Beachten Sie, dass andere Units weiterhin von dem entsperrten Gerat abhangen und weiterhin fehlschlagen konnten. Falls insbesondere das Gerat als Einhangepunkt verwandt wird, muss der Einhangepunkt selbst auch die Option nofail haben, oder der Systemstart wird fehlschlagen, falls das Gerat nicht erfolgreich entsperrt wurde. Hinzugefugt in Version 186. offset= Anfangsversatz im Gerat im Hintergrund, in 512-Byte-Sektoren. Diese Option ist nur fur einfache Gerate relevant. Hinzugefugt in Version 220. plain Erzwingt den einfachen Verschlusselungsmodus. Hinzugefugt in Version 186. read-only, readonly Richtet das verschlusselte Blockgerat schreibgeschutzt ein. Hinzugefugt in Version 186. same-cpu-crypt Fuhrt die Verschlusselung auf der gleichen CPU aus, auf der E/A ubergeben wurde. Die Vorgabe ist die Verwendung einer unbegrenzten Arbeitswarteschlange, so dass die Verschlusselungsarbeit automatisch zwischen verfugbaren CPUs ausbalanciert wird. Dies benotigt Kernel 4.0 oder neuer. Hinzugefugt in Version 242. submit-from-crypt-cpus Deaktiviert das Abladen von Schreibaktionen in einen separaten Thread nach der Entschlusselung. Es gibt einige Situationen, bei denen das Abladen der Schreibaktionen aus Entschlusselungs-Threads in einen dedizierten Thread die Leistung deutlich senkt. Die Vorgabe ist, Schreibaktionen auf einen dedizierten Thread abzuladen, da es fur den CFQ-Scheduler von Vorteil ist, wenn Schreibaktionen im gleichen Kontext ubergeben werden. Dies benotigt Kernel 4.0 oder neuer. Hinzugefugt in Version 242. no-read-workqueue Umgeht die interne Arbeitswarteschlange von dm-crypt und verarbeitet Leseanfragen synchron. Standardmassig werden diese Anfragen in eine Warteschlange eingestellt und dann asynchron verarbeitet. Dies benotigt Kernel 5.9 oder neuer. Hinzugefugt in Version 248. no-write-workqueue Umgeht die interne Arbeitswarteschlange von dm-crypt und verarbeitet Schreibanfragen synchron. Standardmassig werden diese Anfragen in eine Warteschlange eingestellt und dann asynchron verarbeitet. Dies benotigt Kernel 5.9 oder neuer. Hinzugefugt in Version 248. skip= Wie viele 512-Byte-Sektoren der verschlusselten Daten am Anfang ubersprungen werden sollen. Dies unterscheidet sich von der Option offset= im Hinblick auf die im Initialisierungsvektor (IV) fur die Berechnung verwandte Anzahl an Sektoren. Durch die Verwendung von offset= wird die IV-Berechnung durch die gleiche negative Anzahl verschoben. Falls daher offset=n ubergeben wird, wird Sektor n eine Sektorennummer 0 fur die IV-Berechnung erhalten. skip= bewirkt, dass Sektor n auch der erste Sektor des zugeordneten Gerates ist, aber dabei die Nummer n fur die IV-Erstellung hat. Diese Option ist nur fur einfache Gerate relevant. Hinzugefugt in Version 220. size= Legt die Schlusselgrosse in Bits fest. Siehe cryptsetup(8) fur mogliche Werte und den Vorgabewert dieser Option. Hinzugefugt in Version 186. sector-size= Legt die Sektorgrosse in Byte fest. Siehe cryptsetup(8) fur mogliche Werte und den Vorgabewert dieser Option. Hinzugefugt in Version 240. swap Das verschlusselte Gerat wird als Auslagerungsgerat benutzt. Es wird nach der Einrichtung des verschlusselten Blockgerates entsprechend mit mkswap(8) formatiert. Diese Option impliziert plain. WARNUNG: Durch Verwendung der Option swap wird der Inhalt der benannten Partition wahrend jedes Systemstarts zerstort. Stellen Sie daher sicher, dass das zugrundeliegende Blockgerat korrekt angegeben ist. Hinzugefugt in Version 186. tcrypt Verwendet den TrueCrypt-Verschlusselungsmodus. Beim Einsatz dieses Modus werden die folgenden Optionen ignoriert, da sie durch die TrueCrypt-Kopfzeilen bereitgestellt oder nicht anwendbar sind: cipher=, hash=, keyfile-offset=, keyfile-size=, size=. Beim Einsatz dieses Modus wird die Passphrase aus der im dritten Feld ubergebenen Datei gelesen. Es wird nur die erste Zeile dieser Datei ohne das Zeilenvorschubszeichen gelesen. Beachten Sie, dass das TrueCrypt-Format sowohl Passphrasen als auch Schlusseldateien zur Ableitung eines Passworts fur den Datentrager verwendet. Daher mussen die Passphrase und alle Schlusseldateien angegeben werden. Verwenden Sie tcrypt-keyfile=, um den absoluten Pfad zu allen Schlusseldateien anzugeben. Bei der Verwendung einer leeren Passphrase in Kombination mit einer oder mehrerer Schlusseldateien verwenden Sie >>/dev/null<< als Passwortdatei im dritten Feld. Hinzugefugt in Version 206. tcrypt-hidden Verwendet den versteckten TrueCrypt-Datentrager. Diese Option impliziert tcrypt. Dies bildet den versteckten Datentrager, das sich innerhalb des im zweiten Feld angegebenen Datentragers befindet, ab. Beachten Sie, dass es keinen Schutz fur den versteckten Datentrager gibt, falls stattdessen der aussere Datentrager eingehangt wird. Siehe cryptsetup(8) fur weitere Informationen uber diese Beschrankung. Hinzugefugt in Version 206. tcrypt-keyfile= Legt den absoluten Pfad zu der fur ein TrueCrypt-Datentrager zu verwendenden Schlusseldatei fest. Dies impliziert tcrypt und kann mehr als einmal zur Angabe mehrerer Schlusseldateien verwandt werden. Lesen Sie beim Einsatz des TrueCrypt-Verschlusselungsmodus den Eintrag zu tcrypt fur das Verhalten der Passphrase und Schlusseldateien. Hinzugefugt in Version 206. tcrypt-system TrueCrypt im Systemverschlusselungsmodus verwenden. Diese Option impliziert tcrypt. Hinzugefugt in Version 206. tcrypt-veracrypt Pruft auf ein VeraCrypt-Datentrager. VeraCrypt ist eine Abspaltung von TrueCrypt, die grosstenteils kompatibel ist, aber andere, starkere Schlusselableitungsalgorithmen verwendet, die ohne diesen Schalter nicht erkannt werden konnen. Aktivierung dieser Option konnte das Entsperren deutlich verlangsamen, da die Schlusselableitung von VeraCrypt viel langer als die von TrueCrypt dauert. Diese Option impliziert tcrypt. Hinzugefugt in Version 232. veracrypt-pim= Legt den Wert eines angepassten >>Personal Iteration Multiplier<< (PIM) fest, der im Bereich 02147468 fur Standard-Veracrypt-Datentrager und 065535 fur Veracrypt-Systemdatentrager sein kann. Ein Wert 0 impliziert die Vorgabe von Veracrypt. Diese Option wird nur wirksam, wenn tcrypt-veracrypt gesetzt ist. Beachten Sie, dass VeraCrypt einen minimalen erlaubten PIM-Wert erzwingt, der von der Passwortstarke und dem fur die Schlusselableitung verwandten Hash-Algorithmus abhangt. Allerdings pruft veracrypt-pim= dies nicht gegen diese Schranken. Siehe die Veracrypt-Personal-Iteration-Multiplier[1]-Dokumentation fur weitere Informationen. Hinzugefugt in Version 254. timeout= Legt die Zeituberschreitung fur die Abfrage eines Passworts fest. Falls keine Einheit angegeben ist, werden Sekunden verwandt. Unterstutzte Einheiten sind s, ms, us, min, h, d. Eine Zeituberschreitung von 0 wartet unendlich lang (dies ist die Vorgabe). Hinzugefugt in Version 186. tmp= Das verschlusselte Blockgerat wird fur den Einsatz als /tmp/ vorbereitet; es wird mittels mkfs(8) formatiert. Akzeptiert einen Dateisystemtyp als Argument, wie >>ext4<<, >>xfs<< oder >>btrfs<<. Falls kein Argument angegeben ist, ist >>ext4<< die Vorgabe. Diese Option impliziert plain. WARNUNG: Durch Verwendung der Option tmp wird der Inhalt der benannten Partition wahrend jedes Systemstarts zerstort. Stellen Sie daher sicher, dass das zugrundeliegende Blockgerat korrekt angegeben ist. Hinzugefugt in Version 186. tries= Legt die maximale Anzahl an Abfragen des Benutzers nach einem Passwort fest. Die Vorgabe ist 3. Falls auf 0 gesetzt, wird der Benutzer unendlich oft nach einem Passwort gefragt. Hinzugefugt in Version 186. headless= Akzeptiert ein logisches Argument, standardmassig falsch. Falls wahr, wird niemals interaktiv nach einem Passwort/einer PIN gefragt. Nutzlich fur Systeme ohne Monitor. Hinzugefugt in Version 249. verify Falls das Verschlusselungspasswort aus der Konsole ausgelesen wird, muss es zweimal eingegeben werden, um Tippfehler zu vermeiden. Hinzugefugt in Version 186. password-echo=yes|no|masked Steuert, ob Passworter oder die PINs von Sicherheits-Token bei der Eingabe auch gleich auf der Konsole wieder ausgegeben werden. Akzeptiert einen logischen Wert oder die besondere Zeichenkette >>masked<<. Die Vorgabe ist password-echo=masked. Falls aktiviert, werden die eingegebenen Zeichen 1:1 ausgegeben. Falls deaktiviert, werden die eingegebenen Zeichen in keiner Weise wieder ausgegeben, der Benutzer erhalt keine Ruckmeldung zu seiner Eingabe. Falls auf >>masked<< gesetzt, wird ein Sternchen (>>*<<) fur jedes getippte Zeichen ausgegeben. Unabhangig davon, welcher Modus ausgewahlt wird, wird die Ausgabe eingegebener Zeichen ausgeschaltet, falls der Benutzer zu irgendeinem Zeitpunkt die Tabulatortaste (>><<) oder vor der Eingabe anderer Daten die Ruckschritttaste (>><<) druckt. Hinzugefugt in Version 249. pkcs11-uri= Akzeptiert entweder den besonderen Wert >>auto<< oder eine RFC7512 PKCS#11 URI[2], die auf einen privaten RSA-Schlussel zeigt, der zum Enschlusseln des in der dritten Spalte der Zeile festgelegten verschlusselten Schlussels verwandt wird. Dies ist nutzlich, um verschlusselte Datentrager mittels PKCS#11-kompatible Sicherheits-Token oder Smartcards zu entsperren. Weiter unten finden Sie ein Beispiel, wie Sie diesen Mechanismus zum Entsperren eines LUKS2-Datentragers mit einem YubiKey-Sicherheits-Token verwenden konnen. Falls dies als >>auto<< festgelegt wurde, dann muss der Datentrager vom Typ LUKS2 sein und die PKCS#11-Sicherheits-Token-Metadaten in seinem LUKS2-JSON-Token-Abschnitt tragen. In diesem Modus werden die URI und der verschlusselte Schlussel automatisch aus dem LUKS2-JSON-Token-Datenkopf gelesen. Verwenden Sie systemd-cryptenroll(1) als einfaches Werkzeug zum Registrieren von PKCS#11-Sicherheits-Token oder -Smartcards, auf eine Art, die mit >>auto<< kompatibel ist. In diesem Modus sollte die dritte Spalte der Zeile leer bleiben (das bedeutet, als >>-<< festgelegt sein). Die festgelegte URI kann sich entweder direkt auf einen privaten, auf dem Token gespeicherten RSA-Schlussel oder alternativ nur auf ein Position oder einen Token beziehen. In letzterem Fall wird eine Suche nach einem geeigneten privaten RSA-Schlussel durchgefuhrt. Werden in diesem Fall mehrere geeignete Objekte gefunden, wird der Token abgelehnt. Der in der dritten Spalte der Zeile konfigurierte verschlusselte Schlussel wird unverandert (d.h. in binarer Form, unverarbeitet) an die RSA-Entschlusselung weitergegeben. Der daraus entstehende entschlusselte Schlussel wird dann Base64-kodiert, bevor er zum Entsperren des LUKS-Datentragers verwandt wird. Verwenden Sie systemd-cryptenroll --pkcs11-token-uri=list, um alle geeigneten, derzeit eingesteckten PKCS#11-Sicherheits-Token zusammen mit ihren URIs aufzulisten. Beachten Sie, dass viele neuere Sicherheits-Token, die auch als PKCS#11-Sicherheits-Token verwandt werden konnen, typischerweise auch das neuere und einfachere (nachfolgend beschriebene) fido2-device= implementieren, um sie stattdessen mit FIDO2 zu registrieren. Beachten Sie, dass ein mittels PKCS#11 registrierter Token nicht zum Entsperren eines Datentragers mittels FIDO2 verwandt werden kann, ausser er ist auch mittels FIDO2 registriert und umgekehrt. Hinzugefugt in Version 245. fido2-device= Akzeptiert entweder den besonderen Wert >>auto<< oder den Pfad zu einem >>hidraw<<-Gerateknoten (z.B. /dev/hidraw1), der sich auf einen FIDO2-Sicherheits-Token bezieht, der die Erweiterung >>hmac-secret<< implementiert (was die meisten aktuellen Hardware-Sicherheits-Token machen). Weiter unten finden Sie ein Beispiel, wie dieser Mechanismus eingerichtet wird, um einen verschlusselten Datentrager mit einem FIDO2-Sicherheits-Token zu entsperren. Falls dies als >>auto<< festgelegt wird, wird das FIDO2-Token-Gerat automatisch erkannt, wenn es eingesteckt wird. FIDO2-Datentragerentsperrung benotigt einen Client-Kennungs-Hash (CID), der mittels fido2-cid= (siehe unten) konfiguriert wird und einen Schlussel, der an die HMAC-Funktionalitat des Sicherheits-Tokens ubergeben werden muss (der in der dritten Spalte der Zeile konfiguriert wird), um zu funktionieren. Falls nicht konfiguriert und der Datentrager vom Typ LUKS2 ist, wird die CID und der Schlussel stattdessen von den LUKS2-JSON-Token-Metadaten gelesen. Verwenden Sie systemd-cryptenroll(1) als einfaches Werkzeug, um FIDO2-Sicherheits-Token, die zum automatischen Modus kompatibel sind, der nur fur LUKS2-Datentrager verfugbar ist, zu konfigurieren. Verwenden Sie systemd-cryptenroll --fido2-device=list, um alle geeigneten und derzeit eingesteckten FIDO2-Sicherheits-Token zusammen mit ihren Gerateknoten aufzulisten. Diese Option implementiert den folgenden Mechanismus: der konfigurierte Schlussel wird mittels der vom FIDO2-Gerat implementierten HMAC-indizierten Hash-Funktion gehasht, indiziert durch einen geheimen Schlussel, der im Gerat eingebettet ist. Der daraus entstehende Hash-Wert wird Base64-kodiert und zum entsperren des LUKS2-Datentragers verwandt. Da es nicht moglich sein darf, den geheimen Schlussel vom Hardware-Token auszulesen, sollte es nicht moglich sein, den gehashten Schlussel zu ermitteln, wenn der konfigurierte Schlussel ubergeben wird -- ohne den Hardware-Token zu besitzen. Beachten Sie, dass viele Sicherheits-Token, die FIDO2 implementieren, auch PKCS#11 implementieren, was zum Entsperren von Datentragern mit der oben beschriebenen Option pkcs11-uri= geeignet ist. Typischerweise ist der neuere, einfachere FIDO2-Standard zu bevorzugen. Hinzugefugt in Version 248. fido2-cid= Akzeptiert eine Base64-kodierte FIDO2-Client-Kennung, die fur die FIDO2-Entsperraktion verwandt werden soll. Falls festgelegt, aber nicht fido2-device=, dann wird fido2-device=auto impliziert. Falls fido2-device= verwandt wird aber nicht fido2-cid=, dann muss der Datentragertyp LUKS2 sein und die CID wird aus den LUKS2-JSON-Token-Kopfzeilen ausgelesen. Verwenden Sie systemd-cryptenroll(1) zum Registrieren von FIDO2-Token in den LUKS2-Kopfzeilen, die zu diesem Modus kompatibel sind. Hinzugefugt in Version 248. fido2-rp= Akzeptiert eine Zeichenkette, die die FIDO2-Weiterleitungs-Partei (rp) fur die FIDO2-Entsperraktion konfiguriert. Falls nicht festgelegt, wird >>io.systemd.cryptsetup<< verwandt, ausser falls die LUKS2-JSON-Token-Kopfzeilen einen anderen Wert enthalten. Normalerweise sollte es nicht notwendig sein, diesen Wert ausser Kraft zu setzen. Hinzugefugt in Version 248. tpm2-device= Akzeptiert entweder den besonderen Wert >>auto<< oder den Pfad zu einem Gerateknoten (z.B. /dev/tpmrm0), der sich auf einen TPM2-Sicherheits-Chip bezieht. Siehe weiter unten fur ein Beispiel, wie dieser Mechanismus zum Entsperren eines verschlusselten Datentragers mit einem TPM2-Chip verwandt wird. Verwenden Sie tpm2-pcrs= (siehe unten), um die Menge der TPM2-PCRs, die an die Datentrager-Entsperrung gebunden werden soll, zu konfigurieren. Verwenden Sie systemd-cryptenroll(1) als einfacheres Werkzeug zum Registrieren von TPM2-Sicherheits-Chips bei LUKS2-Datentragern. Falls als >>auto<< festgelegt, wird das TPM2-Gerat automatisch ermittelt. Verwenden Sie systemd-cryptenroll --tpm2-device=list, um alle derzeit verfugbaren geeigneten TPM2-Gerate zusammen mit ihren Gerateknoten aufzulisten. Diese Option implementiert die folgenden Mechanismen: Beim Registrieren eines TPM2-Gerates mittels systemd-cryptenroll an einem LUKS2-Datentrager wird auf dem Rechner ein zufalliger Schlussel zum Entsperren des Datentragers erstellt und in den TPM2-Chip geladen, wo er mit dem asymmetrischen >>primaren<< Schlusselpaar, das vom internen >>seed<<-Schlussel des TPMs abgeleitet ist, verschlusselt wird. Es wird sichergestellt, dass weder der Seed-Schlussel noch der primare Schlussel jemals den TPM2-Chips verlassen -- der jetzt verschlusselte zufallige Schlussel darf dies aber. Er wird in den JSON-Token-Kopfzeilen des LUKS2-Datentragers gespeichert. Beim Entsperren des verschlusselten Datentragers wird auf dem TPM2-Chip das primare Schlusselpaar erneut erstellt (was funktioniert, solange der Seed-Schlussel auf dem TPM-Chip korrekt verwaltet wird). Dieses Schlusselpaar wird dann zum Entschlusseln (auf dem TPM2-Chips) des verschlusselten Schlussel aus den JSON-Token-Kopfzeilen des LUK2-Datentragers, der dort beim Registrieren gespeichert wurde, verwandt. Der daraus entstehende entschlusselte Schlussel wird dann zum Entschlusseln des Datentragers verwandt. Wenn der zufallige Schlussel verschlusselt wird, dann werden die aktuellen Werte der ausgewahlten PCRs (siehe unten) in der Aktion eingebunden, so dass ein anderer PCR-Status zu einem anderen verschlusselten Schlussel fuhrt und der entschlusselte Schlussel nur wiederhergestellt werden kann, falls der gleiche PCR-Zustand reproduziert wird. Hinzugefugt in Version 248. tpm2-pcrs= Akzeptiert eine durch >>+<< getrennte Liste von numerischen TPM2-PCR- (d.h. >>Plattformkonfigurationsregister<<) Indices, an die die TPM2-Datentragerentsperrung gebunden werden sollen. Diese Option ist nur nutzlich, wenn die TPM2-Registrierungsmetadaten nicht bereits in den LUKS2-JSON-Token-Kopfzeilen verfugbar sind, auf die Art, wie sie systemd-cryptenroll dort hineinschreibt. Falls nicht verwandt (und keine Metadaten in den LUKS2-JSON-Token-Kopfzeilen sie definieren) ist die Vorgabe eine Liste mit einem einzigen Eintrag: PCR 7. Weisen Sie eine leere Zeichenkette zu, um eine Richtlinie festzulegen, die den Schlussel an keine PCR bindet, wodurch der Schlussel fur lokale Programme zugreifbar wird, unabhangig von dem aktuellen PCR-Status. Hinzugefugt in Version 248. tpm2-pin= Akzeptiert ein logisches Argument, standarmassig >>false<<. Steuert, ob TPM2-Datentrager-Entsperrung neben PCRs an eine PIN gebunden ist. Entsprechend ist diese Option nur nutzlich, falls die TPM2-Registrierungs-Metadaten nicht verfugbar sind. Hinzugefugt in Version 251. tpm2-signature= Akzeptiert einen absoluten Pfad zu einer TPM2-PCR-JSON-Signaturdatei, wie sie vom Werkzeug systemd-measure(1) erstellt wird. Damit konnen LUKS2-Datentrager an jeden PCR-Wert gesperrt werden, fur den eine gultige Signaturdatei bereitgestellt werden kann, die auf einen offentlichen Schlussel passt, der bei der Schlusselregistrierung angegeben wurde. Siehe systemd-cryptenroll(1) zu Details uber das Registrieren von offentlichen TPM2-PCR-Schlusseln. Falls diese Option nicht angegeben ist, aber versucht wird, einen LUKS2-Datentrager mit einer signierten TPM2-PCR-Registrierung zu entsperren, wird nach einer geeigneten Signaturdatei tpm2-pcr-signature.json in /etc/systemd/, /run/systemd/, /usr/lib/systemd/ (in dieser Reihenfolge) gesucht. Hinzugefugt in Version 252. tpm2-pcrlock= Akzeptiert einen absoluten Pfad zu einer TPM2-Pcrlock-Richtliniendatei, wie sie vom Werkzeug systemd-pcrlock(1) erstellt wird. Damit konnen LUKS2-Datentrager an eine lokale Richtlinie erlaubter PCR-Werte mit Varianten gesperrt werden. Siehe systemd-cryptenroll(1) zu Details uber das Registrieren von TPM2-Pcrlock-Richtlinien. Falls diese Option nicht angegeben ist, aber versucht wird, einen LUKS2-Datentrager mit einer TPM2-Pcrlock-Registrierung zu entsperren, wird nach einer geeigneten Datei pcrlock.json in /run/systemd/ und /var/lib/systemd/ (in dieser Reihenfolge) gesucht. Hinzugefugt in Version 255. tpm2-measure-pcr= Steuert, ob der Datentragerschlussel des verschlusselten Datentragers in ein TPM2 PCR eingemessen werden soll. Falls auf >>no<< (die Vorgabe) gesetzt, erfolgt keine PCR-Erweiterung. Falls auf >>yes<< gesetzt, wird der Datentragerschlussel in PCR 15 eingemessen. Falls auf eine dezimale Ganzahl im Bereich 023 gesetzt, wird der Datentragerschlussel in das festgelegte PCR eingemessen. Der Datentragerschlussel wird zusammen mit dem Namen des aktivierten Datentragers und seiner UUID eingemessen. Diese Funktionalitat ist insbesondere fur verschlusselte Datentrager nutzlich, die das Wurzeldateisystem unterlegen, da sie damit spateren TPM-Objekten erlaubt, sicher an das Wurzeldateisystem und damit die konkrete Installation gebunden zu werden. Hinzugefugt in Version 253. tpm2-measure-bank= Wahlt eine oder mehrere TPM2-PCR-Banke aus, in die der Datentragerschlussel eingemessen werden soll, wie oben mit tpm2-measure-pcr= konfiguriert. Es konnen mehrere Banke, getrennt durch Doppelpunkte, angegeben werden. Falls nicht angegeben, werden die verfugbaren und benutzten Banke automatisch bestimmt. Erwartet einen Nachrichten-Hash-Namen (z.B. >>sha1<<, >>sha256<<, ) als Argument, um die Bank zu identifizieren. Hinzugefugt in Version 253. token-timeout= Legt fest, wie lange maximal auf das Auftauchen des konfigurierten Sicherheitsgerates (d.h. FIDO2, PKCS#11, TPM2) gewartet werden soll. Akzeptiert einen Zeitwert in Sekunden (es durfen aber auch andere Zeiteinheiten angegeben werden, siehe systemd.time(7) fur unterstutzte Formate). Standardmassig 30s. Sobald die festgelegte Zeituberschreitung abgelaufen ist, wird die Authentifizierung uber Passwort versucht. Beachten Sie, dass die Zeituberschreitung fur das Warten auf das Auftauchen des Sicherheitsgerates gilt - sie gilt nicht fur die PIN-Eingabeaufforderung fur das Gerat (sollte eine benotigt werden) oder ahnliches. Ubergeben Sie >>0<<, um die Zeituberschreitung zu deaktivieren und beliebig lange zu warten. Hinzugefugt in Version 250. try-empty-password= Akzeptiert ein logisches Argument. Falls aktiviert, wird zuerst versucht, den Datentrager mit einem leeren Passwort zu entsperren, bevor der Benutzer nach einem Passwort gefragt wird. Dies ist fur Systeme nutzlich, die mit einem verschlusselten Datentrager initialisiert werden, bei dem nur ein leeres Passwort gesetzt ist, das dann wahrend des ersten Systemstarts aber nach der Aktivierung mit einem geeigneten Passwort ersetzt werden muss. Hinzugefugt in Version 246. x-systemd.device-timeout= Legt fest, wie lange Systemd auf das Auftauchen eines blockorientierten Gerates warten soll, bevor es bei dem Eintrag aufgibt. Das Argument ist eine Zeit in Sekunden oder in einer explizit angegebenen Einheit (>>s<<, >>min<<, >>h<<, >>ms<<). Hinzugefugt in Version 216. x-initrd.attach Richtet dieses verschlusselte Blockgerat in der Initrd ein, ahnlich zu mit x-initrd.mount markierten systemd.mount(5)-Units. Obwohl es nicht notwendig ist, den Einhangeeintrag fur das Wurzeldateisystem mit x-initrd.mount zu markieren, wird x-initrd.attach weiterhin fur verschlusselte Blockgerate empfohlen, die das Wurzeldateisystem enthalten, da Systemd andernfalls versuchen wird, das Gerat wahrend des regularen Herunterfahrens des Systems abzuhangen, wahrend es noch verwandt wird. Mit dieser Option wird das Gerat weiterhin abgehangt, aber spater, wenn das Wurzeldateisystem ausgehangt wird. Alle anderen verschlusselten Blockgerate, die in der Initrd eingehangte Dateisysteme enthalten, sollten diese Option verwenden. Hinzugefugt in Version 245. In der fruhen Systemstartphase und wenn die Konfiguration des Systemverwalters neu geladen wird, wird diese Datei durch systemd-cryptsetup-generator(8) in eine native Systemd-Unit ubersetzt. AF_UNIX-SCHLUSSELDATEIEN Falls der Schlusseldateipfad (wie in der dritten Spalte der /etc/crypttab-Eintrage festgelegt, siehe oben) sich auf ein AF_UNIX-Datenstrom-Socket in dem Dateisystem bezieht, wird der Schlussel erlangt, indem eine Verbindung zu dem Socket aufgebaut und der Schlussel aus der Verbindung gelesen wird. Die Verbindung erfolgt von einem AF_UNIX-Socket in dem abstrakten Namensraum, siehe unix(7) fur Details. Der Quell-Socket-Name wird gemass folgendem Format ausgewahlt: NUL ZUFALL /cryptsetup/ DATENTRAGER Mit anderen Worten: ein Nullbyte (NUL) (wie fur abstrakte Namensraum-Sockets benotigt), gefolgt von einer zufalligen Zeichenkette (bestehend nur aus alphanumerischen Zeichen), gefolgt von der wortlichen Zeichenkette >>cryptsetup<<, gefolgt von dem Namen des Datentragers, fur den der Schlussel erlangt werden soll. Zum Beispiel fur einen Datentrager >>myvol<<: \0d7067f78d9827418/cryptsetup/myvol Dienste, die auf dem AF_UNIX-Datenstrom-Socket auf Anfragen warten, konnen den Quell-Socket-Namen mit getpeername(2) abfragen und dieses dazu verwenden, den gesandten Schlussel zu ermitteln, wodurch ein einzelner, auf Anfragen wartender Socket Schlussel fur eine Reihe von Datentragern bereitstellen kann. Falls die PKCS#11-Logik verwandt wird (siehe oben), wird der Socket-Quellname auf ahnliche Art ermittelt, ausser dass die wortliche Zeichenkette >>cryptsetup-pkcs11<< verwandt wird. Ahnlich fur FIDO2 (>>cryptsetup-fido2<<) und TPM2 (>>cryptsetup-tpm2<<). Es wird eine andere Pfadkomponente verwandt, damit Dienste, die Schlusselmaterial bereitstellen, wissen, dass der geheime Schlussel nicht direkt erbeten wurde, sondern stattdessen ein verschlusselter Schlussel, der mittels der PKCS#11/FIDO2/TPM2-Logik entschlusselt wird, um den letztendlichen geheimen Schlussel zu erlangen. BEISPIELE Beispiel 1. /etc/crypttab-Beispiel Richtet vier verschlusselte Blockgerate ein. Eines mittels LUKS fur die normale Speicherung, ein anderes fur die Verwendung als Auslagerungsgerat und zwei TrueCrypt-Datentrager. Fur das vierte Gerat wird die Optionszeichenkette als zwei Optionen interpretiert: >>cipher=xchacha12,aes-adiantum-plain64<<, >>keyfile-timeout=10s<<. luks UUID=2505567a-9e27-4efe-a4d5-15ad146c258b swap /dev/sda7 /dev/urandom swap truecrypt /dev/sda2 /etc/container_password tcrypt hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile external /dev/sda3 keyfile:LABEL=keydev keyfile-timeout=10s,cipher=xchacha12\,aes-adiantum-plain64 Beispiel 2. Yubikey-basierte PKCS#11-Datentrager-Entsperrung Die PKCS#11-Logik erlaubt das Einbinden jedes kompatiblen Sicherheits-Tokens, der in der Lage ist, RSA-Entschlusselungsschlussel fur das Entsperren verschlusselter Datentrager zu speichern. Als Beispiel hier die Einrichtung eines Yubikey-Sicherheits-Tokens fur ein LUKS2-Datentrager zu diesem Zweck mittels ykmap(1) aus dem Yubikey-manager-Projekt, um den Token zu initialisieren und systemd-cryptenroll(1), um ihn zu dem LUKS2-Datentrager hinzuzufugen: # SPDX-License-Identifier: MIT-0 # Alle alten Schlussel auf dem Yubikey zerstoren (Vorsicht!) ykman piv reset # Erstellt ein neues Schlusselpaar (privat/offentlich) auf dem Gerat, speichert den # offentlichen Schlussel in >>pubkey.pem<<. ykman piv generate-key -a RSA2048 9d pubkey.pem # Erstellen Sie ein selbstsigniertes Zertifikat aus diesem offentlichen Schlussel und speichern Sie es auf dem # Gerat. Das >>subject<< sollte eine beliebige, vom Benutzer gewahlte Zeichenkette sein, um den Token # damit zu identifizieren. ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem # Wir brauchen den offentlichen Schlussel nicht mehr, daher wird er entfernt. Da er nicht sicherheitsrelevant # ist, fuhren wir einfach ein regulares >>rm<< hier aus. rm pubkey.pem # Registriert den frisch initialisierten Sicherheits-Token in dem LUKS2-Datentrager. # Ersetzen Sie /dev/sdXn durch die zu verwendende Partition (z.B. /dev/sda1). sudo systemd-cryptenroll --pkcs11-token-uri=auto /dev/sdXn # Testen: Fuhren Sie >>systemd-cryptsetup<< aus, um zu testen, ob alles funktioniert. sudo systemd-cryptsetup attach mytest /dev/sdXn - pkcs11-uri=auto # Falls das funktionierte, fugen Sie die gleiche Zeile fur die Zukunft dauerhaft # zu /etc/crypttab hinzu. Der (instabile) Name /dev/sdX sollte nicht verwandt # werden, daher wird ein stabiler Link ermitelt: udevadm info -q -r symlink /dev/sdXn # Fugen Sie jetzt die Zeile mittels des by-uuid-Symlinks zu /etc/crypttab # hinzu: sudo bash -c 'echo "mytest /dev/disk/by-uuid/ - pkcs11-uri=auto" >>/etc/crypttab' # Abhangig von Ihrer Distribution und Verschlusselungsinstallation, konnte es # notwendig sein, dass Sie Ihre Initramfs manuell neu erstellen mussen, um # einen Yubikey / ein PKCS#11-Token zu verwenden, um wahrend der fruhen # Systemstartphase die Partition zu entsperren. # Weitere Informationen unter https://unix.stackexchange.com/a/705809. # Auf Fedora-basierten Systemen: sudo dracut --force # Auf Debian-basierten Systemen: sudo update-initramfs -u Ein paar Hinweise zu obigem: o Wir verwenden RSA2048, das die langste, derzeit von Yubikeys unterstutzte Schlussellange ist. o Wir verwenden die Yubikey Schlussel-Position 9d, da dies offensichtlich die fur Entschlusselungszwecke zu verwendende Position ist, siehe Yubico-PIV-Zertifikatspositionen[3]. Beispiel 3. FIDO2-Datentrager-Entsperrung Die FIDO2-Logik erlaubt das Verwenden jedes kompatiblen FIDO2-Sicherheits-Tokens, der die Erweiterung >>hmac-secret<< zum Entsperren eines verschlusselten Datentragers implementiert. Als Beispiel hier die Einrichtung eines FIDO2-Sicherheits-Tokens fur ein LUKS2-Datentrager mittels systemd-cryptenroll(1) zu diesem Zweck: # SPDX-License-Identifier: MIT-0 # Registrieren des Sicherheits-Tokens am LUKS2-Datentrager. Ersetzen Sie /dev/sdXn # durch die zu verwendende Partition (z.B. /dev/sda1). sudo systemd-cryptenroll --fido2-device=auto /dev/sdXn # Testen: Fuhren Sie >>systemd-cryptsetup<< aus, um zu testen, ob alles funktioniert. sudo systemd-cryptsetup attach mytest /dev/sdXn - fido2-device=auto # Falls das funktionierte, fugen Sie die gleiche Zeile fur die Zukunft dauerhaft # zu /etc/crypttab hinzu. Der (instabile) Name /dev/sdX sollte nicht verwandt # werden, daher wird ein stabiler Link ermitelt: udevadm info -q -r symlink /dev/sdXn # Fugen Sie jetzt die Zeile mittels des by-uuid-Symlinks zu /etc/crypttab # hinzu: sudo bash -c 'echo "mytest /dev/disk/by-uuid/ - fido2-device=auto" >>/etc/crypttab' # Abhangig von Ihrer Distribution und Verschlusselungsinstallation, konnte es # notwendig sein, dass Sie Ihre Initramfs manuell neu erstellen mussen, um # ein FIDO2-Gerat zu verwenden, um wahrend der fruhen Systemstartphase die # Partition zu entsperren. # Weitere Informationen unter https://unix.stackexchange.com/a/705809. # Auf Fedora-basierten Systemen: sudo dracut --force # Auf Debian-basierten Systemen: sudo update-initramfs -u Beispiel 4. TPM2-basierte Datentrager-Entsperrung Die TPM2-Logik erlaubt die Verwendung jedes durch den Linux-Kernel unterstutzten TPM2-Chips zum Entsperren eines verschlusselten Datentragers. Es folgt ein Beispiel, wie ein TPM2-Chip fur diesen Zweck fur ein LUKS2-Datentrager mittels systemd-cryptenroll(1) eingerichtet wird: # SPDX-License-Identifier: MIT-0 # Registrieren des TPM2-Sicherheits-Chips am LUKS2-Datentrager und Anbindung an nur # PCR 7. Ersetzen Sie /dev/sdXn durch die zu verwendende Partition (z.B. /dev/sda1). sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdXn # Testen: Fuhren Sie >>systemd-cryptsetup<< aus, um zu testen, ob alles funktioniert. sudo systemd-cryptsetup attach mytest /dev/sdXn - tpm2-device=auto # Falls das funktionierte, fugen Sie die gleiche Zeile fur die Zukunft dauerhaft # zu /etc/crypttab hinzu. Der (instabile) Name /dev/sdX sollte nicht verwandt # werden, daher wird ein stabiler Link ermitelt: udevadm info -q -r symlink /dev/sdXn # Fugen Sie jetzt die Zeile mittels des by-uuid-Symlinks zu /etc/crypttab # hinzu: sudo bash -c 'echo "mytest /dev/disk/by-uuid/ - tpm2-device=auto" >>/etc/crypttab' # Prufen Sie jetzt, dass die automatische Entsperrung funktioniert: sudo systemd-cryptsetup detach mytest sudo systemctl daemon-reload sudo systemctl start cryptsetup.target systemctl is-active systemd-cryptsetup@mytest.service # Sobald das automatisch entsperrte Gerate vorliegt, kann es verwandt werden. # Normalerweise wird ein Dateisystem erstellt und zu /etc/fstab hinzugefugt: sudo mkfs.ext4 /dev/mapper/mytest # Dies gibt die >>Dateisystem-UUID<< aus, die als stabiler Name verwandt werden kann: sudo bash -c 'echo "/dev/disk/by-uuid/... /var/mytest ext4 defaults,x-systemd.mkdir 0 2" >>/etc/fstab' # Uberprufen Sie jetzt, dass das Einhangen funktioniert: sudo systemctl daemon-reload sudo systemctl start /var/mytest systemctl status /var/mytest # Abhangig von Ihrer Distribution und Verschlusselungsinstallation, konnte es # notwendig sein, dass Sie Ihre Initramfs manuell neu erstellen mussen, um # einen TPM2-Sicherheitschip zu verwenden, um wahrend der fruhen # Systemstartphase die Partition zu entsperren. # Weitere Informationen unter https://unix.stackexchange.com/a/705809. # Auf Fedora-basierten Systemen: sudo dracut --force # Auf Debian-basierten Systemen: sudo update-initramfs -u SIEHE AUCH systemd(1), systemd-cryptsetup@.service(8), systemd-cryptsetup-generator(8), systemd-cryptenroll(1), fstab(5), cryptsetup(8), mkswap(8), mke2fs(8) ANMERKUNGEN 1. Veracrypt Personal Iterations Multiplier https://www.veracrypt.fr/en/Personal%20Iterations%20Multiplier%20%28PIM%29.html 2. RFC7512 PKCS#11 URI https://tools.ietf.org/html/rfc7512 3. Yubico-PIV-Zertifikatspositionen https://developers.yubico.com/PIV/Introduction/Certificate_slots.html UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 CRYPTTAB(5)