lionlizard
Anmeldungsdatum: 20. September 2012
Beiträge: 6244
Wohnort: Berlin
|
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.
|
franco_bez
(Themenstarter)
Anmeldungsdatum: 1. Mai 2007
Beiträge: 688
|
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.
|
lionlizard
Anmeldungsdatum: 20. September 2012
Beiträge: 6244
Wohnort: Berlin
|
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?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7738
|
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 .
|
lionlizard
Anmeldungsdatum: 20. September 2012
Beiträge: 6244
Wohnort: Berlin
|
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.
|
franco_bez
(Themenstarter)
Anmeldungsdatum: 1. Mai 2007
Beiträge: 688
|
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
|
qwertz42
Anmeldungsdatum: 16. Januar 2016
Beiträge: 1
|
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
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7738
|
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. ☺
|
lionlizard
Anmeldungsdatum: 20. September 2012
Beiträge: 6244
Wohnort: Berlin
|
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.
|
kischai
Anmeldungsdatum: 25. Juni 2020
Beiträge: 7
|
Hi, ich würde gerne eine kleine Verbesserung im Artikel anbringen. Es geht um diesen Code
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
anschaut, bekommt man folgende Ausgabe:
| 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?
|
franco_bez
(Themenstarter)
Anmeldungsdatum: 1. Mai 2007
Beiträge: 688
|
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. | 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
|
|
kischai
Anmeldungsdatum: 25. Juni 2020
Beiträge: 7
|
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.
|
franco_bez
(Themenstarter)
Anmeldungsdatum: 1. Mai 2007
Beiträge: 688
|
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.
|
kischai
Anmeldungsdatum: 25. Juni 2020
Beiträge: 7
|
Hi franco, weißt du wie man den Artikel in die Baustelle bekommt? Ich würde die Änderung dann machen.
|
noisefloor
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29567
|
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
|