Schlüsselableitung funktioniert nicht.

C

cyrax

Member
Registriert
24 Sep. 2010
Beiträge
249
Hi,

ich bräuchte mal wieder ein Tipp von denen die es draufhaben !

Situation:
Frisch aufgesetztes Kubuntu auf SSD mit LMV komplett verschlüsselt. Jetzt möchte ich eine zweite HDD mit LUKS verschlüsseln und per Schlüsselableitung beim Start automatisch einbinden. Später sollen per fstab große Ordner dahin "ausgelagert" werden.

Die HDD habe ich dann über die Konsole nach dieser Anleitung so bearbeitet:
Code: 
   bst@bst-pc:~$ sudo -s
 [sudo] password for bst:  
 root@bst-pc:~# dd if=/dev/urandom bs=1M count=8 of=/dev/sdb
 8+0 Datensätze ein
 8+0 Datensätze aus
 8388608 Bytes (8,4 MB) kopiert, 1,06982 s, 7,8 MB/s
 root@bst-pc:~# cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/sdb
 

 WARNING!
 ========
 Hiermit überschreiben Sie Daten auf /dev/sdb unwiderruflich.
 

 Are you sure? (Type uppercase yes): YES
 Passsatz eingeben:  
 Verify passphrase:  
 root@bst-pc:~# cryptsetup luksOpen /dev/sdb usb-crypt    
 Geben Sie den Passsatz für /dev/sdb ein:  
 root@bst-pc:~# mkfs.ext4 /dev/mapper/usb-crypt
 mke2fs 1.42.9 (4-Feb-2014)
 Dateisystem-Label=
 OS-Typ: Linux
 Blockgröße=4096 (log=2)
 Fragmentgröße=4096 (log=2)
 Stride=0 Blöcke, Stripebreite=0 Blöcke
 30531584 Inodes, 122096134 Blöcke
 6104806 Blöcke (5.00%) reserviert für den Superuser
 Erster Datenblock=0
 Maximale Dateisystem-Blöcke=4294967296
 3727 Blockgruppen
 32768 Blöcke pro Gruppe, 32768 Fragmente pro Gruppe
 8192 Inodes pro Gruppe
 Superblock-Sicherungskopien gespeichert in den Blöcken:  
         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,  
         4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,  
         102400000
 

 Platz für Gruppentabellen wird angefordert: erledigt                         
 Inode-Tabellen werden geschrieben: erledigt                         
 Erstelle Journal (32768 Blöcke): erledigt
 Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt  
                                                                                                             
 root@bst-pc:~# mount /dev/mapper/usb-crypt /mnt                                                        
 root@bst-pc:~# cryptsetup luksDump /dev/sdb
 LUKS header information for /dev/sdb                                                                        
                                                                                                             
 Version:        1                                                                                           
 Cipher name:    aes                                                                                         
 Cipher mode:    xts-plain64
 Hash spec:      sha512
 Payload offset: 4096
 MK bits:        512
 MK digest:      33 cb dd 01 36 d2 40 8b eb f1 b7 77 68 60 5c 5b aa eb 39 62  
 MK salt:        98 22 52 94 ee a9 4d af 5b 05 a6 e8 53 27 91 c0  
                 e8 0e 85 db de 33 65 26 c7 39 22 5f 7e e7 7f 40  
 MK iterations:  10750
 UUID:           9f2d38c2-6601-4a88-90c0-52d1cf893ac9
 

 Key Slot 0: ENABLED
         Iterations:             43301
         Salt:                   ea 2a bd 7a 52 b9 29 3d 21 c9 f0 de 2a 15 c0 47  
                                 37 a5 e8 a1 f6 e5 39 5c 09 4a a0 93 46 52 43 1b  
         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
 root@bst-pc:~#

An sich alles leichter als gedacht. Wenn ich aber nun versuche nach dieser Anleitung die Schlüsselableitung zu erstellen kommt das:
Code: 
root@bst-pc:~# mkdir /mnt/ram && mount -t ramfs -o size=1m ramfs /mnt/ram && chmod 600 /mnt/ram
mkdir: das Verzeichnis »/mnt/ram“ kann nicht angelegt werden: Die Datei existiert bereits
root@bst-pc:~# /lib/cryptsetup/scripts/decrypt_derived usb-crypt /mnt/ram/tmp.key && cryptsetup luksAddKey /dev/sdb /mnt/ram/tmp.key && rm /mnt/ram/tmp.key
c2f1352a28a4bdeaca0dd035025d1475d4b7c0b700797e4fda7fc7a82bf952bf403e32e444947a241819ea42219a5ae168e9754723904bd2256e896da67c7824Geben Sie irgendeinen Passsatz ein: 
Failed to open key file.
root@bst-pc:~#

Woran kann das liegen, hab das schon versucht wenn das nicht gemounted ist aber daran liegt das nicht.

Gruß
cyrax
 
Hallo,

es liegt vermutlich am Verzeichnise /mnt/ram, welches nicht angelegt wird da schon eine Datei dieses Namens existiert. Damit wird auch die Datei /mnt/ram/tmp.key nicht angelegt ("Failed to open key file.")

Gibt es die Datei /mnt/ram ? Aus welchem Grund ? Kannst du sie gefahrlos löschen ?

Grüße, pepun
 
Zuletzt bearbeitet:
Hab ich mal gemacht dann kommt aber diese Fehlermeldung:
Code: 
bst@bst-pc:~$ sudo rm -rf /mnt
[sudo] password for bst: 
bst@bst-pc:~$ sudo cryptsetup luksOpen /dev/sdb mnt 
Geben Sie den Passsatz für /dev/sdb ein: 
bst@bst-pc:~$ sudo -s
root@bst-pc:~# mkdir /mnt/ram && mount -t ramfs -o size=1m ramfs /mnt/ram && chmod 600 /mnt/ram
mkdir: das Verzeichnis »/mnt/ram“ kann nicht angelegt werden: Datei oder Verzeichnis nicht gefunden
root@bst-pc:~#  /lib/cryptsetup/scripts/decrypt_derived usb-crypt /mnt/ram/tmp.key  && cryptsetup luksAddKey /dev/sdb /mnt/ram/tmp.key && rm  /mnt/ram/tmp.key
/lib/cryptsetup/scripts/decrypt_derived: failed to find usb-crypt in dmtable
 
kein wunder, denn statt /mnt/ram zu löschen, hast du /mnt gelöscht. folglich kannst du in /mnt nichts mehr anlegen.
vorsicht, wenn du mit root-rechten wild irgendwas löscht, ohne drauf zu achten, worum es sich handelt.
 
Vor allem wäre ich mit
Code: 
sudo rm -rf /irgendwas
EXTREMST VORSICHTIG!!
 
Hab hier so eine Hilfe für Konsolen Befehle liegen und in der wird der Befehl "rm -rf Verz so definiert: "Alle Dateien/Verzeichnisse unterhalb des Verzeichnisses Verz löschen."

Hab auf einer anderen Seite den Befehl "rm" nochmal in den verschiedenen Varianten gefunden, jetzt macht das auch Sinn das da alles weg war hatte das oben aber anders verstanden. So was blödes, na ja /mnt habe ich wieder erstellt und ich werde das nochmal der Reihe nach durchgehen, aber erst Morgen wenn ich fitter bin und mir nicht noch das System verhunze. Das wird ja wohl zu machen sein. Jedenfalls wieder etwas schlauer.
 
cyrax schrieb:
Hab hier so eine Hilfe für Konsolen Befehle liegen
Zum Vergrößern anklicken....
Diese bitte umgehend in die Rundablage entsorgen :facepalm:.

Es ist übrigens absolut unnötig vor einer Wiederholung das Verzeichnis zu löschen. Analog ist das abschliessende "rmdir /mnt/ram" überflüssig.

Insgesamt also:
Code: 
mkdir -f /mnt/ram && mount -t ramfs -o size=1m ramfs /mnt/ram && chmod 600 /mnt/ram
/lib/cryptsetup/scripts/decrypt_derived <Name_des_Ursprungsgeräts> > /mnt/ram/tmp.key && cryptsetup luksAddKey <Gerät> /mnt/ram/tmp.key && rm /mnt/ram/tmp.key
umount /mnt/ram

Bedingt durch den mount wird nichts ins darunterliegende Verzeichnis /mnt/ram geschrieben.
 
Zuletzt bearbeitet:
So ich habe das jetzt aufgegeben, da ich gesehen habe, dass schon die Verschlüsselung der gesammten Platte nicht richtig funktioniert, es wird immer nur eine Partition mit 6 MB angezeigt anstatt den 500 GB und es gibt Probleme beim schreiben.
Ohne den Adapter läuft alles normal, es scheint also an dem Zusammenspiel zwischen Adapter und dem X301 zu liegen, wie schon verlinkt gibnt es da auch andere Threads zu nur ohne Lösung. Da auf meine Anfrage wer das gleiche System laufen hat sich niemand gemeldet hat lasse ich das jetzt in Ruhem, da ich nicht noch mehr Zeit reinstecken möchte, schade ist es schon aber ich weiß einfach nicht weiter.

Falls ich nochmal Zeit habe werde ich das ganze in ein Ubuntun Forum verlagern und nochmals angehen.
 
Falls das cyrax oder jemand anderes nochmal ausgräbt: Bei mir hat die Schlüsselableitung nach der wiki-Anleitung funktioniert (mit bereits vorhandenem luks volume).

Der Fehler lag wahrscheinlich in dieser Zeile im ersten Post:
root@bst-pc:~# /lib/cryptsetup/scripts/decrypt_derived usb-crypt > /mnt/ram/tmp.key && cryptsetup luksAddKey /dev/sdb /mnt/ram/tmp.key && rm /mnt/ram/tmp.key
Zum Vergrößern anklicken....
Anstatt usb-crypt (= das neue Volume) sollte hier Mapper-Name des ursprünglichen Volumes stehen, im Beispiel wäre das die System SSD. Außerdem hat das Zeichen ">" gefehlt um den key überhaupt nach /mnt/ram/tmp.key zu schreiben.
 
Danke, da ich momentan keine Zeit habe mich mit dem ganzen zu beschäftigen, da das Book jetzt produktiv genutzt wird und die SSD im ACHI Modus installiert wurde. Da ich keine Zweite habe kann ich das nicht testen da der Adapter nur im Kompatibilitätsmodus stabil läuft und das System ist gerade bequem eingerichtet.
Werde mich aber in absehbarer Zeit nochmal damit befassen, da nach einem Erfolg wohl erstmal kein neues Book in Frage kommt.

@Boggler hast du Hardware mäßig denn eine ähnliche Konfiguration bei der das funktioniert hat (X301 und 2 HDD im Ultrabay?)
 
cyrax schrieb:
@Boggler hast du Hardware mäßig denn eine ähnliche Konfiguration bei der das funktioniert hat (X301 und 2 HDD im Ultrabay?)
Zum Vergrößern anklicken....

Ne, ganz und garnicht, das war eine hotgepluggte 3,5" Platte an meinem Desktop. Ich hab aber vor bald auch eine Platte im Ultrabay-Rahmen in der X201T Ultrabase so zu verschlüsseln. Hilft aber alles nix, wenn bei dir schon das normale Verschlüsseln nicht klappt. Ist es ein Nachbau-Adapter?
 
@Boggler: geh mal davon aus, daß die allerwenigsten Ultrabayadapter Zicken machen. Mit der Verschlüsselung hat es erst recht nichts zu tun.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben