staging.inyokaproject.org

crazy-biscuit schrieb:

EDIT: Derived Key funktioniert nur wenn man sich bei der Anmeldung automatisch einloggen möchte mit crypttab und fstab.

Mit Neffen mein Lieber:

/lib/cryptsetup/scripts/decrypt_derived <Name_des_Ursprungsgeräts> | cryptsetup luksOpen <Gerät> <Name> 

funktioniert auf der Kommandozeile tadellos.

Okay das wusste ich tatsächlich nicht. Was ist denn der Vorteil einer Ableitung? Ich kann doch auch ein beliebiges File nutzen bzw. erstellen und das verwenden,indem ich es als Schlüssel hinzufüge....

crazy-biscuit schrieb:

Was ist denn der Vorteil einer Ableitung?

Gibt sicher andere/bessere Lösungen aber die Schlüsselableitung hat sich eben irgendwie [zumindest bei Ubuntu] durchgesetzt. Wahrscheinlich war sie [hier] zuerst da.

Heute kommt man ggf. ohne aus, allen LUKS Containern die gleiche Passphrase und zumindest Ubuntu 16.10 (evtl. auch schon 16.04) fragt beim Booten auch so nur einmal. Vermutlich ein systemd-Feature?

Bei Speziallösungen (ssh, dropbear) klappt das allerdings noch nicht, bei ★ubuntu weiß ich auch nicht.

Für Container die erst nach dem Bootvorgang aufgemacht werden kann man klar Keyfiles (ggf. nur für Root lesbar) nehmen. Wem die Schlüsselableitung lieber ist der bleibt dabei. Alles Geschmackssache.

Hallo,

Okay, wenn sich niemand findet, würde mir dann bitte jemand den Artikel in die Baustelle schieben?

LUKS oder LUKS/SChlüsselableitung? Habe gerade den Überblick verloren...

Gruß, noisefloor

crazy-biscuit schrieb:

Okay das wusste ich tatsächlich nicht. Was ist denn der Vorteil einer Ableitung? Ich kann doch auch ein beliebiges File nutzen bzw. erstellen und das verwenden,indem ich es als Schlüssel hinzufüge....

Der im Wiki beschriebene Vorteil ist, dass keine Datei mit dem Passwort irgendwo im System gespeichert ist. Die Ableitung ist fest und unveränderlich im LUKS-Ursprungsgerät verankert und kann nur ausgelesen werden, wenn das Ursprungsgerät bereits entschlüsselt wurde.

frostschutz schrieb:

Heute kommt man ggf. ohne aus, allen LUKS Containern die gleiche Passphrase und zumindest Ubuntu 16.10 (evtl. auch schon 16.04) fragt beim Booten auch so nur einmal.

Ist bei 16.04 leider definitiv nicht der Fall. Hier muss im Gegenteil ein zweite Datei /etc/intramfs-tools/conf.d/cryptroot ähnlich der /etc/cryptroot aufgebaut werden, damit es möglich ist, weitere Partitionen beim Start automatisch aufzuschließen.

Ein identisches Passwort nutze ich sowieso für all meine verschlüsselten Partitionen.

noisefloor schrieb:

Hallo,

Okay, wenn sich niemand findet, würde mir dann bitte jemand den Artikel in die Baustelle schieben?

LUKS oder LUKS/SChlüsselableitung? Habe gerade den Überblick verloren...

Gruß, noisefloor

Bitte LUKS/SChlüsselableitung.

lionlizard

Hallo,

Baustelle ist da. Das Fertigstellungsdatum ggf. noch anpassen.

Wenn du fertig bist bitte hier kurz posten - oder natürlich bei Fragen etc.

Gruß, noisefloor

lionlizard schrieb:

crazy-biscuit schrieb:

Okay das wusste ich tatsächlich nicht. Was ist denn der Vorteil einer Ableitung? Ich kann doch auch ein beliebiges File nutzen bzw. erstellen und das verwenden,indem ich es als Schlüssel hinzufüge....

Der im Wiki beschriebene Vorteil ist, dass keine Datei mit dem Passwort irgendwo im System gespeichert ist. Die Ableitung ist fest und unveränderlich im LUKS-Ursprungsgerät verankert und kann nur ausgelesen werden, wenn das Ursprungsgerät bereits entschlüsselt wurde.

Das muss man generell nicht mehr. Siehe:

# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>) 
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase: 

Quelle: Dm-crypt/Device_encryption

Das funktioniert auch wunderbar! Ich habe das selbst so schon im Einsatz gehabt. Insofern unterscheidet sich der Grad der Sicherheit m.E.n. nicht.

@All:
Ich habe meine Änderungen angebracht. Bitte einmal alles genau durchsehen, weil ich im Moment nur eingechränkt zurechnungsfähig bin. (ich stehe unter starken Medikamenten)
crazy-biscuit schrieb:

Das muss man generell nicht mehr. Siehe: …

Ich weiß nicht, was Du damit sagen willst? Natürlich kann man eine weitere Passphrase hinzufügen. Es geht doch aber darum, einen Schlüssel zu benutzen, der in keiner Datei gespeichert ist, und somit nicht in Gefahr gerät, von jemand anderem entwendet zu werden.

Hallo,

rein formell (Syntax etc) ist es ok. Inhaltlich kann ich nichts dazu sagen.

Gruß, noisefloor

noisefloor schrieb:

rein formell (Syntax etc) ist es ok. …

Danke schön, das klingt ja schon mal vielversprechend.

Dann findet sich vielleicht noch jemand, der die beiden Abschnitte:

• Bestehendes Luks-Gerät

• Sicherheitsschlüssel anlegen

noch einmal testet. Das sollte zwar alles so stimmen, aber das ganze finde ich zu heikel, um es ungeprüft ins Wiki zu stellen. Sonst hätte ich das auch ohne Baustelle gemacht.

Ich würde da wie gesagt beim decrypt_derived bleiben. (eine Seite vorher)

Anders macht das einfach gar keinen Sinn (selbst wenn es funktioniert ist das einfach ein eklatanter Stilbruch).

frostschutz schrieb:

Ich würde da wie gesagt beim decrypt_derived bleiben. (eine Seite vorher)

Anders macht das einfach gar keinen Sinn (selbst wenn es funktioniert ist das einfach ein eklatanter Stilbruch).

Ich hatte Dein Beispiel nicht verstanden, genau so wenig wie die Befehlsumleitung. Das habe ich nur irgendwo abgeschrieben. Resultat war dann auch, dass beim 2. Beispiel

# Hinzufügen einer normalen Passphrase bei einem LUKS Gerät mit Schlüsselableitung:
cryptsetup luksAddKey <Gerät> --key-file <(/lib/cryptsetup/scripts/decrypt_derived <Name_des_Ursprungsgeräts>

das Fehlen der abschließenden Klammer mit dazu geführt hat, dass das so bei mir nicht funktionierte. Da es inzwischen sehr wohl funktioniert, ist da wohl noch mehr gewesen … 😳 Aber ich verstehe nun auch die Umleitung etwas besser (zumindest kenne ich ein paar mehr Möglichkeiten, die ich durchprobieren kann)

Gehst Du denn mit der jetzigen Fassung konform?

lionlizard schrieb:

Gehst Du denn mit der jetzigen Fassung konform?

Was den Befehl angeht 👍

frostschutz schrieb:

Was den Befehl angeht 👍

Sonst nicht?