staging.inyokaproject.org

Irgendwie ist das Thema System verschlüsslen und Schlüsselableitung ein echter zeitraubender Krampf. Kaum ist ein Problem gelöst, tut sich ein neues auf. Ich benutze im Übrigen btrfs und subvolumes statt LVM auf 18.04.

Nach den jüngsten Korrekturen im Wiki ist mein Problem mit der Fehlermeldung beim Ausführen von /etc/initramfs-tools/scripts/luks/get.root_crypt.decrypt_derived erledigt. Stattdessen erhalte ich nun eine ellenlange Zeichnenfolge, welche diesselbe ist, die ich mit sudo /lib/cryptsetup/scripts/decrypt_derived root erhalte. Insofern scheint jetzt dies zumindest zu funktionieren.

Nur: Ich muss trotzdem für jede verschlüsselte Partition das Passwort beim Start eingeben. Das Spannende dabei: Bisher musste ich das nicht, wenn die Partitionen auf einer physischen Festplatte lagen. Die Schlüsselableitung schien nur dann nicht zu funktionieren, wenn die per Schlüsselableitung zu öffnende Partition auf einer anderen physischen Festplatte als die Partition lag, von welcher der Schlüssel abgeleitet werden sollte (root). Im Ergebnis klappte die Schlüsselableitung bisher für swap (auch ohne den Workaround mit /etc/initramfs-tools/scripts/luks/get.root_crypt.decrypt_derived, weil auf der gleichen physischen Festplatte wie root), und nur für die Partition auf einer anderen physischen Festplatte musste ich das Passwort händisch eingeben.

Nun habe ich zusätzlich meine root-Festplatte (HDD) mit einer SSD ausgetauscht und bin nach der Anleitung "Ubuntu umziehen" vorgegangen. Das hat alles soweit geklappt, System startet wie vorher, nur mit einem ärgerlichen Manko: Jetzt klappt nicht einmal mehr die Schlüsselableitung für eine Partition auf derselben physischen Festplatte (root und swap auf der SSD, home auf der HDD). Nun muss ich beim Start dreimal ein ellenlanges Passwort eingeben, statt zweimal.

Ich habe alle Einträge in /etc/fstab, /etc/crypttab und /etc/initramfs-tools/conf.d/cryptroot hinsichtlich UUIDs und Gerätenamen überprüft. Ich finde keinen Fehler und bin mit meinem Latein am Ende.

Wie funktioniert die Schlüsselableitung eigentlich, wenn das root-Laufwerk mehrere Schlüssel hat, also mehr als der Slot 0 befüllt ist? Welcher Slot wird abgleitet? Immer der erste, also Slot 0? Oder vielleicht der letzte? Oder welcher?

Wenn den Laufwerken, die mit der Schlüsselableitung geöffnet werden sollen ein von root abgeleiteter Schlüssel hinzugefügt werden soll (dazu muss ja bereits einer vorhanden sein), muss dieser in einen bestimmten Slot geschrieben werden, etwa in Slot 0 oder dem letzten, oder ist das egal?

Danke für die Erklärungen und Änderungen an eliro.

ubuntuuser1311161408 schrieb:

Wie funktioniert die Schlüsselableitung eigentlich, wenn das root-Laufwerk mehrere Schlüssel hat, also mehr als der Slot 0 befüllt ist? Welcher Slot wird abgleitet? Immer der erste, also Slot 0? Oder vielleicht der letzte? Oder welcher?

Gute Frage. Es muss ja von einem PW abhängen, also damit auch tatsächlich von einem Slot. Der letzte sicher nicht, da können ja jederzeit mehr hinzukommen - man kann sie sich ja alle auflisten lassen. Laut Anleitung nimmt man ja dann immer den ersten...

Auf der andren Seite funktioniert die Ableitung ja auch, wenn man ein Zweitpasswort angelegt und benutzt hat, oder? Hmm...Magie. 😈 Es müsste dann so sein, dass mit irgendeinem Schlüssel entsperrt wird und das Ableitungsscript dann erst etwas entschlüsseltes (! - mit welchem PW ist ja dann egal) aus den LUKS-Headern verwendet, um die zweite Partition abzuleiten.

Wenn man dazu die Zeit hat, könnte man sich ja mal überlegen, wie man die Veränderungen durch Ableiten mitschneiden kann, z.B. diff von zwei Imagedateien, vor und nach Ableitung...jeweils nur die Quelle betrachten. In irgendwelche LUKS-Sektoren wird dann sicherlich was reingeschrieben (, was auch entschlüsselt werden muss). So tief habe ich mir da noch gar keine Gedanken gemacht - man kann ja froh sein, wenn es läuft und man dazu nicht erst Mathe, Info oder Kryptologie studieren muss. 😉

Wenn den Laufwerken, die mit der Schlüsselableitung geöffnet werden sollen ein von root abgeleiteter Schlüssel hinzugefügt werden soll (dazu muss ja bereits einer vorhanden sein), muss dieser in einen bestimmten Slot geschrieben werden, etwa in Slot 0 oder dem letzten, oder ist das egal?

Ich denke, ohne den Inhalt vom Script genauer dazu zum Anlass zu nehmen, dass der erste freie Slot verwendet wird. So wie beim Hinzufügen weiterer PW auch. Auch das kann man sich ja wieder auflisten lassen, welche belegt sind/ werden:

sudo cryptsetup luksDump /dev/sda5   # wenn es sda5 ist

Es ist dann auch egal, wo es steht, denn es werden mit jedem eingegebenen PW (sicher auch bei Ableitung) alle belegten Slots durchprobiert, ob der Key auf einen Slot passt, ansonsten kommt eine entsprechende Fehlermeldung:

Kein Schlüssel mit dieser Passphrase verfügbar.

Grüße, Benno

Editiert zu Magie.

ubuntuuser1311161408 schrieb:

Nur: Ich muss trotzdem für jede verschlüsselte Partition das Passwort beim Start eingeben. Das Spannende dabei: Bisher musste ich das nicht, wenn die Partitionen auf einer physischen Festplatte lagen. Die Schlüsselableitung schien nur dann nicht zu funktionieren, wenn die per Schlüsselableitung zu öffnende Partition auf einer anderen physischen Festplatte als die Partition lag, von welcher der Schlüssel abgeleitet werden sollte (root). Im Ergebnis klappte die Schlüsselableitung bisher für swap (auch ohne den Workaround mit /etc/initramfs-tools/scripts/luks/get.root_crypt.decrypt_derived, weil auf der gleichen physischen Festplatte wie root), und nur für die Partition auf einer anderen physischen Festplatte musste ich das Passwort händisch eingeben.

Hierzu wollte ich nochmal eine Anmerkung machen, die vielleicht Licht in das langjährige Dunkel bringt. Bisher konnte ich die Beiträge, dass wegen einer Änderung das unrsprüngliche Ableitungsscript /lib/cryptsetup/scripts/decrypt_derived nicht mehr funktioniert nämlich nicht nachvollziehen. Denn es hat bei mir trotz der Unkenrufe immer funktioniert, solange die Partition für welche das Passwort abgeleitet werden soll und die von der es abgeleitet wird auf der gleichen physischen Festplatte lagen. Die Ableitung klappt nur für Partitionen nicht, die auf einer anderen physischen Festplatte liegen, als die von der der Schlüssel abgleitet werden soll. Für solche Fälle haben mir aber bislang auch die Workarounds nicht geholfen. (Das jetzt gar keine Ableitung mehr klappt liegt wohl an meinem jüngsten Systemumzug, was ich ehrlich gesagt auch nicht verstehe, was nun hierbei wieder passiert sein soll).

Vielleicht könnte jemand, der sich besser auskennt mal die Spur verfolgen, welchen Einfluss es auf die Schlüsselableitung hat, wie die verschlüsselten Partitionen auf physischen Festplatten verteilt sind.

ubuntuuser1311161408 schrieb:

ubuntuuser1311161408 schrieb:

Nur: Ich muss trotzdem für jede verschlüsselte Partition das Passwort beim Start eingeben. Das Spannende dabei: Bisher musste ich das nicht, wenn die Partitionen auf einer physischen Festplatte lagen. Die Schlüsselableitung schien nur dann nicht zu funktionieren, wenn die per Schlüsselableitung zu öffnende Partition auf einer anderen physischen Festplatte als die Partition lag, von welcher der Schlüssel abgeleitet werden sollte (root). Im Ergebnis klappte die Schlüsselableitung bisher für swap (auch ohne den Workaround mit /etc/initramfs-tools/scripts/luks/get.root_crypt.decrypt_derived, weil auf der gleichen physischen Festplatte wie root), und nur für die Partition auf einer anderen physischen Festplatte musste ich das Passwort händisch eingeben.

Habe das Problem (inzwischen Ubuntu 18.10) gelöst, indem ich in der crypttab bei den Partitionen deren Schlüssel abgeleitet werden, als zusätzliche Option initramfs eingetragen habe, also z.B.:

home UUID=<uuid> root luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived

Damit klappt es wie gewünscht. Das Passwort muss nur 1x eingegeben werden, und das System startet Dank Schlüsselableitung durch.

Dann hätte vermutlich statt dem Eintrag gereicht, das übliche

sudo update-initramfs -u -k all

abzusetzen?

Moin an die, die diesen Artikel pflegen oder hier beim durchackern stöbern, ich habe nach vielen Jahren mal wieder dieses Howto erfolgreich durchgespielt. Hier meine Erfahrungen/Hörensagen. Diesmal mir einer 18.04 Installation. /boot und root sind auf einer SSD, swap (und /home/$USERder-bei-der-Installation-angelegt-wird) auf einer HDD. Vorangegangene Posts in dieser Diskussion, dass das Ganze nur auf einem Device laufe kann ich für meine Konfiguration nicht bestätigen. Was mir aufgefallen ist und ggf angepasst werden könnte: Unter dem Punkt "Verschlüsselung der Partition" steht

"Anschließend wird die Swap-Partition mit einem von der Root-Partition abgeleiteten Schlüssel ^[8] erstellt und geöffnet:

1	/lib/cryptsetup/scripts/decrypt_derived root | cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 [mark]-y[/mark] /dev/sdX2

Das klappte so für mich nicht, da das -y eine wiederholte Eingabe erfragt, die das Script natürlich nicht liefert.

Mich hat irritiert, dass nach dem chroot noch ein

1

apt-get install cryptsetup

erfolgen solle. Das war bereits vorhanden. Allerdings gab es keine /etc/crypttab (bzw /mnt/etc/crypttab) sondern sie wurde erst erzeugt durch

1

echo "root UUID=<SDX3_ROOT_VOLUME_ID> none luks" >> /etc/crypttab

weswegen meine auch keine auskommentierte Kopfzeile mit "Spaltennamen" hat.

Bei "/etc/crypttab editieren" steht zu 18.04:

Insbesondere bei weiteren Volumes oder Laufwerken etwa für (/home) sollte aber in der "crypttab" (s.o.) zusätzlich die Option "initramfs" angegeben werden, da die systemd Version von crypttab offenbar die Option "keyscript" nicht versteht

Hier wären eine Beispiel-crypttab wie darüber bzgl "discard" hilfreich. Was hier "Insbesondere" bedeutet wurde mir auch nicht klar. Die swap hat ohne "initramfs" Option nicht funktioniert, an root habe ich sie vorsichtshalber auch gesetzt, hatte aber keine Zeit mehr zu testen, ob das nötig ist. Es funktioniert, aber dmesg gibt einen Error:

/run/systemd/generator/systemd-cryptsetup@swap.service:12: Failed to add required mount "root", ignoring: Invalid argument

(und dito für den $USERder-bei-der-Installation-angelegt-wird)

In Zukunft, bzw für Testende von Versionen >18.04 oder Artikel Pflegende, ist ggf relevant, dass ab 18.10 das auch schon für 18.04 gegebene LUKS2 nicht mehr als default LUKS1 Verschlüsselung verwendet und GRUB mit LUKS2 Verschlüsselung Probleme hat. Daher muss dann noch die Option "--type=luks1" verwendet werden, zumindest für root.

Was vielleicht noch relevant ist oder auch nicht, gilt das ganze sowohl für BIOS als auch EFI Installationen und sowohl für MBR als auch GPT konfigurierte Devices?

Zu guter Letzt: Ich passe auch vor einem finalen

1

initramfs -u -k all

die /etc/fstab an und ersetze dort alle /dev/sdX und dev/mapper/X Eintäge mit den korrekten UUIDs. Das erscheint mir sicherer, da sich die Nomenklatur von /dev/wasauchimmer schnell mal ändern kann durch USB-Sticks oder BIOS-Settings. UUIDs sind schön eindeutig. für alles, was man ableiten will sollte man eine im Hirn vorhandene Passphrase anlegen. Das hilft selbst bei der swap, wenn was schief läuft, aber beim booten danach gefragt wird. Auf wichtiges, z.B. /home kann man so immer noch zugreifen, selbst wenn es einem root, womöglich auf einem anderen Device zerschießt.

Hier noch eine Quelle https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019