Verwenden einer einzigen Passphrase zum Entsperren mehrerer verschlüsselter Festplatten beim Booten

Debian-basierte Distributionen:

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

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

Ein Beispiel 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

Die decrypt_keyctl script hängt von keyutils ab Paket (das nur vorgeschlagen und daher nicht unbedingt installiert wird).

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 nicht auf Debian-Systemen, die systemd init verwenden, aufgrund eines Fehlers (andere Init-Systeme sollten nicht betroffen sein). Mit diesem Fehler werden Sie ein zweites Mal von systemd nach dem Passwort gefragt, was es unmöglich macht, es per ssh aus der Ferne zu entsperren. Debian crypttab-Manpage schlägt als Problemumgehung vor, initramfs zu verwenden Option zum Erzwingen der Verarbeitung in der initramfs-Phase des Bootens. Um diesen Fehler zu umgehen, ein Beispiel für /etc/crypttab in Debian

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

Distributionen, die decrypt_keyctl nicht bereitstellen Skript:

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

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

1. Generieren Sie den Schlüssel mit zufälligen Daten und legen Sie seine Berechtigungen nur für den Besitzer lesbar fest, um ein Durchsickern 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 zu Ihrem LUKS-Gerät hinzu

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

3. Konfigurieren Sie crypttab um die Schlüsseldatei zu verwenden. Die erste Zeile sollte das Root-Gerät sein, da die Geräte in derselben Reihenfolge entsperrt werden, wie sie in crypttab aufgelistet ist . 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
   

Eine weitere Möglichkeit ist die Verwendung des /lib/cryptsetup/scripts/decrypt_derived -Skript, das auch Teil von cryptsetup in Debian/Ubuntu ist.

Anstatt den Schlüssel zwischenzuspeichern, verwenden Sie den Lautstärkeschlüssel einer Festplatte als zusätzliches Kennwort für die zweite Festplatte. Dies erfordert das Hinzufügen eines zweiten Passworts zur zweiten (und dritten usw.) verschlüsselten Festplatte, aber LUKS unterstützt dies. Diese Lösung funktioniert daher auch, wenn Ihre mehreren verschlüsselten Laufwerke nicht dasselbe Passwort verwenden.

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

Volume Key von sda6crypt als zusätzliches Passwort für sda5 hinzufügen:

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

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

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

Dies verwendet eine benannte Pipe (fifo ), um den Schlüssel zu übergeben, um zu vermeiden, dass der Lautstärkeschlüssel in einer temporären Datei auf der Festplatte gespeichert werden muss.

Die keyscript Option funktioniert nur, wenn crypttab von Debians ursprünglichen cryptsetup-Tools verarbeitet wird, unterstützt die systemd-Neuimplementierung dies derzeit nicht. Wenn Ihr System systemd verwendet (was die meisten Systeme sind), benötigen Sie den initramfs Option, um die Verarbeitung in der initrd durch die cryptsetup-Tools zu erzwingen, bevor systemd startet.

Basierend auf https://unix.stackexchange.com/a/32551/50793

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

Mein Setup ist etwas anders. Ich habe eine verschlüsselte Root-Partition und eine Reihe von RAID-Festplatten. Für mich musste ich dem Cryptab 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 im initramfs gemountet haben 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 einfache dm-crypt sind. Dies bedeutete, dass ich die Luks-Keyfile-Methode nicht verwenden konnte, die den Systemd-Keyscript-Fehler umgeht. Für einfaches dm-crypt müsste ich die Passphrase im Klartext speichern.

Das Paket keyutils muss installiert sein und die verschlüsselten Laufwerke müssen vor update-initramfs gemountet werden es läuft; Andernfalls werden Fehler ausgegeben. Ich musste nach den folgenden Zeilen suchen, als mein initramfs gebaut wurde:

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

die die folgenden zwei Dateien zeigte:

/bin/keyctl
cryptkeyctl

wird zum initramfs hinzugefügt.

Schließlich musste ich Systemd deaktivieren, das mein Cryptab verarbeitet, um den oben genannten Fehler zu beheben:Systemd unterstützt die Keyscript-Option in Crypttab nicht. Dafür habe ich die Kernel-Option

hinzugefügt

GRUB_CMDLINE_LINUX_DEFAULT="quiet luks.crypttab=no"     

nach /etc/default/grub und führte update-grub aus . 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. Das bedeutet, dass ich mein Passwort zweimal eingeben muss; eine für die Root-Partition und eine für mein Raid-Array.