ubuntuusers.de

FighterXP schrieb:

1	sudo dd if=/pfad/zum/KeyFile of=/dev/sdX bs=512 skip=1 count=4

statt

skip=1

braucht man hier dann allerdings

seek=1

Ein schöner Artikel, danke dafür. Was mir persönlich noch gefehlt hat, ist der Hinweis auf Einbindung benötiger Treibermodule:

Also z.B. per

1

sudo hwinfo --disk

die Treibernodule herausfinden und dann vorm update-initramfs in /etc/initramfs-tools/modules eintragen.

Gruß herbaman

Ich weiß, dass ist jetz bisschen OT aber muss sein: Was ein geiler Beitrag! ☺ vielen Dank

hmm, also ich denke das geht so eigentlich nicht. /etc/ befindet sich doch ggf auf einem verschlüsseltem lvm. Wäre es nicht sinnvoller alles in /boot/ zu packen? Bei mir jedenfalls klappt es so nicht.

Ray-Ven schrieb:

hmm, also ich denke das geht so eigentlich nicht. /etc/ befindet sich doch ggf auf einem verschlüsseltem lvm. Wäre es nicht sinnvoller alles in /boot/ zu packen? Bei mir jedenfalls klappt es so nicht.

Der Teil der vor dem entschlüsseln der root-Partition benötigt wird wird doch über den hook in das initramfs gepackt, und dieses liegt in /boot.

Muß es unter dem Punkt "Vorbereiten des Schlosses" anstatt

1

sudo cryptsetup luksAddKey /dev/sda5 --key-file=- tempKeyFile.bin

nicht

1

sudo cryptsetup luksAddKey /dev/sda5 --key-file=tempKeyFile.bin

lauten?

miwie schrieb:

Muß es unter dem Punkt "Vorbereiten des Schlosses" anstatt

1	sudo cryptsetup luksAddKey /dev/sda5 --key-file=- tempKeyFile.bin

nicht

1	sudo cryptsetup luksAddKey /dev/sda5 --key-file=tempKeyFile.bin

lauten?

Gut möglich dass sich da ein Tippfehler eingeschlichen hat, am besten ausprobieren und ggf. korrigieren.

- ist stdin, bei --key-file=- wirst du also gefragt... die Option kann man aber einfach weglassen, also cryptsetup luksAddKey gerät keydatei

EDIT: Darunter steht es ja sogar einmal mit --key-file=tempfile2 - das müßte falsch sein.

anders ist es wenn du cat key | crypsetup ... machen würdest, da kann --key-file=- notwendig sein, damit der Key auch über \n (Zeilenumbruch) hinaus gelesen wird.

Wer das vergisst hat am Ende womöglich einen Key von dem nur die ersten 2-3 Bytes tatsächlich relevant sind - bruteforce olé.

Ansonsten zu dem Artikel: 1 Sektor reicht. Wirklich. Passphrases sind schon sicher und die bewegen sich eigentlich immer unterhalb der 100...

Bei GPT-Partitionen klappt das mit dem Einmogeln so nicht. Da muss das etwas weiter hinten liegen...

Allgemein sollte man sehr aufpassen wo man diese tempfile-keys speichert - ist das Gerät unverschlüsselt hast du deinen Key geleakt.

frostschutz schrieb:

- ist stdin, bei --key-file=- wirst du also gefragt... die Option kann man aber einfach weglassen, also cryptsetup luksAddKey gerät keydatei

Das ist mir ja alles klar. Ich denke dass die Intention ja die ist, dass man den vom Stick extrahierten key eintragen will und dann ist die angezeigte Syntax ,mit --key-file=- keydatei nicht das gewollte.

miwie schrieb:

Ich denke dass die Intention ja die ist, dass man den vom Stick extrahierten key eintragen will

Dazu musst du den neuen Key liefern (ist die Datei) und auch einen alten Key (und der alte Key ist --key-file, nach dem wirst du dann eben gefragt)

und dann ist die angezeigte Syntax ,mit --key-file=- keydatei nicht das gewollte.

Ich kanns zwar gerade nicht ausprobieren, aber sollte eigentlich schon so klappen. Der Parameter ist nicht falsch nur in diesem Fall überflüssig.

EDIT:

Noch eine andere Möglichkeit ohne Tempfile:

cryptsetup luksAddKey --new-keyfile-offset=512 --new-keyfile-size=2048 /dev/gerät /dev/usbstick

Dann holt sich cryptsetup den Key direkt vom USB-Stick, Offset/Size ist anzupassen falls man andere Werte genommen hat.

Erstmal danke für diesen guten Artikel! Bin nun auch im Genuß eines voll verschlüsselten Systems mit bequemer Entschlüsselung.

Ich habe folgendes gefunden:
im Kapitel "Vorbereiten eines zweiten Schlosses" findet sich die Aussage: "Diesmal wird bei "skip=" 4 eingetragen, damit der bereits zuvor erstellte Schlüssel, der bis Sektor 4 geht, nicht überschrieben wird."
Das macht in meinen Augen keinen Sinn!
1. Wenn ich 2 verschlüsselte Partitionen mit einem Schlüssel aufschließen will, dann sollte ich denselben auch eintragen, nicht einen anderen 1.5kB später. Oder ich benutze 2 verschiedene Schlüssel für beide Partitionen, muß dann aber die decryptdevice.conf ändern. Nämlich so, daß mehrere Schlüssel überhaupt unterstützt werden, und das Script das dann auch erkennt!
(Ich hab mich für einen Schlüssel entschieden, der beide Partitionen aufschließt. Der Weg des geringeren Widerstands...)
2. Was sollte da überschrieben werden? Das würde nur sicherstellen, daß die beiden Schlüssel nicht identisch sind, wobei sich die ersten 512B decken würden. Da bräuchte man skip=5 statt 4.

Mein Semf! (Gut gemeinte Kritik)

Jruß
chris

chris_blues schrieb:

Oder ich benutze 2 verschiedene Schlüssel für beide Partitionen, muß dann aber die decryptdevice.conf ändern. Nämlich so, daß mehrere Schlüssel überhaupt unterstützt werden, und das Script das dann auch erkennt!

Die faule Variante wäre, einfach eine decryptkey2.{conf,sh} anzulegen (und die sh auch die 2.conf laden zu lassen). Normalerweise macht man das nicht (kopierst du Code, kopierst du auch die ganzen Bugs mit) aber was solls.

Da bräuchte man skip=5 statt 4.

Richtig. Streng genommen ist dd überhaupt unnötig, da cryptsetup durchaus in der Lage ist, sich diesen Bereich selbst direkt vom Device zu lutschen (--keyfile-offset, --keyfile-size)

So große Keys machen auch keinen Sinn. Bzw. ein großer Key macht dann Sinn wenn man befürchten muss, daß der Key klein genug ist um bei einem Defekt auf ewig in einem reallocated sector festzuhängen. Aber darum muss man sich normalerweise keine Gedanken machen...

sudo cryptsetup luksAddKey /dev/sda6 --key-file=tempKeyFile2.bin 

Das hat bei mir nicht funktioniert, es wird anscheinend versucht den Key zu benutzen, anstatt diesen hinzu zu fügen.

Meldung:

No key available with this passphrase.

Es funktioniert:

sudo cryptsetup luksAddKey --key-slot 1 /dev/sda6 tempKeyFile.bin

Hi,

der Befehl zum Hinzufügen des keyfiles muss folgendermaßen aussehen:

1

sudo cryptsetup luksAddKey /dev/sda5 --key-file=- tempKeyFile.bin

und nicht

1

sudo cryptsetup luksAddKey /dev/sda5 --key-file=tempKeyFile.bin

Sonst kommt es zu oben genannter Fehlermeldung:

1

Kein Schlüssel mit diesem Passsatz verfügbar.

Hab's gerade beim Testen feststellen dürfen 😕

Bevor ich jetzt anfange, den USB-Key zu erstellen: Was passiert denn, wenn der USB-Stick nicht im Gerät steckt (oder das Dateisystem geschreddert wurde), werde ich dann nach einem Passwort gefragt? Oder muss ich erst das LW manuell entschlüsseln und die crypttab ändern, bevor ich das System wieder starten kann?

lionlizard schrieb:

Bevor ich jetzt anfange, den USB-Key zu erstellen: Was passiert denn, wenn der USB-Stick nicht im Gerät steckt (oder das Dateisystem geschreddert wurde),

Da der Key nicht im Dateisystem, sondern auf einem ungenutzen Bereich des USB-Keys liegt kannst du das Dateisystem schreddern sooft du willst. Der Key wird dabei nicht überschrieben. Das nur am Rande 😉

werde ich dann nach einem Passwort gefragt? Oder muss ich erst das LW manuell entschlüsseln und die crypttab ändern, bevor ich das System wieder starten kann?

Wird kein Key gefunden, oder gibt es Probleme beim lesen, oder passt der Schlüssel nicht, so wird nach einem Passwort gefragt.

Ciao, Franco