Entschlüsseln mit einem USB-Schlüssel: "Kein Schlüssel...

[pachhenk]

Hallo,

meine Versuche, einen USB-Stick als Schlüssel zu verwenden, scheitern an der Fehlermeldung:

Code: Alles auswählen

Kein Schlüssel mit dieser Passphrase verfügbar.

Ich weiss nicht, was damit gemeint ist.

Nach dem HowTo:
http://wiki.debianforum.de/Cryptsetup_m ... _USB-Stick
habe ich es mehrmals versucht, immer die selbe Meldung. Liegts am HowTo? Ist ja in Überarbeitung. Oder mach ich was falsch?

Das Sytem ist eine ganz normale i386 jessie Installation (vom Stick aus), auf einem hp Compaq Mini 110 mit CF als Festplatte.

Hab das ganze nochmal im Terminal gemacht und rauskopiert:

Code: Alles auswählen

BENUTZER@debian:~$ su
Passwort: 
root@debian:/home/BENUTZER# cd
root@debian:~# sudo fdisk -l
bash: sudo: Kommando nicht gefunden.
root@debian:~# fdisk -l

Disk /dev/sda: 14.9 GiB, 16000221184 bytes, 31250432 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x49f1a71c

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1  *      2048   499711   497664  243M 83 Linux
/dev/sda2       501758 31248383 30746626 14.7G  5 Extended
/dev/sda5       501760 31248383 30746624 14.7G 83 Linux

Disk /dev/mapper/sda5_crypt: 14.7 GiB, 15740174336 bytes, 30742528 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/debian--vg-root: 14 GiB, 15044968448 bytes, 29384704 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/debian--vg-swap_1: 660 MiB, 692060160 bytes, 1351680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sdb: 486.5 MiB, 510132224 bytes, 996352 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start    End Sectors   Size Id Type
/dev/sdb1         235 996351  996117 486.4M  6 FAT16

root@debian:~# dd if=/dev/urandom of=/dev/sdb bs=512 seek=1 count=60 
60+0 Datensätze ein
60+0 Datensätze aus
30720 Bytes (31 kB) kopiert, 0.0297488 s, 1.0 MB/s
root@debian:~# dd if=/dev/sdb bs=512 skip=1 count=4 > tempKeyFile.bin 
4+0 Datensätze ein
4+0 Datensätze aus
2048 Bytes (2.0 kB) kopiert, 0.00129828 s, 1.6 MB/s
root@debian:~# cryptsetup luksAddKey /dev/sda5 --key-file=tempKeyFile.bin
Kein Schlüssel mit dieser Passphrase verfügbar.
root@debian:~# 

Könnt ihr etwas sehen, worans liegt?
Oder mir sagen, wie die Fehlermeldung gemeint ist. Ich komme nicht drauf was klemmt.

Gruss pachhenk

[rendegast]

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

Wie ist es mit

Code: Alles auswählen

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

'--key-file=' findet sich in der manpage nur als '--key-file=-'.
Wenn das jedoch relevant ist, so wäre das ziemlich verwirrend.

[pachhenk]

Code: Alles auswählen

root@debian:~# dd if=/dev/urandom of=/dev/sdb bs=512 seek=1 count=60 
60+0 Datensätze ein
60+0 Datensätze aus
30720 Bytes (31 kB) kopiert, 0.767971 s, 40.0 kB/s
root@debian:~# dd if=/dev/sdb bs=512 skip=1 count=4 > tempKeyFile.bin 
4+0 Datensätze ein
4+0 Datensätze aus
2048 Bytes (2.0 kB) kopiert, 0.00100229 s, 2.0 MB/s
root@debian:~# cryptsetup luksAddKey /dev/sda5 --key-file tempKeyFile.bin
Kein Schlüssel mit dieser Passphrase verfügbar.
root@debian:~# cryptsetup luksAddKey /dev/sda5 --key-file tempKeyFile.bin
Kein Schlüssel mit dieser Passphrase verfügbar.
root@debian:~# cryptsetup luksAddKey /dev/sda5 --key-file=-tempKeyFile.bin Konnte Schlüsseldatei nicht öffnen.
root@debian:~# cryptsetup luksAddKey /dev/sda5 --key-file= -tempKeyFile.bin 
Verwendung: cryptsetup [-?vyrq] [-?|--help] [--usage] [--version] [-v|--verbose]
        [--debug] [-c|--cipher=STRING] [-h|--hash=STRING]
        ....
        [OPTION...] <Aktion> <aktionsabhängig>
-tempKeyFile.bin: Ungültiger nummerischer Wert
root@debian:~# 

Danke für den Tip.
Ich werde mir nochmal das manual genau anschauen und mein Geschreibsel. Vielleicht hab ich doch was übersehen.

[rendegast]

Scheint eher so zu sein:

Code: Alles auswählen

cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin 

Per '--keyfile ...' würde wohl eher ein Passphrase für die tempKeyFile.bin mitgegeben,
ohne diese Option wird wohl nach der Passphrase des vorhandenen Key im slot0 gefragt.

[pachhenk]

das sah erstmal besser aus. Aber scheint noch nicht zu gefallen...

Code: Alles auswählen

root@debian:~# cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin 
Geben Sie irgendeine Passphrase ein: IRGENDEINE PASSPHRASE
Kein Schlüssel mit dieser Passphrase verfügbar.
root@debian:~#

Ich wühle mich grad durch das Manual und andere Infos. Das Problem ist, dass ich eben nur wenig weiss, von dem was da abläuft. So kann ich auch nichts anfangen mit den Fehlermeldungen. Für mich ist es ein Wiederspruch, wenn ich irgendetwas eingeben soll (IRGENDEINE PASSPHRASE), und dann aber eine erwartet wird, die schon vorhanden(verfügbar) ist.

[rendegast]

Es ist wohl eine in diesem Moment für diese Aktion irgendwie gültige Passphrase gemeint.
In der Doku/manpage wird die Passphrase des Schlüssels im slot0 genannt,
habe ich vorher mal erwähnt.

Nebenbei, wenn ich "irgendeine" Passphrase eingeben könnte,
könnte sich ja jeder Zugang zum Container verschaffen.
Kein guter Schutz für geklaute Notebooks.

[pachhenk]

Danke!

Code: Alles auswählen

root@debian:~# cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha1
Payload offset:	4096
MK bits:       	512
MK digest:     	68 77 dd 52 2c 7e 58 d4 f0 39 58 4d cd 4c 46 3b 24 2d fb 59 
MK salt:       	4e 02 c2 8a d5 0f 96 ca 24 52 0d 0c 35 d2 fa 90 
               	02 e2 d7 81 fa da 7d 04 20 cc 26 82 a3 85 92 dd 
MK iterations: 	16000
UUID:          	44c83b8d-d7c5-4c4e-a505-322275abe67f

Key Slot 0: ENABLED
	Iterations:         	67509
	Salt:               	e8 ce 8b 8e 1f 52 4a c6 f0 2e 78 98 0e 60 c4 0c 
	                      	65 5f 44 74 76 30 44 d7 65 f1 b3 3e 84 60 23 4c 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

(Ich habe keine Ahnung ob die Infos "geheim" sind. Ist aber egal, das ist mein Sandkasten hier.)

Es gibt bisher einen Schlüssel. Vielleicht wird der erwartet. Anstatt "irgendeinen" gebe ich mal den Einzigen ein, von dem ich weiss, dass er existiert; die Passphrase die ich während der Installation zum Verschlüsseln angegeben hatte.

root@debian:~# cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin
Geben Sie irgendeine Passphrase ein:
root@debian:~#

Schweigen im Walde. Ist das ein gutes Zeichen? Ich gehe mal davon aus, und mach, zur Konfiguration, mit dem Wechsel ins DebianforumWiki weiter.

EDIT: Nach der Konfiguration wird beim Starten wie bisher die Passphrase abgefragt. Das mit dem Schlüssel scheint nicht zu funktionieren.
Weil die Erklärungen zur Konfiguration im Ubuntuwiki viel umfangreicher sind, werde ich sie auch noch durch gehen, und mit dem was ich nach Debianforumwiki gemacht hab vergleichen. Vielleicht fehlt noch was.

[rendegast]

root@debian:~# cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin
Geben Sie irgendeine Passphrase ein:
root@debian:~#
Schweigen im Walde. Ist das ein gutes Zeichen?

Ja, nachsehen per '... luksDump ...', wie oben schon geschehen.

2.EDIT: nach der Konfiguration und wird beim Starten wie bisher die Passphrase abgefragt. Das mit dem Schlüssel scheint nicht zu funktionieren.

Nunja, versuch es mal so:

Code: Alles auswählen

# ll
total 796
-rw-r--r-- 1 root root      2048 Aug 14 18:18 rand1
-rw-r--r-- 1 root root      2048 Aug 14 18:18 rand2
-rw-r--r-- 1 root root 104857600 Aug 14 22:20 diskfile
#
# cryptsetup luksAddKey ./diskfile rand1
Enter any passphrase: 
#
# cryptsetup luksAddKey ./diskfile rand2 --key-file rand1
# 
# cryptsetup luksDump ./diskfile 
LUKS header information for ./diskfile

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      8e c0 75 fa 08 f0 f6 96 6f 16 90 65 77 8b a0 01 17 6b c0 ad 
MK salt:        09 ab 41 1d d6 5a 38 7e 96 18 3b ba 39 d5 40 38 
                29 3e 27 5d 31 cd fb de 53 01 88 ef 23 5c 75 bb 
MK iterations:  81125
UUID:           37c177bc-2319-41ef-af68-16f36eb99d26

Key Slot 0: ENABLED
        Iterations:             326530
        Salt:                   cd 41 90 77 00 08 9e b1 9b 35 6f 21 e0 32 79 75 
                                a2 3d 51 7b 9d 50 6e 29 81 a5 6b 62 0e e3 e9 e9 
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: ENABLED
        Iterations:             312194
        Salt:                   f2 07 c7 e1 b9 45 4e 8b ea e0 54 2c 09 49 7a a5 
                                b1 90 17 e0 47 bc a3 6e 7b e7 e3 d2 00 68 1a a6 
        Key material offset:    264
        AF stripes:             4000
Key Slot 2: ENABLED
        Iterations:             309178
        Salt:                   58 fc bf 99 01 e2 cd 50 78 96 b2 37 c2 7f a9 9f 
                                0e d0 08 d3 1d 1c 1c 43 70 99 36 af 8c 71 31 40 
        Key material offset:    520
        AF stripes:             4000
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Beim 2ten Key brauche ich keine Passphrase (mehr).
Beim 1sten wohl auch nicht, wenn ich als '--key-file' den Key aus slot0 verwenden würde.



(EDIT, geänderte Namen disk 1 2 -> diskfile rand1 rand2)

[pachhenk]

Ja, nachsehen per '... luksDump ...', wie oben schon geschehen.

Ja, hier das gleiche:

Code: Alles auswählen

root@debian:~# cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha1
Payload offset:	4096
MK bits:       	512
MK digest:     	68 77 dd 52 2c 7e 58 d4 f0 39 58 4d cd 4c 46 3b 24 2d fb 59 
MK salt:       	4e 02 c2 8a d5 0f 96 ca 24 52 0d 0c 35 d2 fa 90 
               	02 e2 d7 81 fa da 7d 04 20 cc 26 82 a3 85 92 dd 
MK iterations: 	16000
UUID:          	44c83b8d-d7c5-4c4e-a505-322275abe67f

Key Slot 0: ENABLED
	Iterations:         	67509
	Salt:               	e8 ce 8b 8e 1f 52 4a c6 f0 2e 78 98 0e 60 c4 0c 
	                      	65 5f 44 74 76 30 44 d7 65 f1 b3 3e 84 60 23 4c 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: ENABLED
	Iterations:         	62500
	Salt:               	15 25 f8 0a f7 e9 94 ad bb 2c 34 78 4e 72 da 21 
	                      	8e ff 18 74 cd c9 51 2c d4 4a 13 d4 5c b7 4f 79 
	Key material offset:	512
	AF stripes:            	4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Aber immer noch die gleiche Antwort auf:

Code: Alles auswählen

root@debian:~# cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin 
Geben Sie irgendeine Passphrase ein: 
Kein Schlüssel mit dieser Passphrase verfügbar.

Auf

Code: Alles auswählen

root@debian:~# cryptsetup luksAddKey /dev/sda5
Geben Sie irgendeine bestehende Passphrase ein: 
Geben Sie die neue Passphrase für das Schlüsselfach ein: 
Passphrase wiederholen: 
root@debian:~# 

wird jetzt eine "bestehende" verlangt.
Mir fehlen die Zusammenhänge. Gibts neben den WikiInfos vielleicht irgendwo eine grafische Darstellung von all dem? Das ist alles so verschachtelt, da würde mir ein "Bildchen" vieleicht helfen.

Nunja, versuch es mal so:

Code: Alles auswählen

# ll
total 796
-rw-r--r-- 1 root root      2048 Aug 14 18:18 1
-rw-r--r-- 1 root root      2048 Aug 14 18:18 2
-rw-r--r-- 1 root root 104857600 Aug 14 22:20 disk
#
# cryptsetup luksAddKey ./disk 1
Enter any passphrase: 
...

Beim 2ten Key brauche ich keine Passphrase (mehr).
Beim 1sten wohl auch nicht, wenn ich als '--key-file' den Key aus slot0 verwenden würde.

Was bedeutet "# ll" ?
ok:
https://de.wikipedia.org/wiki/PKCS
Wo bist du bei "cryptsetup luksAddKey ./disk 1"?

Werd jetzt alles nochmal in Ruhe durchschauen.
Mit weniger Eifer...

[rendegast]

ja, hier das gleiche:

Nein, im Gegensatz zu Deinem ersten Quote ist bei Deinem zweiten der slot1 belegt worden.

Wo bist du bei "cryptsetup luksAddKey ./disk 1"?

Die Dateien 1 und 2 (EDIT rand1 und rand2) sind einfach 2kB lange random-Ausgaben.
disk (diskfile) ist eine per qemu-img erstellte Datei, statt Verwendung eines block-device.
Ich füge da die Datei 1 (rand1) als Schlüssel dem luks-Header hinzu.
Bei mir wird beim Belegen des slot2 mit der Datei 2 (rand2) die Aktion durch Angabe des vorher hinzugefügten und somit gültigen Schlüssels Datei 1 (rand1) bestätigt,
dadurch muß ich für diesen keine Passphrase angeben.

Das Hinzufügen der Datei 1 (rand1) hätte ich auch mit dem Key "slot0"
(welcher beim luksFormat erzeugt wird) bestätigen können,
statt der Angabe der Passphrase des Key "slot0".
An den sogenannten Master-Key käme mensch per

luksDump <device>

dumps the header information of a LUKS partition.

If --dump-master-key option is used, the volume (master) key is dumped instead of keyslot info. Because this information can be used to access encrypted device without passphrase knowledge (even without LUKS header) use this option very carefully.

(Ich mache oben mal ein EDIT wegen der Namen)

Was bedeutet "# ll" ?
ok:
..link..

Ein gebräuchlicher alias von 'ls -l',
das # ist der Prompt der benutzten root-Shell,
nicht vergleichbar dem # aus dem Link, welches wohl eher als "Nr." zu deuten ist.
Zudem ist der Link eine Aufzählung,
es finden sich dort keine Beispielbefehle oder etwas in der Art "Howto"
("Wo bist du bei "cryptsetup luksAddKey ./disk 1"? ").

[pachhenk]

ächz...
Hab bis jetzt mal die 40 Seiten Einführung von Hauke L. gelesen und VERSUCHT zu verstehen. Was mir leider nur bruchstückhaft gelingt.

Ich habe keinen Schimmer was random-Ausgaben, qemu-img, luks-Header usw sind. Manches kann ich mir so vage vorstellen (zB luks-Header), es fehlen mir jedoch die Grundlagen, um einigermassen den Überblick zu haben wo, was, wozu ist.
Aber ich bleib weiter dran.
Lernen kann ich so auf jeden Fall einiges. Und das Thema finde ich sehr interessant.
Werd mich also jetzt mal um "random-Ausgaben, qemu-img, luks-Header" und so kümmern.

[rendegast]

Ich habe keinen Schimmer was random-Ausgaben,

Ähmmm

root@debian:~# dd if=/dev/urandom of=/dev/sdb bs=512 seek=1
root@debian:~# dd if=/dev/sdb bs=512 skip=1 count=4 > tempKeyFile.bin

Ich habe "mein" rand halt direkt in Dateien gesteckt

Code: Alles auswählen

dd if=/dev/urandom of=1 bs=512 count=4
dd if=/dev/urandom of=2 bs=512 count=4
dd if=/dev/urandom of=3 bs=512 count=4
...

Ich habe keinen Schimmer was .... qemu-img,

Es gibt

Code: Alles auswählen

dd if=/dev/zero of=datei bs=1M count=100
oder
qemu-img create datei 100M

Ich habe keinen Schimmer was ... luks-Header

Da stecken die Schlüssel für den Container drin,
gelistet per 'cryptsetup luksDump ...'.

[pachhenk]

ok, danke!
Jetzt haben ein paar Synapsen geklickt.
Die Passphrase zum ersten Schlüssel für sda5, welche ich bei der Installation eingegeben habe, ist für slot0. Beim hinzufügen des zweiten Schlüssels sollte dieser (=rand2) aus der Datei tempKeyFile.bin gelesen werden , was aber irgendwie nicht geklappt hat. Für diesen Vorgang müsste ich die erste Passphrase angeben oder das key-file von slot0, und nicht, wie ich es gemacht hab, irgendeine. Also kann das Ganze noch nicht funktionieren, weil dieser Schlüssel so wie ich es gemacht habe, noch nicht hinzugefügt wurde.
Ich muss eben diese Sache mit dem 'key-file=' hinkriegen.
Mit

Code: Alles auswählen

cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin

füge ich doch einen neuen Schlüssel hinzu. Da wäre es doch logisch, dass ich irgendeine Passphrase angeben kann, so, wie bei der Installation schon.
Ich probier es jetzt nochmal Schritt für Schritt mit Angabe der ersten Passphrase wenn ich irgendeine angeben soll, auch wenns mir nicht einleuchtet. Nur mal zum Test.

Code: Alles auswählen

root@debian:~# mount
...
/dev/sda1 on /boot type ext2 (rw,relatime)
...
/dev/sdb1 on /media/BENUTZER/EOS_DIGITAL type vfat 
...
root@debian:~# dd if=/dev/urandom of=/dev/sdb bs=512 seek=1 count=60 
60+0 Datensätze ein
60+0 Datensätze aus
30720 Bytes (31 kB) kopiert, 0.753064 s, 40.8 kB/s
root@debian:~# dd if=/dev/sdb bs=512 skip=1 count=4 > tempKeyFile.bin 
4+0 Datensätze ein
4+0 Datensätze aus
2048 Bytes (2.0 kB) kopiert, 0.00489545 s, 418 kB/s
root@debian:~# cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin 
Geben Sie irgendeine Passphrase ein: 
root@debian:~#
root@debian:~#reboot 

Beim Starten wieder die Abfrage der Passphrase.

[rendegast]

Code: Alles auswählen

Mit
    cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin
füge ich doch einen neuen Schlüssel hinzu. Da wäre es doch logisch, dass ich irgendeine Passphrase angeben kann, so, wie bei der Installation schon. 

Das könnte der nette Beamte vom BND ja dann auch,
würde ihm die Arbeit ungemein erleichtern.

Anders,
Du stellst Dich vor ein fremdes Haus, nimmst Dir irgendeinen Schlüssel aus Deiner Tasche, schreibst "Kellertür" auf den Anhänger und Peng -- er paßt.

[pachhenk]

Das stimmt.

Mittlerweile habe ich noch die oben erwähnte Anleitung vom wiki.ubuntuusers.de abgearbeitet. Erst ab dem Punkt von dem an ich zuvor auf das wiki.debianforum gewechselt hatte.

Viel Hoffnung hatte ich nicht. Aber mir kams seltsam vor, dass man all die Schritte weglassen können soll. Das Ergebnis wirft leider nur noch mehr Fragen auf, und funktioniert auch nicht.

Code: Alles auswählen

root@debian:~# cp /home/BENUTZER/Downloads/decryptkeydevice_keyscript.sh /etc/decryptkeydevice/
root@debian:~# less /etc/decryptkeydevice/decryptkeydevice_keyscript.sh 
root@debian:~# chmod +x /etc/decryptkeydevice/decryptkeydevice_keyscript.sh 
root@debian:~# nano /etc/crypttab 
root@debian:~# less /etc/crypttab
/dev/sda5 UUID=44c83b8d-d7c5-4c4e-a505-322275abe67f /dev/disk/by-id/Generic-_Multi-Card_20071114173400000-0:0 luks,tries=3,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh
/etc/crypttab (END)
root@debian:~# cp /home/BENUTZER/Downloads/decryptkeydevice.hook /etc/initramfs-tools/hooks/
root@debian:~# chmod +x /etc/initramfs-tools/hooks/decryptkeydevice.hook 
root@debian:~# update-initramfs -k 'uname -r' -c
update-initramfs: Generating /boot/initrd.img-uname -r
WARNING: missing /lib/modules/uname -r
Ensure all necessary drivers are built into the linux image!
depmod: FATAL: uname: not absolute path.
cryptsetup: WARNING: invalid line in /etc/crypttab for sda5_crypt - 
cryptsetup: WARNING: invalid line in /etc/crypttab for sda5_crypt - 

depmod: ERROR: could not open directory /var/tmp/mkinitramfs_WhuBHc/lib/modules/3.16.0-4-686-pae: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
root@debian:~# 
root@debian:~# update-initramfs -k `uname -r` -c
Cannot create version 3.16.0-4-686-pae: already exists
root@debian:~# reboot

Ich glaub ich räum den ganzen Schrott erst mal auf, und fang ganz von vorne an.

[pachhenk]

Also noch mal der Reihe nach:

Aus dem Manual kann ich nur erfahren, dass Schlüssel und Passphrase jeweils interaktiv oder mit Angabe einer Datei übergeben werden können. Wie aber die Syntax sein muss, kann ICH nicht hereausfinden, obwohl ich ein bisschen Englisch kann.

Ich gehe jetzt davon aus, dass bei der Installation ein Schlüssel aus meiner Passphrase generiert wurde, und damit (fast) alles verschlüsselt ist.
Mit dem Befehl

Code: Alles auswählen

root@debian:~# cryptsetup luksAddKey /dev/sda5 --key-file=-tempKeyFile.bin 

wird wohl versucht eine Passphrase aus der binären Datei zu lesen. Was nicht klappt.

Code: Alles auswählen

Konnte Schlüsseldatei nicht öffnen.

Ich versuche es noch einmal mit dieser Variante:

Code: Alles auswählen

root@debian:~# cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin

Scheint mir am logischsten.

Hier alles auf NoPaste (ich hoffe das ist richtig so):
http://nopaste.debianforum.de/38731

Danach ist leider immer noch alles beim Alten. Beim Start wird die Passphrase abgefragt.

Code: Alles auswählen

cryptsetup luksDump /dev/sda5

zeigt zwar, dass ein zweiter Schlüssel vorhanden ist. Aber ob dafür die eingegebene Passphrase verwendet wurde oder aus dem tempKeyFile.bin gelesen wurde weiss ich nicht.

[OFF TOPIC]
Alles in allem (zwei volle Tage), hätte mich doch gefreut wenn ich bisschen mehr erreicht hätte.
Aber Durchzappen egal was passiert, Hauptsache es rappelt und danch läuft irgendwas, irgendwie bis zum nächsten "keinenPlanhab" kenne ich gut. So gesehen ist das diesmal doch befriedigender. Und Druck habe ich zum Glück keinen, das ist einfach Interesse an Dingen die leider immer wichtiger werden.
[/OFF TOPIC]

rendegast, ich danke dir für die Unterstützung! Werde sicher weitermachen. Aber morgen Früh um 4:00h gehts bei mir wieder los, und ein bisschen Abhängen brauch ich vorher noch.

Gruss pachhenk

[rendegast]

cryptsetup luksAddKey /dev/sda5 --key-file=-tempKeyFile.bin
wird wohl versucht eine Passphrase aus der binären Datei zu lesen. Was nicht klappt.

Richtig, einmal fehlt die Angabe des hinzuzufügenden Schlüssels,
zusätzlich ist '--key-file=-tempKeyFile.bin' wohl falsch, '-tempKeyFile.bin' ist wohl keine valide Datei.
(Syntax '--key-file=datei' (MIT =-Zeichen) ist wie '--key-file datei' valide)
'--key-file datei': 'datei' muß einen eingetragenen Schlüssel enthalten.

Code: Alles auswählen

cryptsetup luksAddKey /dev/sda5 hinzuf.Schluessel    --key-file valid.Schluessel 

Ich versuche es noch einmal mit dieser Variante:
cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin

Da Angabe '--key-file ...' fehlt, wird nach Passphrase gefragt.





Nach weiterem Lesen der manpage und Herumprobieren,
"Passphrase" IST gleichbedeutend "key".
Bis zu 8 Passphrases resp. keys kann ein luks-Container haben.

Die beim luksformat eingetippte Passphrase kann ich in einer Datei (ohne Zeilenschaltung) per '--key-file' benutzen.
Wenn ich das schon beim luksFormat mache, wird auch nicht nach einer Passphrase gefragt.

Die Passphrase resp. Key aus Slot0 scheint soweit nichts besonderes,
kann entfernt reps. ausgetauscht werden (solange noch eine weitere Passphrase resp. Key im Header existiert).


-----------------------------------------------------------

# update-initramfs -k 'uname -r' -c

# update-initramfs -k `uname -r` -c
Cannot create version 3.16.0-4-686-pae: already exists

Das mit den Single-Quotes ist korrigiert, es ginge auch

Code: Alles auswählen

... $(uname -r) ...

'-c' funktioniert jedoch nur, wenn noch keine initrd erstellt wurde
(was im allgemeinen nicht vorkommt),
sodaß '-u' der richtige Parameter ist.
(Hier spielt(e) auch noch eine Referenzierung in /var/lib/initramfs-tools/ mit,
in meinem jessie aber wohl nicht (mehr).)

[pachhenk]

Diesmal nicht frisch aufgesetztes System. Trotzdem noch ein Versuch mit der neuen Variante ('cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin --key-file key.file'):

Code: Alles auswählen

root@debian:~# dd if=/dev/urandom of=/dev/sdb bs=512 seek=1 count=60 
60+0 Datensätze ein
60+0 Datensätze aus
30720 Bytes (31 kB) kopiert, 0.769362 s, 39.9 kB/s
root@debian:~# dd if=/dev/sdb bs=512 skip=1 count=4 > tempKeyFile.bin
4+0 Datensätze ein
4+0 Datensätze aus
2048 Bytes (2.0 kB) kopiert, 0.00101361 s, 2.0 MB/s
root@debian:~# cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin --key-file key.file
Kein Schlüssel mit dieser Passphrase verfügbar.
root@debian:~# 

Die Datei key.file enthält die Passphrase welche ich beim installieren angegeben habe, und immer beim Start eingebe. Sie muss also valide sein, oder?

"Passphrase" IST gleichbedeutend "key".

?
So würde ich es auch verstehen. Aber die Fehlermeldung "Kein Schlüssel mit dieser Passphrase verfügbar." spricht ja eindeutig von zwei verschiedenen Dingen. Oder?


Kann ich denn irgendwie die zwei validen Schlüssel/Passphrasen (slot 0+1) ausgeben lassen? Dann wäre überprüfbar was er als zweite drin hat.

Schönen Tag noch, pachhenk

[rendegast]

Aber die Fehlermeldung "Kein Schlüssel mit dieser Passphrase verfügbar." spricht ja eindeutig von zwei verschiedenen Dingen. Oder?

Halte ich für eine unglückliche Formulierung, auch auf englisch.
"No key available with this passphrase."

Besser wäre vielleicht sowas
"Authorisation failed, no valid passphrase/key."

# cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin --key-file key.file
Kein Schlüssel mit dieser Passphrase verfügbar.

Die Datei key.file enthält die Passphrase welche ich beim installieren angegeben habe, und immer beim Start eingebe. Sie muss also valide sein, oder?

Nicht unbedingt, einmal habe ich schon die Zeilenschaltung angesprochen:

Code: Alles auswählen

# echo neues | cryptsetup luksDump ./disk --dump-master-key --key-file=-
No key available with this passphrase.

# echo -n neues | cryptsetup luksDump ./disk --dump-master-key --key-file=-
LUKS header information for ./disk
Cipher name:    aes
Cipher mode:    xts-plain64
....

# echo -n neues > 0pass
# file 0pass 
0pass: ASCII text, with no line terminators
# cat 0pass | cryptsetup luksDump ./disk --dump-master-key --key-file=-
LUKS header information for ./disk
Cipher name:    aes
Cipher mode:    xts-plain64
...

es könnte auch Probleme mit der Codierung von Sonderzeichen/Umlauten geben.
Insbesondere graphischen Editoren traue ich auch nicht in solchen Fällen,
zBsp. wegen gelegentlich verwendeter unsichtbarer Steuerzeichen.

Kann ich denn irgendwie die zwei validen Schlüssel/Passphrasen (slot 0+1) ausgeben lassen? Dann wäre überprüfbar was er als zweite drin hat.

Gute Frage, es gibt aber wohl nur mit Salt gehashte Einträge:

Code: Alles auswählen

# cat 0pass | cryptsetup luksAddKey ./disk 0pass --key-file=-
# cat 0pass | cryptsetup luksAddKey ./disk 0pass --key-file=-
# cat 0pass | cryptsetup luksAddKey ./disk 0pass --key-file=-
# cryptsetup luksDump ./disk
LUKS header information for ./disk
....

(letzteres bemerke! ohne Authorisierung,
wie der nette Grenzbeamte mit seiner live-CD)
-> keine Anzeichen, daß key/passphrase ja immer das selbe ist.
Ähnlich shadow, Du kannst zwar ein neues Password setzen,
das vorhandene aber nur per Brute-Force ermitteln.

[pachhenk]

das key.file hatte mit

Code: Alles auswählen

# echo Feufngl9ke.Lheikzhes. > key.file

erstellt.
Also keine Sonderzeichen, und Umbruch ist da wohl auch nicht nötig. Dennoch, wenn ich es mit der gleichen Passphrase so erstelle

Code: Alles auswählen

# echo -n Feufngl9ke.Lheikzhes. > key.file

dann kommt keine Fehlermeldung mehr.
Ein Erfolg, aber ich verstehe nicht den Grund dafür.
Allerdings arbeite ich momentan auf dem grafischen useraccount im Terminal, und nicht wie sonst auf tty*. Vielleicht erklärt das die Codierungsunterschiede. Jedenfalls hats jetzt geklappt.

Code: Alles auswählen

cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5
...
Key Slot 0: ENABLED
	...
Key Slot 1: ENABLED
	...
Key Slot 2: ENABLED
	...
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

[rendegast]

# echo -n .......... > key.file
dann kommt keine Fehlermeldung mehr.
Ein Erfolg, aber ich verstehe nicht den Grund dafür.

Oh sorry, ich habe nicht stark genug darauf hingewiesen,
daß die Zeilenschaltung ein Problem ist.

Vielleicht erklärt das die Codierungsunterschiede.

Nein, Deine Phrase/Key ist reines ASCII,
es war die Zeilenschaltung.

[pachhenk]

Das mit der Zeilenschaltung kam an, aber ich habs wohl nicht verstanden. Ich bin davon ausgegangen, dass mein Befehl eine Datei" mit nur einer Zeile erstellt".
Jetzt habe ich mit

Code: Alles auswählen

$ touch test1

und

Code: Alles auswählen

$ nano test1

gesehen, dass diese frische Datei zwar nur eine Zeile hat. Sobald ich aber nur einen Buchstaben tippe, hat es darunter eine leere Zeile, und somit wohl dazwischen auch einen Zeilenumbruch. Vermutlich ist es bei dem key.file auch so.

Wieder einen Schritt weiter, und das nächste Rätsel kriecht um die Ecke. Ich glaub ich mag jetzt lieber mein neues Notebook ausprobieren.

erstmal alles wie gehabt aber diesmal mit "-n"

Code: Alles auswählen

user@debian:~$ su
Passwort: 
root@debian:/home/user# cd
root@debian:~# dd if=/dev/urandom of=/dev/sdb bs=512 seek=1 count=60 
60+0 Datensätze ein
60+0 Datensätze aus
30720 Bytes (31 kB) kopiert, 0.0233267 s, 1.3 MB/s
root@debian:~# mount
...
/dev/sdb1 on /media/user/EOS_DIGITAL type vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=utf8,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
root@debian:~# dd if=/dev/urandom of=/dev/sdb bs=512 seek=1 count=60 
60+0 Datensätze ein
60+0 Datensätze aus
30720 Bytes (31 kB) kopiert, 0.0341674 s, 899 kB/s
root@debian:~# dd if=/dev/sdb bs=512 skip=1 count=4 > tempKeyFile.bin
4+0 Datensätze ein
4+0 Datensätze aus
2048 Bytes (2.0 kB) kopiert, 0.00100578 s, 2.0 MB/s
root@debian:~# echo -n Feufngl9ke.Lheikzhes. > key.file 
root@debian:~# cryptsetup luksAddKey /dev/sda5 tempKeyFile.bin --key-file key.file
root@debian:~# nano /etc/crypttab 
root@debian:~# systemctl --system daemon-reload
root@debian:~# cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5

UUID:          	c3dc122a-aa2f-4eb1-8e9b-b7652861f4b9

Key Slot 0: ENABLED
...
Key Slot 1: ENABLED
...
Key Slot 2: ENABLED
...
Key Slot 3: ENABLED
...
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
root@debian:~# reboot

Keine Fehlermeldung, und wieder ein Schlüssel mehr.
Und beim booten wie immer die Frage nach der Passphrase ganz am Anfang. Jetzt kommt aber noch eine zweite mitten drin. Hab ein Bild geschossen:
https://www.dropbox.com/s/3ca27e4zk72tb ... r.jpg?dl=0

Ich hab grad Probleme beim Partitioniren und verschlüsseln vom neuen Notebook. Ist mein erster Versuch verschlüsselt bei manueller Partitionierung. Ich geh jetzt erst mal Hausaufgaben machen.

---- EDIT 18.09.2015: ----
Tut mir leid, aber das Thema ist für mich ertst mal auf Eis. Das Leben liefert mir grad genug andere Baustellen.
Trotzdem vielen Dank für die Hilfe!
Habe viel gelernt und werde irgendwann damit weiterkommen.
Vorerst ist meine Lösung erstmal, dass ich nicht verschlüssele bevor ich nicht kapier was da läuft. Auch nicht das neue Notebook. Denn wenn ichs mach und was schief geht, müsste ich zum ammärikanischän Spezialisten mit dem passenden Rechenpotenzial. Und dann wärs ja ganz dahin, mit meinem Datenschutz.

Gruss Pachhenk