it-swarm.com.de

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

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 mich dafür entschieden, dieselbe Passphrase für sie zu verwenden. Die SSD wird unter / Und die Festplatte unter /usr/hdd Eingehängt (einzelne Benutzer haben jeweils ein Verzeichnis und können vom Home-Verzeichnis aus nach Belieben einen Symlink erstellen).

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

24
doublep

Debian-basierte Distributionen:

Debian und Ubuntu liefern ein Passwort-Caching-Skript decrypt_keyctl 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 mit der Option keyscript=decrypt_keyctl Aktiviert werden. Das gleiche Passwort wird für Ziele verwendet, die die gleiche Kennung in 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

Das Skript decrypt_keyctl Hängt vom Paket keyutils ab (das nur vorgeschlagen und daher nicht unbedingt installiert wird).

Nachdem Sie Ihre 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 von ein Fehler (andere init-Systeme) nicht sollte nicht betroffen sein). Debian crypttab man page schlägt als Problemumgehung vor, die Option initramfs zu verwenden, um die Verarbeitung in der Startphase von initramfs 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 bereitgestellt werden kann.

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

  1. Generieren Sie den Schlüssel mit zufälligen Daten und setzen Sie seine Berechtigungen auf vom Eigentümer lesbar, 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, 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 in crypttab aufgeführt. 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
    
25
sebasth

Eine andere Option ist die Verwendung von /lib/cryptsetup/scripts/decrypt_derived script, das auch Teil von cryptsetup in Debian/Ubuntu ist.

Anstatt den Schlüssel zwischenzuspeichern, verwenden Sie den Volume-Schlüssel einer Festplatte als zusätzliches Kennwort für die zweite Festplatte. 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ügen Sie 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 in /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

Dabei wird eine Named Pipe (fifo) verwendet, um den Schlüssel zu übergeben, damit der Volume-Schlüssel nicht in einer temporären Datei auf der Festplatte gespeichert werden muss.

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

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

2
JanKanis

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 der 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 diese crypttab-Einträge in den initramfs bereitgestellt werden sollen. Ich habe mein Crypttab durch Ausführen überprüft

cryptdisks_start part1_crypt
cryptdisks_start part2_crypt

Beachten Sie, dass meine RAID-Festplatten einfache DM-Krypta sind. Dies bedeutete, dass ich die luks-Schlüsseldateimethode, die den systemd-Keyscript-Fehler umgeht, nicht verwenden konnte. Für eine einfache dm-Krypta müsste ich die Passphrase im Klartext speichern.

Die verschlüsselten Festplatten müssen bereitgestellt werden, bevor update-initramfs Ausgeführt wird. Andernfalls werden Fehler ausgegeben. Ich musste nach den folgenden Zeilen suchen, als mein initramfs erstellt wurde:

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

welches die folgenden zwei Dateien zeigte:

/bin/keyctl
cryptkeyctl

wird zu den initramfs hinzugefügt.

Schließlich musste ich systemd deaktivieren, das mein Crypttab behandelt, 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"     

zu/etc/default/grub und lief update-grub. systemd ignoriert jetzt crypttab und alle verschlüsselten Partitionen werden in die 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 einmal für mein RAID-Array.

2
user128063