eternaltyro / cryptsetup

Since Google code is shuttering...
http://code.google.com/p/cryptsetup
GNU General Public License v2.0
0 stars 0 forks source link

LUKS, No key available with this passphrase. #177

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hello, 

I worked on standard, fresh Fedora 19 installation, had disk encrypted with 
Luks, default installer setup using lvm:

Short after reboot (I mounted encrypted hdd to other computer using cryptsetup 
-luksOpen ~~, copied some data and reboot, didn't unmount it correctly) I met a 
problem: 

All system partition except /dev/sdb2 (home) are accessible during boot 
normally - password for / and swap is accepted. But system does not start; 
after accepting passphrase normal way, it asks next about pass for /home 
partition - few times, and next drop into emergency shell. I 100% sure that I 
provide correct password, root and swap partition are mounted correctly.

It look as:

fdisk -l
Urządzenie Rozruch   Początek      Koniec   Bloków   ID  System
/dev/sdb1   *        2048     1026047      512000   83  Linux
/dev/sdb2         1026048   867686399   433330176   83  Linux
/dev/sdb3       867686400   972543999    52428800   83  Linux
/dev/sdb4       972544000   976773119     2114560    5  Extended
/dev/sdb5       972548096   976773119     2112512   83  Linux

I tried to unlock /dev/sdb2 partiton from second computer (also Fedora 19, both 
system updated daily), using cryptsetup, eg.

[root@localhost piotr]# cryptsetup luksOpen /dev/sdb3 c1
Enter passphrase for /dev/sdb3: 
and is ok, I can mount it, but: 

root@localhost piotr]# cryptsetup luksOpen /dev/sdb2 c2
Enter passphrase for /dev/sdb2: 
No key available with this passphrase.
Enter passphrase for /dev/sdb2: 
No key available with this passphrase.
Enter passphrase for /dev/sdb2: 
No key available with this passphrase.
[root@localhost piotr]# 

for /dev/sdb2 i have "No key available with this passphrase" message

Luks partition seems to be correct: 

root@localhost piotr]# cryptsetup -v isLuks /dev/sdb2
Command successful.

Heres dump from my header: 

cryptsetup luksDump /dev/sdb2
LUKS header information for /dev/sdb2

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        512
MK digest:      54 97 2b 30 10 4c 23 db 49 b6 71 97 fe a2 f5 e4 e6 eb ed 15 
MK salt:        ae a7 e6 67 e5 87 8d 72 35 33 1c b7 67 4f 80 f2 
                26 c1 02 19 46 76 a5 9f 54 f7 68 ea b7 7b f1 1c 
MK iterations:  43375
UUID:           1e582a36-28eb-415d-9ce9-acd57d076324

Key Slot 0: ENABLED
        Iterations:             194824
        Salt:                   44 c2 26 99 b8 29 5e 5b 23 f1 71 c4 a3 f8 16 ca 
                                c7 a2 7c f7 92 ff 2d 01 c1 b7 93 94 7b 5b b6 df 
        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

I also tried deal with locale, eg:

LANG=en_US cryptsetup luksOpen /dev/sdb2 c3
Enter passphrase for /dev/sdb2: 
No key available with this passphrase.

but with no effect.

Here is content of my crypttab:

luks-f5516cbe-f746-4876-b70e-3e22be73ef35 
UUID=f5516cbe-f746-4876-b70e-3e22be73ef35 none
luks-1e582a36-28eb-415d-9ce9-acd57d076324 
UUID=1e582a36-28eb-415d-9ce9-acd57d076324 none
luks-d52b03d1-f9b4-4e16-9f06-3edeb4e02d64 
UUID=d52b03d1-f9b4-4e16-9f06-3edeb4e02d64 none

After few days working with this problem i stuck; cant access my data. .. 
anyone know what is going on ?

Original issue reported on code.google.com by pi...@medelin.net on 11 Oct 2013 at 11:07

GoogleCodeExporter commented 9 years ago
I would say keyslot (not the visible header) is corrupted.
Please provide output from keyslot checker as Arno already suggested here:
http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/6896
(to RH bug tracker please).

Anyway, this is not upstream issue but Fedora distro problem, you already 
reported it there https://bugzilla.redhat.com/show_bug.cgi?id=1013595 , so 
let's track it there.

Original comment by gmazyl...@gmail.com on 12 Oct 2013 at 6:59