staging.inyokaproject.org

Hallo,

ich habe gestern ein Update auf die Version 15.04 durchgeführt. Danach tritt folgendes Problem auf:

Ich verwende zwei Festplatten mit dm-crypt verschlüsselt.

Die erste Platte wird ganz normal per Passwort entschlüsselt. Danach werde ich neuerdings nach einem Passwort für die zweite Platte gefragt. Diese bekommt ihren Schlüssel aber per keyscript (/lib/cryptsetup/scripts/decrypt_derived) von der ersten Platte.

Kann mir jemand einen Tipp geben, wie ich die Platte wieder öffnen kann?

Willkommen!

Wie sieht deine crypttab aus? keyscript war nach Upgrade noch unverändert drin?

Ja, das Script ist noch in der cryptab drin. Die ist unverändert.

Hallo, ich bestätige das Problem hiermit. Nach dem Update auf Vivid funktioniert die Schlüsselableitung per script nicht mehr automatisch.

Manuelle Einbindung mit folgendem Befehl ist weiterhin möglich (bei entsprechendem Eintrag in /etc/crypttab der noch vor dem Update erstellt wurde):

/lib/cryptsetup/scripts/decrypt_derived luks_root_device | cryptsetup luksOpen /dev/sdX1 Test_HDD

Das Script für die Schlüsselableitung funktioniert also noch. Ebenso der Eintrag in der Crypttab.

Weiß irgendjemand mehr?

Bin inzwischen ein wenig weiter: der Fehler scheint sich in der Umstellung zu systemd eingeschlichen zu haben

Zum einbinden der Platte gibt es den Service mit Namen systemd-cryptsetup@Test_HDD.service

In diesem wird folgender Start-Befehl ausgeführt (Private Daten habe ich mal durch x ersetzt)

/lib/systemd/systemd-cryptsetup attach Test_HDD /dev/disk/by-uuid/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx luks_root_device luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived,noauto

Dieser Befehl liefert folgenden Fehler:

Password file path 'luks_root_device' is not absolute. Ignoring.
Encountered unknown /etc/crypttab option 'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.

Das heißt, das Script (automatisch erstellt) passt nicht zum Programm, das aufgerufen wird.

http://lists.freedesktop.org/archives/systemd-devel/2014-July/021418.html und https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862

keyscript= parameter funktioniert nicht mit systemd (Ubuntu 15.04) :/

Ich hatte gerade gestern genau das gleiche Problem bei einer Neuinstallation von 15.4. Ich bin der Anleitung aus dem Wiki gefolgt und bin auf die gleichen Fehler gestoßen.

Die Lösung bei mir war, alle Partitionen ganz normal mit dem gleichen Passwort zu verschlüsseln (also ohne Keyscript). Meine crypttab sieht danach so aus:

# /dev/sda3 -> /:
root UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none luks

# dev/sdb1 -> /opt:
opt  UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx root luks

# /dev/sda2 -> swap:
swap UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx root luks

Beim Start werde ich auch nur einmal für / nach dem Passwort gefragt und alles weitere geht automatisch. Anscheinend nutzt systemd das Passwort hinter den Kulissen auch automatisch für die anderen Partitionen.

Ich habe aber keine Möglichkeit gefunden, dass nachträglich zu ändern bzw irgendwie abgeleitete Schlüssel zu verwenden. Für meine Methode muss man wohl oder übel die abgeleiteten Partitionen mit dem gleichen Passwort wie / neu verschlüsseln (Achtung, die Daten gehen verloren und das ändert auch die UUIDs in der crypttab).

Muss man nicht, es geht einfach mit luksAddKey o.ä. - sollte man sowieso machen und die Passwörter mehrfach je Laufwerk anlegen, falls ausgerechnet der Sektor mit den Entschlüsselungsinformationen stirbt.

Ah, interessant und gut zu wissen. Ich bin davon ausgegangen, dass da bei den derived-Geschichten irgendeine Magie am Werk ist, wodurch die normale Schlüsselverwaltung obsolet wird.

Also, wie aus den Links von tehownt oben zu entnehmen ist, funktionieren die keyscripts mit systemd nicht mehr und es ist wohl auch nicht geplant, an diesem Umstand etwas zu ändern.

Auf folgender Seite hat sich noch jemand Gedanken gemacht, wie das Keyscript zum entschlüsseln mittels Block-Device ersetzt werden kann.

https://wiki.debianforum.de/Cryptsetup_mit_systemd_und_Schl%C3%BCssel_auf_externem_USB-Stick

Das decrypt-derived-Script ist aber derzeit wohl nicht vernünftig zu ersetzen.

Der übliche Workaround ist wohl, auf eine Schlüsseldatei zurückzugreifen, die sich auf der primären verschlüsselten Partition und nur für Root lesbar befindet.

Über Vor- und Nachteile wurde sich schon ausgiebig gestritten, aber es ist wohl im Moment der einzige mögliche Weg.

Warum überhaupt der ganze Aufwand mit der Ableitung und den Scripten?

Einfach alle Partitionen mit dem gleichen Passwort versehen (auch nachträglich mit luksAddKey) und fertig. Oder wo liegt da mein Denkfehler?

Zum Beispiel für Anwendungen ohne Passwort.

- USB-Stick

- Smartcard

- Yubikey

Das Problem ist, dass du mit Passwörtern nie den zur Verfügung stehenden 256-Bit Schlüsselraum ausnutzen kannst, weshalb es sinnvoll ist, den irgendwo sicher zu speichern.

Mit dem decrypt-derived-Script hat man den Schlüssel nie unverschlüsselt auf irgendeinem Blockdevice liegen, sondern höchstens im RAM.

Außerdem ist es selten eine gute Idee, ein und dasselbe Passwort für verschiedene Zwecke zu verwenden.

Es wäre natürlich schön, wenn das mittelfristig auch wieder mit externen Schüsseln gehen würde.

Aber das hat mit dem vorliegenden Problem ja nur indirekt zu tun. Hier wird der Schlüssel schon per Hand eingegeben. Das Ableiten von einer Partition zu einer anderen auf dem gleichen Rechner sehe ich hier eher als großen Nachteil und nicht als Sicherheitsgewinn. Wer so tief im System drinnen ist, dass er den ganzen Speicher nach Passwörtern abgrasen kann, kann auch Tastatureingaben mitlesen. Ausserdem schafft es einen großen Single-Point-Of-Failure (siehe vorliegenden Fall).

Nun, ich finde es schön, wenn deine Probleme gelöst sind.

Nur geht es hier ursächlich darum, dass nach dem Update auf Ubuntu 15.04 die keyscripts nicht mehr funktionieren. Das hat unter anderem auch zur Folge, dass mehrere Anleitungen aus dem Wiki hier nicht mehr auf die neueste Version von Ubuntu anwendbar sind.