unraid-newenckey: Change your drive encryption unlock key

[doron]

10 minutes ago, Jclendineng said:

a cosmic ray or random bit flip happened hosing my key slot.

How many data drives are in your array? Just one?

[doron]

19 hours ago, doron said:

How many data drives are in your array? Just one?

@Jclendineng, if I was unclear, that was a genuine question. Since you suspected a bit flip, that would be a viable hypothesis only if you have exactly one data drive in the array. Each drive has its own LUKS header; the chance of a bit flipping in all of them at once is practically zero.

[Jclendineng]

53 minutes ago, doron said:

@Jclendineng, if I was unclear, that was a genuine question. Since you suspected a bit flip, that would be a viable hypothesis only if you have exactly one data drive in the array. Each drive has its own LUKS header; the chance of a bit flipping in all of them at once is practically zero.

I have 1 data drive, but I also have encrypted cache drive, with its own header, the keyfile doesn't work for either header anymore, but the header itself doesnt look corrupted meaning something must be wrong with the keyslot...in any case this is on me for not backing up the header.

 

Edit. 1 data, 1 parity and 1 cache.

Edited March 6, 2023 by Jclendineng

[doron]

1 hour ago, Jclendineng said:

I have 1 data drive, but I also have encrypted cache drive, with its own header, the keyfile doesn't work for either header anymore, but the header itself doesnt look corrupted meaning something must be wrong with the keyslot...in any case this is on me for not backing up the header.

If you have both a data drive and a cache drive, and both stopped being openable with your keyfile at the very same time, - I'd bet your key slots are fine. Chances are, either (a) you have some cabling issue or controller issue, or (b) something happened to the keyfile (have you backed it up? Perhaps use a backup copy).

I'd put lower chances on (c) someone did change the key on your drives or (d) some malware played nasty games with your LUKS headers.

Another thing - have you run "memtest" recently?

[Jclendineng]

On 3/6/2023 at 1:23 PM, doron said:

If you have both a data drive and a cache drive, and both stopped being openable with your keyfile at the very same time, - I'd bet your key slots are fine. Chances are, either (a) you have some cabling issue or controller issue, or (b) something happened to the keyfile (have you backed it up? Perhaps use a backup copy).

I'd put lower chances on (c) someone did change the key on your drives or (d) some malware played nasty games with your LUKS headers.

Another thing - have you run "memtest" recently?

I thought memory (even though its relatively new ram...) but I pulled the drives, mounted them on a different server and attempted the unlock with the same results, so I have ruled out hardware (minus anything hardware related that might have done this)

[doron]

1 hour ago, Jclendineng said:

I thought memory (even though its relatively new ram...) but I pulled the drives, mounted them on a different server and attempted the unlock with the same results, so I have ruled out hardware (minus anything hardware related that might have done this)

So you believe both LUKS headers got corrupted simulateously?

Have you tried a backup copy of the keyfile?

[Jclendineng]

17 hours ago, doron said:

So you believe both LUKS headers got corrupted simulateously?

Have you tried a backup copy of the keyfile?

Yes I have it in a private git repo that I call on startup to unlock, so its versioned and is the same. I also had a backup on a private cloud that also didn't work. Very odd but I'm assuming the simplest answer is ram issue or hardware issue, perhaps a controller is going bad, the board is pretty old, and its a gigabyte consumer board meaning anything possible

[doron]

Perhaps this calls for a new feature of this little tool - back up my LUKS headers. I'll take a look to see what it takes to do that reliably for the entire array. @Jclendineng

Edited March 8, 2023 by doron

[Rendeaust]

Hey, this 3 year old inactive account just want to say thanks.

 

Basically I setup encryption for one of my drives for the first time yesterday, copied shares over to it already, then panicked when I realized my past self must've forgotten to save the encryption key in my password manager because I can't see it there.

 

I think I remember the key... but I want a way to verify if it's correct without stopping the array because I'd be toast if it's incorrect (without making a back up first anyway).

 

Your tool did exactly what I needed to do and verified my memory serves me correctly today. I just exited on the prompt for new passphrase as soon as it verified my key was right. Big kudos to you, dude. You just saved my ass.

[Hugh Jazz]

hi! is it possible to use this tool just to verify my password without changing it? its been a while since i mounted and will have to hunt down my password, which i'm a bit unsure of... 😕

[doron]

15 minutes ago, Hugh Jazz said:

hi! is it possible to use this tool just to verify my password without changing it?

Sure; just run the tool as you normally would. Once asked for the old (current) password/key, provide it. The tool then tries this key on each available drive. If it can't open any of them, it will shout. If you're asked for the new key, it means the key is good; just hit ^C (ctrl-C) and leave.

[Hugh Jazz]

18 minutes ago, doron said:

Sure; just run the tool as you normally would. Once asked for the old (current) password/key, provide it. The tool then tries this key on each available drive. If it can't open any of them, it will shout. If you're asked for the new key, it means the key is good; just hit ^C (ctrl-C) and leave.

thank you very much for the fast replay! looks like a neat tool!

 

if i choose a keyfile, can i just use any random file i want and store it on a usb stick or something?

[doron]

On 8/4/2023 at 12:37 AM, Hugh Jazz said:

if i choose a keyfile, can i just use any random file i want and store it on a usb stick or something?

Yes, any file, on the location of your choice. Make very sure though:

1. It is accessible to Unraid during (re)starting the array
2. It is kept intact, bit-wise, throughout the life of the array (do not trust a copy/paste of its contents, for example, etc.)
3. You have a good backup copy in a safe place you remember... If you lose it, you lose your entire array and anything else that's encrypted using this keyfile.

This all may sound trivial, but - I've seen all of those happen. Better safe.

[Jabberwocky]

Just wanted to say thank you for the script! Would be nice to have this functionality as well as a backup of the luks header on the regular UI though (maybe as an optional / password-protected part of the backup of the usb stick?).

 

For everybody who is looking for a way to change your passphrase:

• Backup your luks header with this script (it's in the zip file and NOT in the post) to a location of your chosing (better safe than sorry..):

 

• Install the script from this post from the app store called "New Unlock Key for Encrypted Drives"

 

• Run the script on the CLI to change your passphrase

 

 

Edited February 11 by Jabberwocky

[_cjd_]

Just went through this and had a bit of a scare; despite backups and testing, when I actually stopped the array nothing I did was successful getting it to start up again despite being super careful and confident that I had the right keyfile...

For whatever reason, before trying to fiddle with recovery measures, I decided to add the bits to the go file to fetch from a remote server and auto-start and reboot (all previously tested). And... it booted up perfectly fine straight into a started array.

That said, I would have loved a non-destructive option here (I almost went and did this all manually to just add the new key...) - as would my afternoon stress levels. In the end, all was well though. So thanks for a handy script.

[doron]

Thanks @_cjd_ for reporting this. I'm not sure I understand what actually went wrong? Why did the stress happen in the 1st place?

Sent from my tracking device using Tapatalk

[_cjd_]

1 hour ago, doron said:

Thanks @_cjd_ for reporting this. I'm not sure I understand what actually went wrong? Why did the stress happen in the 1st place?

I wish I knew. I changed the key, then ran the script again just through confirming the key (but without then replacing it); that all worked.

I then stopped the array and tried to start it; it failed (it didn't let me choose a passphrase or key until after it failed once, after which it prompted). At that point, selecting the keyfile did not allow the array to start. I tried sourcing the image from a few different places just in case one was unexpectedly corrupted (including manually copying from the remote host), none of them worked. I do probably get overly stressed about stuff like this (even with layers of backup options too)

I have no idea why rebooting changed anything, but it did; and just to be sure, I ran the script again (cancelling out before providing a new passphrase or keyfile) and indeed, it's passing with the keyfiles I was trying when things weren't working.

More than anything, I figured it was worth sharing in case anyone else runs up against the same odd behavior.

On the off chance it matters, this system is on 6.12.8

Edited February 25 by _cjd_

[doron]

@_cjd_some stress is certainly understandable in such situation 😉 

At any rate you may have bumped unto an Unraid bug (or feature).

It might be good to have the script recommend a server reboot once done.