ubuntuusers.de

LUKS verschlüsselte root Partition: Kombination von USB und remote ssh unlock

Status: Ungelöst | Ubuntu-Version: Kubuntu 22.04 (Jammy Jellyfish)
Antworten |

Mkdir0815

Anmeldungsdatum:
22. Oktober 2024

Beiträge: 8

Hallo zusammen,

ich habe meine root Partition mit LUKS verschlüsselt und nach diesem Wiki-Eintrag erolgreich einen USB-Stick zur Entschlüsselung verwendet:
Archiv/System verschlüsseln/Entschlüsseln mit einem USB-Schlüssel

Um auch die Möglichkeit zu haben, die Entschlüsselung remote über ssh vorzunehmen, bin ich dieser Wiki-Anleitung gefolgt:
Verschlüsseltes System via SSH freischalten

Hier bekomme ich aber die folgende Fehlermeldung: "Error: Timeout reached while waiting for askpass." Ich habe mittlerweile herausgefunden, dass wenn ich das keyscript aus der crypttab entferne, die Remote-Entschlüsselung wunderbar funktioniert (aber natürlich die USB-Entschlüsselung nicht mehr).

Hätte jemand einen Ansatz, wie man die beiden Verfahren kombinieren könnte?

Bearbeitet von kB:

Syntax korrigiert (Links ins Wiki)

ja

Anmeldungsdatum:
30. Juli 2022

Beiträge: 91

Hi, Ich habe meine mit dropbear ssh LUKS verschlüsselte VM nachträglich mit clevis und tang ausgerüstet. Das hat sofort funktioniert. clevis-sss kann mehr Faktoren abfragen, 2 tang-server und ein USB stick, wobei nur einer von beiden tang da sein muss oder so. clevis und dropbear geht parallel.

Mkdir0815

(Themenstarter)

Anmeldungsdatum:
22. Oktober 2024

Beiträge: 8

Danke für deine Antwort! Ich konnte bisher nur einen kurze Recherche zu deinem Vorschlag betreiben, aber es scheint mir etwas komplizierter zu sein. Aber wenn es keine anderen Ideen gibt, werde ich mich im Laufe der nächsten Woche mal einlesen. Da es sich um mein Produktivsystem handelt, will ich hier nicht ins Blaue rein testen.

ja

Anmeldungsdatum:
30. Juli 2022

Beiträge: 91

Hi, mein gefährliches Halbwissen ist nicht auf Prodsystemen im Einsatz. Fühl dich eingeladen zu Linux am Dienstag. Nach dem Programm kann man beim Stammtisch eigene Probleme vorbringen und die Jungs freuen sich auf kniffelige Aufgaben. Marius machte gerade einen Vortrag zum Thema. https://linux-am-dienstag.de/archiv/LAD-2024-LuksviaUSBentschl%C3%BCsseln.pdf Dann hab ich einen Vortrag bei den CLT 2023 gesehen. Auf den Folien Seite 20 https://chemnitzer.linux-tage.de/2023/de/programm/beitrag/133/#video

man clevis-luks-unlockers

Mkdir0815

(Themenstarter)

Anmeldungsdatum:
22. Oktober 2024

Beiträge: 8

Dein erster Link liest sich sehr interessant... Hier scheint die USB-Entschlüsselung komplett ohne Keyscript abzulaufen. Das werde ich mal testen und mich dann nochmal melden.

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

Mkdir0815

(Themenstarter)

Anmeldungsdatum:
22. Oktober 2024

Beiträge: 8

Kannst du das konkretisieren? Redest du von systematischen Fehlern oder Tippfehlern oder was ist dein Kritikpunkt? Was wäre aus deiner Sicht eine bessere Vorgehensweise?

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

fdisk wird falsch verwendet. Wenn man alle Partitionen löschen will, dann nicht mit d sondern gleich eine neue mit o. Dann wäre auch klar das es eine DOS-Partitionstabelle ist. Denn GPT würde mit den dd Befehlen erstmal kaputt geschrieben werden und umgekehrt bei Herstellung eines GPT-Backups wäre dann der Key zerstört.

Ein falscher dd Befehl steht dann sowieso dabei, da wird skip statt seek verwendet, d.h. der erste Block des Keys wird weggelassen und dann die DOS-Partitionstabelle kaputtgeschrieben. Der so erstellte Stick funktioniert dann schlichtweg gar nicht.

Dann wird fest /dev/sda als Gerätename verwendet. Daß dieser Name so bestehen bleibt, dafür gibts keine Garantie, wird also oft so gar nicht funktionieren. Da muss was anderes her, also eins von /dev/disk/by-id, partlabel, partuuid, label, uuid, - nur dafür müsste man den Key natürlich ordentlich auf eine Partition schreiben und nicht einfach irgendwie so mitten rein.

Doppelte Einträge für die gleiche LUKS-UUID in crypttab, ist mir neu, wenn das nicht irgendwo dokumentiert ist, daß man das so machen darf, wird es eher zu undefiniertem Verhalten führen.

Wenns funktioniert dann Glück gehabt, aber eigentlich ist das alles nicht korrekt so.

Mkdir0815

(Themenstarter)

Anmeldungsdatum:
22. Oktober 2024

Beiträge: 8

Danke für deine Erläuterungen. Insbesondere der Verweise auf sda hatte mich auch verwundert. Ich werde das Ganze nochmal durchdenken und dann hier mein Ergebnis posten.

Mkdir0815

(Themenstarter)

Anmeldungsdatum:
22. Oktober 2024

Beiträge: 8

Ich hab mich jetzt mal etwas länger mit dem Thema beschäftigt. Mein Problem ist aktuell folgendes: Die Optionen keyfile-timeout und nofail werden nicht erkannt. Bei einer Google-Suche habe ich nicht viel dazu gefunden. Irgendwo stand nur, dass update-initramfs eine recht alte cryptsetup Version verwendet. Ich weiß allerdings nicht, wie ich das ändern kann. Hat jemand dazu eine Idee?

frostschutz

Avatar von frostschutz

Anmeldungsdatum:
18. November 2010

Beiträge: 7790

Wenn du Ubuntu üblich initramfs-tools benutzt, kannst du dir /lib/cryptsetup/functions (crypttab_parse_options) und z.B. /usr/share/initramfs-tools/hooks/cryptroot anschauen.

Das sind die Scripte mit denen initramfs-tools arbeitet.

keyfile-timeout, nofail, sind systemd-spezifische Optionen die von den initramfs-Tools Scripten schlicht (noch?) nicht unterstützt werden.

Du könntest auf initramfs-tools verzichten und stattdessen dracut einsetzen. Da funktionieren dann die systemd-Sachen. Jedoch nicht mehr die Ubuntu-spezifischen Lösungen (keyscript, dropbear cryptroot-unlock, usw).

Für Sonderlösungen muss man sein eigenes keyscript, oder gleich einen ganz eigenen Hook schreiben. Dann eben so daß es im Initramfs (in einer busybox shell) funktioniert.

Ist leider alles etwas komplizierter als nur ein Schalter umlegen. Habe ich (speziell mit Ubuntu) selbst auch noch nicht gemacht daher keine konkrete Lösung...

Mkdir0815

(Themenstarter)

Anmeldungsdatum:
22. Oktober 2024

Beiträge: 8

Vielleicht ein kurzes Update: Ich habe das Ganze jetzt über zwei initramfs realisiert. Im Normalfall wird also das mit möglichem Remote-Unlock verwendet, optional kann man in Grub aber auf die USB-Variante umschalten. Ist vielleicht nicht die Optimallösung, funktioniert aber für mich ganz gut.

terkisch

Avatar von terkisch

Anmeldungsdatum:
31. August 2015

Beiträge: 36

wie?

Mkdir0815

(Themenstarter)

Anmeldungsdatum:
22. Oktober 2024

Beiträge: 8

So:

- /etc/crypttab mit keyscript für USB-Unlock erstellen

- sudo update-initramfs -u

- alle relevanten Dateien in /boot/ kopieren und z.B. *_USB nennen

- crypttab bearbeiten (ohne keyscript)

- sudo update-initramfs -u

- sudo update-grub

- sudo reboot

Dann lässt sich in grub über Advanced Options der USB Eintrag wählen.

Voraussetzung ist natürlich, dass remote unlock ohne keyscript funktioniert (also z.B. über dropbear umgesetzt ist).

Nachteil ist, dass die USB Variante nicht automatisch aktualisiert wird. Also der Kernel auch bei Updates unverändert bleibt. Das muss man dann halt ab und an manuell machen.

terkisch

Avatar von terkisch

Anmeldungsdatum:
31. August 2015

Beiträge: 36

Vielen Dank 👍

Antworten |