| View previous topic :: View next topic |
| Author |
Message |
Budoka
l33t
Joined: 03 Jun 2012
Posts: 777
Location: Tokyo, Japan
|
 Posted: Tue Sep 05, 2017 3:10 am Post subject: Serious LUKS/cryptsetup problem. HELP!!![SOLVED] |
 |
|
I want to punch a wall. OK. Now that I have that out of my system.
Please excuse the length of this post but I rather provide everything I did so that you guys and gals can give me the best feedback possible.
I have a 1TB external drive that I have been backing up to "semi" regularly. (Yeah I know. LOL) I had encrypted it with LUKS when initially setting up and hadn't encountered any problems until recently.
So I find I need to use this drive because my internal disk is failing. So yesterday I plug it into the USB port and when I am prompted for the password, enter it and..."you are not authorized to mount/unlock this device". The password wasn't incorrect and I tried for hours to figure out what the h*ll could be going on. Caps lock on, entering it incorrectly, etc So now I am freaking out because the back up I do have is encrypted and my key/password isn't unlocking the disk. So I decide to leave it alone for a day and really think if maybe I had used another password. This morning I connect the disk to my box...and when prompted for the password...enter the one I am pretty sure it was (the same one I tried for hours to use the previous day) and BAM I am in! User error the previous day...maybe.
So I was concerned that if I disconnect the disk and I run into the same problem I am screwed so decide to temporarily remove the password. I used
| Code: | cryptsetup luksRemoveKey /run/media/t***/1TB\ External/
|
(I edited part of the path because it contains identifiable information.) I don't get any feedback and it brings me back to the command line. Hmmm. Does this mean the password has been removed now? So in an over abundance of caution, I decided to add a new password. So I execute
| Code: | cryptsetup luksAddKey /run/media/t**/1TB\ External/
|
I get no feedback or prompts and I am returned to the command line. Hmmm. OK let me verify the password I do have...
| Code: | cryptsetup -y /run/media/tl**/1TB\ External/
|
returns
| Quote: | cryptsetup: Unknown action.
|
Then upon doing some further research, it appears that I should have been using the /dev path with these commands. So I verify that the drive is at sdc1 and I execute | Code: | | cryptsetup luksDump /dev/sdc1 |
It returns | Quote: | LUKS header information for /dev/sdc1
Version: 1
Cipher name: serpent
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 62 15 0b ec fe f8 f6 95 a3 7d 4e 4f fb cd 7c f7 e7 95 1e 77
MK salt: 46 ec 79 81 c4 fc 74 3b 57 1a b7 67 0f f3 6b ae
15 74 d5 50 4c 8d fb 63 5c 55 4c 73 e5 9b ad 10
MK iterations: 21500
UUID: 2436e768-7ae3-4a95-bf24-71e86efadb5d
Key Slot 0: ENABLED
Iterations: 86122
Salt: 68 fc d9 62 45 b4 c2 06 dc 47 22 01 d6 d2 0e c5
77 51 58 4a 29 4e 90 04 3b 18 d1 f1 c8 bf 57 f8
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 |
OK. Looking good. So I add a password to make sure I can get back in...
| Code: | # cryptsetup luksAddKey /dev/sdc1
Enter any existing passphrase:
Enter new passphrase for key slot:
Verify passphrase: |
Looks good. Entered twice and verified. Double check...
| Quote: | cryptsetup luksDump /dev/sdc1
LUKS header information for /dev/sdc1
Version: 1
Cipher name: serpent
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 4096
MK bits: 256
MK digest: 62 15 0b ec fe f8 f6 95 a3 7d 4e 4f fb cd 7c f7 e7 95 1e 77
MK salt: 46 ec 79 81 c4 fc 74 3b 57 1a b7 67 0f f3 6b ae
15 74 d5 50 4c 8d fb 63 5c 55 4c 73 e5 9b ad 10
MK iterations: 21500
UUID: 2436e768-7ae3-4a95-bf24-71e86efadb5d
Key Slot 0: ENABLED
Iterations: 86122
Salt: 68 fc d9 62 45 b4 c2 06 dc 47 22 01 d6 d2 0e c5
77 51 58 4a 29 4e 90 04 3b 18 d1 f1 c8 bf 57 f8
Key material offset: 8
AF stripes: 4000
Key Slot 1: ENABLED
Iterations: 1434171
Salt: 11 e5 94 06 67 e6 76 06 f4 da 2b 4c 14 41 4c 3d
80 6a 0a 0e 91 2f e5 41 2e 98 d8 e2 a1 9f 75 38
Key material offset: 264
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 |
OK, So slot 1 and 2 both have a password and are enabled. I didn't want to remove the first one to be "safe".
So I disconnect the drive...reconnect it...am prompted for the unlock password and YOU ARE NOT AUTHORIZED...blah blah. WTF. The password is NOT INCORRECT. So I can't open this disk again and neither password assigned is incorrect. No caps locks etc.
Strange thing is that at the CLI I can still execute...cryptsetup luksDump /dev/sdc1 get a return. I can also add another password. It prompts me for my current password which it ACCEPTS then prompts to enter new password. I didn't do so yet because I don't want to complicate this further.
OK. I haven't any doubt that there is something going on here that has more to do with me than crypsetup but not sure what it is.
I have got to get back into this drive.
The password I am entering is not incorrect or being mistyped.
WTF? Any ideas?
What am I doing wrong? Google-fu isn't helping.
Last edited by Budoka on Tue Sep 05, 2017 2:06 pm; edited 1 time in total |
|
| Back to top |
|
 |
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Tue Sep 05, 2017 3:34 am Post subject: |
|
|
| The error message about authorization seems like it isn't from cryptsetup. What is printed if you mistype the password when adding or removing a key? |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Tue Sep 05, 2017 3:50 am Post subject: |
|
|
I am not sure what DE you're running (KDE, Gnome, etc) but it may be a GUI bug. Plasma is currently bugged for basic things like removable media. The notification in the system tray says I can click to open it in Dolphin, but then it tells me I do not have permission. If I go to Dolphin and click the drive it mounts and I can access it just fine. I CAN use the system tray notification to safely remove the drive, however. Perhaps this is a similar issue? Tried mounting it via shell only?
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
Budoka
l33t
Joined: 03 Jun 2012
Posts: 777
Location: Tokyo, Japan
|
| Posted: Tue Sep 05, 2017 2:06 pm Post subject: |
|
|
| The_Great_Sephiroth wrote: | | I am not sure what DE you're running (KDE, Gnome, etc) but it may be a GUI bug. Plasma is currently bugged for basic things like removable media. The notification in the system tray says I can click to open it in Dolphin, but then it tells me I do not have permission. If I go to Dolphin and click the drive it mounts and I can access it just fine. I CAN use the system tray notification to safely remove the drive, however. Perhaps this is a similar issue? Tried mounting it via shell only? |
Wow. Thank you and everyone else who commented. This is exactly what it was. The "bug" is in both KDE and XFCE. Should I report this and if so where?
I nearly had a heart attack. LOL |
|
| Back to top |
|
|
The_Great_Sephiroth
Veteran
Joined: 03 Oct 2014
Posts: 1602
Location: Fayetteville, NC, USA
|
| Posted: Tue Sep 05, 2017 2:14 pm Post subject: |
|
|
I have no idea where, but this was not an issue until Plasma was released. To this day the notification icon will not allow users to mount USB attached storage on any Gentoo systems, but Dolphin does it just fine. Glad I could help and I'm glad your data is good.
_________________
Ever picture systemd as what runs "The Borg"? |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21602
|
| Posted: Wed Sep 06, 2017 1:03 am Post subject: |
|
|
As a bit of general advice, when you encounter a problem like this, bypass any intermediate layers. Use straight command-line tools to examine / modify the state.
Personally, I would consider your experience with cryptsetup verb path to indicate a user interface bug. Cryptsetup should have given you a sensible error message (telling you to use a file/device, not a directory) for each of those commands, not only for when you tried with -y. (It does exit with a nonzero error code in that case, but as you observed, no message, so if you do not think to check $?, there will be no indication what happened.) In particular, it looks to me like you got lucky here. It tried to interpret your path as a verb, and that was what provoked Unknown action, which in turn prompted you to reread the documentation and discover your usage error. |
|
| Back to top |
|
|
Budoka
l33t
Joined: 03 Jun 2012
Posts: 777
Location: Tokyo, Japan
|
| Posted: Tue Sep 26, 2017 2:35 am Post subject: |
|
|
| Hu wrote: | As a bit of general advice, when you encounter a problem like this, bypass any intermediate layers. Use straight command-line tools to examine / modify the state.
Personally, I would consider your experience with cryptsetup verb path to indicate a user interface bug. Cryptsetup should have given you a sensible error message (telling you to use a file/device, not a directory) for each of those commands, not only for when you tried with -y. (It does exit with a nonzero error code in that case, but as you observed, no message, so if you do not think to check $?, there will be no indication what happened.) In particular, it looks to me like you got lucky here. It tried to interpret your path as a verb, and that was what provoked Unknown action, which in turn prompted you to reread the documentation and discover your usage error. |
Agreed and lesson learned. I really almost had a heart attack. Haha.
Anyway, thanks everyone. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
