ubuntuusers.de

franco_bez schrieb:

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 😉

Mir gings natürlich um das Dateisystem des Keys… 😉

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

Danke, das hatte ich gehofft.

lionlizard schrieb:

Mir gings natürlich um das Dateisystem des Keys… 😉

Mir auch 😉

Der Key liegt in der Regel völlig außerhalb des Dateisystems an einer Stelle die normalerweise komplett ungemutzt ist. Auch ein "neuformatieren" des USB Sticks beschädigt den Key in der Regel nicht.

Achtung!

In diesem Beispiel wird davon ausgegangen, dass die Home-Partition den Pfad /dev/sda6 hat. Dieser Wert muss natürlich angepasst werden, wenn er vom Beispiel abweicht.

Neuen Schlüssel mit Schlüsseldatei hinzufügen.

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

Der markierte Ausdruck ist doch an dieser Stelle zuviel, da cryptsetup so tempkeyfile2.bin als Authentifizierung zur Änderung des Schlüssels versteht - und nicht als hinzuzufügenden Schlüssel. Oder habe ich da was falsch verstanden?

Habe jetzt den kontext nicht verfolgt, aber da wird eine weitere Passphrase hinzugefügt und als bestehende das Keyfile angegeben.

Vielleicht weniger mißverständlich wenn man die Option zuerst bringt. Das ist auch die Reihenfolge die von der Manpage suggeriert wird (cryptsetup <options> <action> <action args>)

--key-file=tempKeyFile2.bin wäre <options>. /dev/sda6 tempkeyfile wären action args, für die action luksAddKey.

Ich habe den Kontext so verstanden, dass ein weiterer Schlüssel für eine zweite Partition erzeugt wird und dieser dann der zweiten Partition hinzugefügt. Aber das ist genau der Grund, warum ich nicht einfach geändert habe, sondern hier nachfrage.

Wenn ich das übrigens richtig verstanden habe, so ist auch nicht erklärt, wie man dem System mitteilt, dass der zweite Schlüssel für zweite Partition benutzt werden soll. Ich habe so etwas hier gelöst, indem ich ein zweites Verzeichnis mit etwas anderem Namen unter /etc angelegt und den Pfad im decryptkeydevice_keyscript.sh angepasst habe.

lionlizard schrieb:

Neuen Schlüssel mit Schlüsseldatei hinzufügen.

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

Der markierte Ausdruck ist doch an dieser Stelle zuviel, da cryptsetup so tempkeyfile2.bin als Authentifizierung zur Änderung des Schlüssels versteht - und nicht als hinzuzufügenden Schlüssel. Oder habe ich da was falsch verstanden?

In einer älteren Version stand da noch (siehe http://wiki.ubuntuusers.de/System_verschl%C3%BCsseln/Entschl%C3%BCsseln_mit_einem_USB-Schl%C3%BCssel?rev=542342 )

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

Da ist bei den Überarbeitungen wohl etwas kaputt gegangen.

Ich bin mir nicht sicher ob der Teil mit den zwei Schlüsseln jemals richtig getestet wurde.

So ganz kapiere ich nicht warum es unsicherer sein sollte beide Partitionen mit dem selben Schlüssel zu versehen, bzw. für die zweite Partition die LUKS/Schlüsselableitung zu benutzen.

Die Schlüsselableitung hätte einen weiteren Vorteil:

Wenn man den USB-Key nicht griffbereit hat muss man nur einmal das Passwort für die erste Partition eingeben, der Schlüssel für die zweite Partition würde dann automatisch gezogen.

lionlizard schrieb:

Ich habe den Kontext so verstanden, dass ein weiterer Schlüssel für eine zweite Partition erzeugt wird und dieser dann der zweiten Partition hinzugefügt. Aber das ist genau der Grund, warum ich nicht einfach geändert habe, sondern hier nachfrage.

Wenn ich das übrigens richtig verstanden habe, so ist auch nicht erklärt, wie man dem System mitteilt, dass der zweite Schlüssel für zweite Partition benutzt werden soll. Ich habe so etwas hier gelöst, indem ich ein zweites Verzeichnis mit etwas anderem Namen unter /etc angelegt und den Pfad im decryptkeydevice_keyscript.sh angepasst habe.

Wie gesagt, ich verstehe das auch nicht. Vielleicht sollte man den Abschnitt nochmal überarbeiten oder ganz entfernen.

Ciao,

Franco

Hallo Leute,

ich hatte das Problem, dass bei einer Neuinstallation von 16.04.1 (hier Xubuntu) das Skript nicht mehr funktionierte. Ich hatte es viele Jahre auf verschiedenen Rechnern im Einsatz und auch ein Update auf 16.04 ließ das Skript weiterhin funktionierten. Nicht so die Neuinstallation.

Laut https://wiki.debianforum.de/Cryptsetup_mit_systemd_und_Schlüssel_auf_externem_USB-Stick liegt es an systemd, das dd nicht ausführen soll. Soweit, so verständlich.

Als letzter Test hatte ich mir überlegt, dass systemd vermutlich /bin/dd nicht findet. (Vgl. auch die Manpage von cryptsetup.) Daher habe ich dd nach /etc/decryptdevice kopiert, das Skript angepassst (/etc/decryptdevice/dd statt /bin/dd) und das initramfs neu bauen lassen, wie in der Anleitung beschrieben - und siehe da, plötzlich geht es wieder!

Könntet ihr (liebe Maintainer des Skripts) hier eine passendere Lösung finden als diese Quick'n'Dirty Version? Gibt es einen passenderen Ort, um dd unterzubringen? Was passiert bei Updates, ...? Bei so vielen Fragen ist sicherlich die Q'n'D-Lösung nicht das Wahre.

VG Alexander

Du könntest probieren ob dd funktioniert wenn nicht /bin/ davor steht... oder 'busybox dd'.

Auf dd komplett zu verzichten ist sicher die bessere Lösung. Cryptsetup kann sich selbst was von der Platte kratzen (keyfile-length, keyfile-offset) oder aber du legst direkt für den Key eine kleine (512 Byte, 4KiB, ...) Partition an und nimmst dann diese Partition als Key.

Wie das jetzt im Einzelnen mit diesem Script vereinbar ist... keine Ahnung, ich nutze es nicht, sorry. ☺

Wenn man außer dem Systemlaufwerk weitere Laufwerke freischalten möchte, ist, nach meinen Tests, eine weitere Datei /etc/initramfs-tools/conf.d/cryptroot anzulegen. Hier werden die zusätzlichen Laufwerke mit folgender Syntax eingetragen:

target=<Name>,   source=UUID=<xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx>,trial=3,keyscript=/etc/dekra/keyskript.sh

wobei <Name> der Mapper-Name ist, unter dem das Laufwerk unter /dev/mapper/<Name> eingebunden wird, und die UUID der aus der /etc/crypttab entspricht. Es ist darauf zu achten, dass der letzte Eintrag mit einer Zeilenschaltung abgeschlossen wird, weil vom System automatisch ein Eintrag für das Systemlaufwerk erstellt und angehängt wird, wie man ersehen kann, wenn man sich das fertige initrd.img entpackt und ansieht. Bei Fehlender Zeilenschaltung wird ein Eintrag

target=<Name>,   source=UUID=<xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx>,trial=3,keyscript=/etc/dekra/keyskript.shtarget=<Name>,   source=UUID=<xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx>,trial=3,keyscript=/etc/dekra/keyskript.sh 

erzeugt, der naturgemäß zu einem Fehler führt.

Wer sich das initrd.img einmal ansehen will, kann dies durch den Befehl zcat /boot/initrd.img-x.x.x-xx-generic | cpio -idmv im aktuellen Verzeichnis entpacken lassen. Man legt also sinnvollerweise zunächst ein Verzeichnis an, wechselt hinein und entpackt dann

mkdir initram
cd initram
zcat /boot/initrd.img-x.x.x-xx-generic | cpio -idmv

Natürlich ist nach dem erstellen der /etc/initramfs-tools/conf.d/cryptroot ein sudo update-initramfs fällig.

Hi, ich würde gerne eine kleine Verbesserung im Artikel anbringen.

Es geht um diesen Code

1

sudo fdisk -l /dev/sdb

Der Befehl soll einem die Notwendige Information liefern in welchen Bereich man unbeschadet seinen Schlüssel legen darf. Wenn man dieses Verfahren auf einen USB-Stick mit GPT statt mit MBR anwendet, zerschießt man sich unter Umständen die GPT auf dem USB-Stick. Genau das ist mir passiert. Fdisk liefert mit meinem Stick:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

sudo fdisk -l /dev/sdb
...
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
...

Gerät        Anfang      Ende  Sektoren  Größe Typ
/dev/sdb1  17371136 121108479 103737344  49,5G Microsoft Basisdaten
/dev/sdb2      1953      3906      1954   977K BIOS boot
/dev/sdb3      3907    503906    500000 244,1M EFI-System

Nach der Beschreibung im Artikel würde man nun den Schlüssel in den Bereich 0...1952 legen. Das hat dann bei mir zu einer kaputten GPT geführt. Wenn man sich den selben USB Schlüssel mit

1

sudo gdisk -l /dev/sdb

anschaut, bekommt man folgende Ausgabe:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

sudo gdisk -l /dev/sdb
...
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 121110494
...

Number  Start (sector)    End (sector)  Size       Code  Name
   1        17371136       121108479   49.5 GiB    0700  primary
   2            1953            3906   977.0 KiB   EF02  primary
   3            3907          503906   244.1 MiB   EF00  primary

Damit ist dann klar das man den Schlüssel in den Bereich 34...1952 legen muss. Das klappt gut, die GPT bleibt heil.

Die Änderung wäre also statt fdisk den Befehl gdisk wie oben Beschrieben zu verwenden.

Was haltet ihr von der Verbesserung?

kischai schrieb:

Die Änderung wäre also statt fdisk den Befehl gdisk wie oben Beschrieben zu verwenden.

Was haltet ihr von der Verbesserung?

Hallo kischai ,

das ist schon eine sehr wichtige Info die meiner Meinung nach unbedingt in die Anleitung reingehört.

Aber einfach nur fdisk durch gdisk ersetzten geht nicht. Bei MBR Formatierten Sticks liefert gdisk irreführende Angaben (siehe unten)

Ich vermute dass die allermeisten Sticks noch MBR formattiert sind.

Man müsste den Hinweis einbauen dass man auf den Festplattenbezeichnungstyp achten muss und dass man im Falle gpt unbedingt gdisk an Stelle von fdisk verwenden soll.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

sudo fdisk -l /dev/sdc
Festplatte /dev/sdc: 29,46 GiB, 31625052160 Bytes, 61767680 Sektoren
Festplattenmodell: SanDisk Ultra   
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x15f006ae

Gerät      Boot Anfang     Ende Sektoren Größe Kn Typ
/dev/sdc1  *      2048 61767679 61765632 29,5G  c W95 FAT32 (LBA)

gdisk gibt verwirrende Info für den Fall Festplattenbezeichnungstyp: dos

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

sudo gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 
***************************************************************


Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/sdc: 61767680 sectors, 29.5 GiB
Model: SanDisk Ultra   
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 56F8A6A6-3A62-4D23-A6C5-2C11E6AFD439
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 61767646
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        61767679   29.5 GiB    0700  Microsoft basic data

Aber einfach nur fdisk durch gdisk ersetzten geht nicht. Bei MBR Formatierten Sticks liefert gdisk irreführende Angaben (siehe unten)

Ja, das ist zu kurz gesprungen.

Beide Befehle zu verwenden würde ich eher als Rückfalllösung betrachten weil es den Artikel unschön aufbläht. Ich werde am Wochenende mal recherchieren ob es ein Tool gibt das zu beiden Varianten MBR und GPT korrekte Informationen liefert.

kischai schrieb:

Aber einfach nur fdisk durch gdisk ersetzten geht nicht. Bei MBR Formatierten Sticks liefert gdisk irreführende Angaben (siehe unten)

Ja, das ist zu kurz gesprungen.

Beide Befehle zu verwenden würde ich eher als Rückfalllösung betrachten weil es den Artikel unschön aufbläht. Ich werde am Wochenende mal recherchieren ob es ein Tool gibt das zu beiden Varianten MBR und GPT korrekte Informationen liefert.

eventuell ist es auch immer der Bereich 2 bis 33 bei dem Vorsicht geboten ist. Auf allen meinen GPT partitionierten Datenträgern liefert gdisk -l

...
Main partition table begins at sector 2 and ends at sector 33
...

Nachtrag: https://de.wikipedia.org/wiki/GUID_Partition_Table

Sieht so aus dass es bei GPT immer die Sektoren 0-33 taboo sind. Dann würde ein einfacher Hinweis reichen.

Hi franco, weißt du wie man den Artikel in die Baustelle bekommt? Ich würde die Änderung dann machen.

Hallo,

das steht hier: Link. "Kleine Änderung" kannst du auch "on the fly" machen. Aber wenn dir eine Baustelle lieber ist → hier nochmal posten.

Gruß, noisefloor