[Aufgegeben] Stretch und automatische Entschlüsselung

[rhHeini]

Habe einen Rechner mit verschlüsseltem LVM unter Stretch amd64, die automatische Entschlüsselung funzt einwandfrei. Verfahren wie in diesem Thread viewtopic.php?f=37&t=164245 mühsam erarbeitet.

Habe eine zweite verschlüsselte Platte dazugehängt und will die nach dem gleichen Verfahren entschlüsseln, systemd fragt aber immer 3 x nach einem Schlüssel, statt die luks-Partition in /dev/mapper einzuhängen. Habe alle Einträge und Skripts mehrfach kontrolliert, finde keinen Fehler. Habe auch den Key neu geholt, mit dem alten verglichen und neu auf das luks-Device geschrieben, alles scheint zu passen, keine Änderung im Verhalten.

Dann habe ich den Rechner hochgefahren und versucht das Device mit einer Pipe-Konstruktion aus der root-Konsole zu öffnen und scheitere ebenfalls. Jetzt ist die Frage ob meine Pipe falsch ist oder ob ich über einen Bug stolpere. Hier erst mal das Kommando das ich verwende:

Code: Alles auswählen

dd if=/dev/disk/by-id/xxx bs=512 skip=someblocks count=8 | cryptsetup luksOpen /dev/sda1 bigdrive_crypt

Es kommt die Meldung:

Code: Alles auswählen

8+0 Datensätze ein
8+0 Datensätze aus
4096 Bytes (4,1 kB, 4,0 KiB) kopiert, 0,00275829 s, 1,5 MB/s
Kein Schlüssel mit dieser Passphrase verfügbar.
Kein Schlüssel mit dieser Passphrase verfügbar.
Kein Schlüssel mit dieser Passphrase verfügbar.

Sieht für mich so aus als ob der Keyfile nicht passt. Ist das Kommando so ok?

Zweite Möglichkeit: ich hatte unter Jessie mal das Problem das ein Keyfile mit dem 4.9er Kernel geschrieben auch nicht funzte, der mit dem 3.16er geschriebene ging. Kann es sein das ich in die gleiche Falle mit Stretch tappe?

Danke, Rolf

[spiralnebelverdreher]

Verstehe ich deinen Ansatz recht, dass du cryptsetup einen keyfile vorsetzen willst, der aus den ersten 4096 Byte deiner Platte mit der UUID xxx bestehen? Da du keine key-size u.ä. angibst und keine wirksame Kontrolle über diese Datensätze hast, können darin auch alle möglichen Zeichenfolgen (EOL, EOF, ...) auftauchen. Und bist du sicher, dass sich diese Daten nie ändern? In einer Multiboot-Umgebung ist das nicht sicher gestellt, manche Programme (früher war Photoshop dafür bekannt) schreiben gerne in diesen "ungenutzten" Bereich proprietäre Information. Oder Änderungen an der Partitionstabelle ändern den MBR.

Warum erzeugst du nicht einfach einem String aus Zufallswerten, speicherst diesen in eine Datei und verwendest diese als keyfile?

[rhHeini]

@Spiralnebelverdreher: Danke für Dein Feedback, mein Ansatz ist einer der möglichen, den Sinn/Unsinn möchte ich hier aber nicht mehr diskutieren. Das hat schon im Frühjahr stattgefunden.

Habe inzwischen die Platte mal an ein Wheezy gehängt und dort den Key neu geschrieben, hat nicht geholfen.

Ideen willkommen....

Gruss, Rolf

[spiralnebelverdreher]

Es wird halt am Key liegen, den dir das dd Kommando über die Pipe zu cryptsetup schaufelt.
Probier doch mal, ob die Key-Länge explizit angegeben, etwas bewirkt. Oder schreib das Ergebnis von dd probeweise in eine Datei und übergebe diese an cryptsetup.

[rhHeini]

Auf der Kommandozeile kriege ich den Container mit dem mit dd geschriebenen Key mit der Option --key-file= entschlüsselt.

Also ist der Key richtig auf das Device geschrieben worden.

Möglicherweise hat sich zwischen Jessie und Stretch was an der Syntax geändert, die Meldung könnte daher kommen das da was nicht stimmt. Entnehme ich jedenfalls der manpage zu cryptsetup. Komischerweise geht die OS-SSD zuverlässig mit dem Originalscript auf, und das zweite Device will nicht.

Jetzt muss ich mal etwas grübeln was das sein könnte.

Gruss, Rolf

[rhHeini]

Verstehe ich deinen Ansatz recht, dass du cryptsetup einen keyfile vorsetzen willst, der aus den ersten 4096 Byte deiner Platte mit der UUID xxx bestehen?

Nein, diese ersten 4096 Byte werden nicht angefasst, ich setze später auf. Da sind Random-Daten drauf geschrieben.

Gruss, Rolf

[spiralnebelverdreher]

Auf der Kommandozeile kriege ich den Container mit dem mit dd geschriebenen Key mit der Option --key-file= entschlüsselt.

Also ist der Key richtig auf das Device geschrieben worden.

Möglicherweise hat sich zwischen Jessie und Stretch was an der Syntax geändert, die Meldung könnte daher kommen das da was nicht stimmt. Entnehme ich jedenfalls der manpage zu cryptsetup. Komischerweise geht die OS-SSD zuverlässig mit dem Originalscript auf, und das zweite Device will nicht.

Jetzt muss ich mal etwas grübeln was das sein könnte.

Verwendest du bei den beiden devices den gleichen Schlüssel ?
Wenn ich mir cryptsetup anschaue bei händischen Bedienung, dann ist die Passworteingabe mit dem RETURN beendet. Was passiert bei der Pipe? Du schaufelst da massig Bytes hin, die alles mögliche enthalten können. Bei einem keyfile ebenfalls, aber da ist die Anzahl der Zeichen vorgegeben durch die Dateigröße.

[rhHeini]

Die Schlüssel sind unterschiedlich. Habe aber einfach mal probiert den Schlüssel von der OS-SSD auf die Datenplatte zu schreiben, hat auch nicht geholfen, ebensowenig ein anderer Bereich als Schlüssel, und der 4.13er Kernel aus den Backports.

Gibt es für die Pipe noch einen Trick17? Ich habe da auch probiert die Option --keyfile-size=xxxx bytes zu verwenden, hat nichts geholfen.

Die Pipe war nichts weiter als der Versuch im root-Terminal einfach die Kommandos zu verkoppeln, die beim Boot auch ablaufen sollten, um die Zeit für eine Reboot zu sparen. Habe da die ganz alte Methode mit einem cat des Keyfiles sowie das Lesen des Schlüssels per dd vom Device ausprobiert. Hat nichts gebracht ausser Frust.

Die SSD wird mit identischem Verfahren einwandfrei entschlüsselt, bei der Datenplatte (Einträge und Skripte kopiert, angepasst, x mal kontrolliert...) fällt das System immer zurück auf die Passwortabfrage. Kann das ein Bug sein?

Gruss, Rolf

[rhHeini]

Jetzt hab ich auch noch auf einem zweiten Rechner probiert ein 2tes Device unter Stretch automatisch zu entschlüsseln, geht nicht.

Muss ein Bug sein.

Gruss, Rolf

[spiralnebelverdreher]

Deine Fragestellung/Problem geht weit über meine Kenntnisse hinaus; ich kann da auch nur ins Blaue orakeln:

Du schaufelst mittels dd 4096 Bytes rüber zu cryptsetup; in meiner Stretch Installation sagt cryptstetup --help zu der maximalen Schlüssellänge:

Code: Alles auswählen

Vorgabewerte für Schlüssel und Passphrasen:
	Maximale Größe der Schlüsseldatei: 8192kB, Maximale Länge der interaktiven Passphrase: 512 Zeichen 

Wie ist das bei dir? Schon mal dd mit count=1 probiert?

Ob das Verhalten in deiner Installation ein Bug ist, oder nicht (Bug in cryptsteup oder Bug in bash??) kann ich nicht beurteilen. Wenn du meinst, dass es ein Bug ist solltest du auch einen Bugreport schreiben. Kurzfristig hilft dir das aber nicht weiter, da ist ein anderes Vorgehen mit einem keyfile der Ausweg. Das muss ja keine Datei sein, die mein_geheimer_keyfile.txt heißt, sonder kann auch eine x-beliebige unverdächtige jpg Datei sein.

[rhHeini]

Die Schlüssel sind definitiv nicht zu lang, weder das initiale Passwort noch das Keyfile.

Auch unter Jessie geht das ganze nicht.

Mfg Rolf