Verwenden einer einzelnen Passphrase zum Entsperren mehrerer verschlüsselter Festplatten beim Start

Mein Computer verfügt über eine SSD, auf der ich das System installiert habe, und eine Festplatte, die ich als Speicher für große und / oder selten verwendete Dateien verwende. Beide sind verschlüsselt, aber ich habe die gleiche Passphrase für sie verwendet. SSD wird unter /und HDD unter gemountet /usr/hdd(einzelne Benutzer haben jeweils ein Verzeichnis und können Symlinks vom Basisverzeichnis aus erstellen, wie sie möchten).

Wenn das System gestartet wird, werden Sie sofort nach der Passphrase für die SSD gefragt und wenige Sekunden später nach der Passphrase für die Festplatte (diese wird automatisch eingehängt). Gibt es eine Möglichkeit, das System so zu konfigurieren, dass es nur einmal fragt, da beide Passphrasen gleich sind?

Debian-basierte Distributionen:

Debian und Ubuntu liefern ein Passwort-Caching-Skript decrypt_keyctl mit dem Paket cryptsetup aus .

Das Skript decrypt_keyctl stellt mehreren verschlüsselten LUKS-Zielen dasselbe Kennwort zur Verfügung, sodass Sie es nicht mehrmals eingeben müssen. Es kann mit der Option in crypttab aktiviert werden keyscript=decrypt_keyctl. Das gleiche Passwort wird für Ziele verwendet, die im Schlüsseldateifeld die gleiche Kennung haben . Beim Booten wird das Passwort für jede Kennung einmal abgefragt.

Ein Beispiel für ein Crypttab :

<target>      <source>         <keyfile>      <options>
part1_crypt   /dev/disk/...    crypt_disks    luks,keyscript=decrypt_keyctl
part2_crypt   /dev/disk/...    crypt_disks    luks,keyscript=decrypt_keyctl

Nachdem Sie Ihr Cryptab aktualisiert haben , müssen Sie auch initramfs aktualisieren, um die Änderungen zu übernehmen. Verwenden Sie update-initramfs -u.

Die vollständige Readme-Datei für decrypt_keyctl befindet sich in /usr/share/doc/cryptsetup/README.keyctl

Leider funktioniert dies derzeit auf Debian-Systemen mit systemd init aufgrund eines Fehlers nicht (andere init-Systeme sollten nicht betroffen sein). Die Debian crypttab-Manpage schlägt als Workaround vor, die initramfsOption zu verwenden, um die Verarbeitung in der initramfs-Boot-Phase zu erzwingen.

Distributionen, die kein decrypt_keyctl- Skript bereitstellen :

Wenn decrypt_keyctrl nicht von Ihrer Distribution bereitgestellt wird, kann das Gerät mithilfe einer Schlüsseldatei im verschlüsselten Root-Dateisystem entsperrt werden. Dies ist der Fall, wenn das Root-Dateisystem vor allen anderen verschlüsselten Geräten entsperrt und eingehängt werden kann.

LUKS unterstützt mehrere Schlüsselslots. Auf diese Weise können Sie das Gerät alternativ mit einem Kennwort entsperren, wenn die Schlüsseldatei nicht verfügbar / verloren ist.

1. Generieren Sie den Schlüssel mit zufälligen Daten und setzen Sie seine Berechtigungen auf besitzerlesbar, um ein Auslaufen zu vermeiden. Beachten Sie, dass sich die Schlüsseldatei auf der Root-Partition befinden muss, die zuerst entsperrt wird.

   dd if=/dev/urandom of=<path to key file> bs=1024 count=1
   chmod u=rw,g=,o= <path to key file>
   

2. Fügen Sie den Schlüssel Ihrem LUKS-Gerät hinzu

   cryptsetup luksAddKey <path to encrypted device> <path to key file>
   

3. Konfigurieren Sie crypttab für die Verwendung der Schlüsseldatei. Die erste Zeile sollte das Root-Gerät sein, da die Geräte in derselben Reihenfolge entsperrt werden, wie sie in crypttab aufgeführt sind . Verwenden Sie absolute Pfade für Schlüsseldateien.

   <target>      <source>         <keyfile>                  <options>
   root_crypt    /dev/disk/...    none                       luks
   part1_crypt   /dev/disk/...    <path to key file>         luks
   

Hier ist meine Problemumgehung für Debian angesichts des Fehlers, auf den @sebasth oben verwiesen hat.

Mein Setup ist etwas anders. Ich habe eine verschlüsselte Root-Partition und eine Reihe von RAID-Festplatten. Für mich musste ich dem crypttab eine initramfs-Option hinzufügen:

<target>      <source>         <keyfile>      <options>
part1_crypt   /dev/disk/...    crypt_disks    plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs
part2_crypt   /dev/disk/...    crypt_disks    plain,cipher=aes-xts-plain64,keyscript=decrypt_keyctl,initramfs

Dies teilt update-initramfs mit, dass ich diese Crypttab-Einträge in das initramfs einbinden möchte. Ich habe mein Crypttab überprüft, indem ich ausgeführt habe

cryptdisks_start part1_crypt
cryptdisks_start part2_crypt

Beachten Sie, dass meine RAID-Festplatten reine DM-Krypta sind. Dies bedeutete, dass ich die luks keyfile-Methode nicht verwenden konnte, die den systemd keyscript-Fehler umgeht. Für reine dm-Krypta müsste ich die Passphrase im Klartext speichern.

Die verschlüsselten Festplatten müssen eingehängt werden, bevor sie update-initramfsausgeführt werden. Andernfalls werden Fehler ausgegeben. Ich musste nach den folgenden Zeilen suchen, als mein initramfs erstellt wurde:

update-initramfs -k -u -v | grep 'keyctl'

das zeigte die folgenden zwei Dateien:

/bin/keyctl
cryptkeyctl

wird zu den initramfs hinzugefügt.

Schließlich musste ich die Behandlung meines crypttab durch systemd deaktivieren, um den oben genannten Fehler zu beheben: systemd unterstützt die Option keyscript in crypttab nicht. Zu diesem Zweck habe ich die Kernel-Option hinzugefügt

GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"     

nach / etc / default / grub und lief update-grub. systemd ignoriert jetzt crypttab und alle verschlüsselten Partitionen werden in das initramfs geladen.

Da ich eine verschlüsselte Root-Partition habe, scheint Cryptroot meinen Schlüssel nicht zwischenzuspeichern. Dies bedeutet, dass ich mein Passwort zweimal eingeben muss. eine für die Root-Partition und eine für mein RAID-Array.

Eine andere Möglichkeit ist die Verwendung des /lib/cryptsetup/scripts/decrypt_derivedSkripts, das auch Teil von cryptsetup in Debian / Ubuntu ist.

Anstatt den Schlüssel zwischenzuspeichern, verwenden Sie den Datenträgerschlüssel eines Datenträgers als zusätzliches Kennwort für den zweiten Datenträger. Dies erfordert das Hinzufügen eines zweiten Kennworts zur zweiten (und dritten usw.) verschlüsselten Festplatte, aber LUKS unterstützt dies. Diese Lösung funktioniert daher auch, wenn Ihre mehreren verschlüsselten Festplatten nicht dasselbe Kennwort verwenden.

Beispiel zum Hinzufügen des Schlüssels von sda6crypt zu sda5:

Füge den Volume-Schlüssel von sda6crypt als zusätzliches Passwort für sda5 hinzu:

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

Konfigurieren Sie sda5crypt so, dass es automatisch in entsperrt wird /etc/crypttab

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

Hierbei wird ein Named Pipe ( fifo) zum Übergeben des Schlüssels verwendet, um zu vermeiden, dass der Datenträgerschlüssel in einer temporären Datei auf der Festplatte gespeichert werden muss.

Die keyscriptOption funktioniert nur, wenn sie crypttabvon Debians ursprünglichen Cryptsetup-Tools verarbeitet wird. Die systemd-Neuimplementierung unterstützt sie derzeit nicht. Wenn Ihr System systemd verwendet (das sind die meisten Systeme), müssen Sie die initramfsOption aktivieren, dass die Verarbeitung in initrd von den Cryptsetup-Tools erzwungen wird, bevor systemd gestartet wird.

Basierend auf /unix//a/32551/50793