How would I Change passphrase of encrypted disks/array? Searched and haven't found anything yet.

Is this a stupid question or no one knows? I don't see it in the unraid 6.6.1 interface maybe I'm missing it.

Edited October 12, 20187 yr by EpicBrad

Google is your friend.

 

You'll find it in the status of encryption thread.

 

It's done from the command line, so no you won't see it in the web GUI. And the good news is that it doesn't result in any data loss.

 

 

I think it would be a great idea to have the gui change the encryption key. 

I need to change mine but with 15TB at risk I'm a little apprehensive to use the console.   

On 1/1/2019 at 10:32 PM, jj_uk said:

I think it would be a great idea to have the gui change the encryption key. 

I need to change mine but with 15TB at risk I'm a little apprehensive to use the console.   

 

I came here looking for an answer to the same question

 

I understand your apprehension, and it's not helped that we can't seem to find clear instructions in the Wiki (that i could see): https://wiki.unraid.net/index.php/UnRAID_Topical_Index#Encryption and the forum post above is many pages long, isn't current (as is the nature of forums) and anyone could put an incorrect solution that be followed. I had trouble following the conversation, let alone finding the specific instructions to change the password. What i did see was something about adding and then removing keys. I believe there's an easier way but i don't know how to apply it to unRAID (i.e. the /dev/??? - no idea what to put there) so try it at your own risk:

root@tower:~# cryptsetup luksChangeKey /dev/??? 

Enter LUKS passphrase to be changed:

Enter new LUKS passphrase:

 

I'm new to unRAID, but it seems that the Wiki is very out of date in many cases so its hard to find current and accurate stuff there. I was looking up sleep/wake stuff and it was so damned complicated. I found the easy way via Space Invader on YouTube (and another guy on YouTube). Clearly that Wiki page is outdated (or at best incomplete). I realise this isn't Arch Linux, but now there is an amazing Wiki!

Edited November 15, 20196 yr by Derek_

@Derek_, limetech's post in the thread referenced above has it exactly right.

 

In brief, you can either use "cryptsetup luksAddKey" followed by "cryptsetup luksRemoveKey", or just use "cryptsetup luksChangeKey" which, in most instances, just bundles these two actions together.

 

The safest way would be to do a whole set of luksAddKey, test that everything works with the new key (array stop/start from GUI etc.), and then use luksRemoveKey to clean up.

 

The /dev/ devices you must use as operands for cryptsetup are /dev/md1 for disk1, /dev/md2 for disk2 and so forth. Note that you have to do it unto all of your encrypted array disks(!), and make very sure you assign the exact same key to all of them.

 

Another thing you want to be mindful of is your cache. If you have configured it to be encrypted XFS, you'll need to take care of it, too. To figure out the correct device name for the operation, you can check out your GUI main tab. Under "Cache Devices" you will find your cache drive. There, you will have the device name in parenthesis under "Identification". So if, for example, you find "(sdc)" in there, your parameter for the luksAddKey / luksRemoveKey would be /dev/sdc1 (note the "1" suffix, indicating the first partition).

 

(Edited - corrected cache reference)

 

Edited November 15, 20196 yr by doron

Thanks @doron, that is somewhat clearer. Should the array be stopped before doing the deed?

37 minutes ago, Derek_ said:

Thanks @doron, that is somewhat clearer. Should the array be stopped before doing the deed?

Absolutely not. You must do it when the array is started. In fact when it's not started you will not be able to follow the instructions above, as the /dev/mdX devices will not be available.

On 11/15/2019 at 10:53 PM, doron said:

Absolutely not. You must do it when the array is started. In fact when it's not started you will not be able to follow the instructions above, as the /dev/mdX devices will not be available.

Thanks again. What about Dockers and VMs - should they be stopped?

Thanks again. What about Dockers and VMs - should they be stopped?

I don't see a reason to stop anything. The key slots are fixed and are manipulated in place. Your data is not affected during the process.
Just do the full set of luksAddKey, stop/start when convenient to see that the new key works, then a set of luksRemoveKey.

@doron Thank you. I do appreciate your patience with me

 

Where X is the disk number, and done for all encrypted disks either array or cache:
# cryptsetup luksAddKey /dev/mdX
reboot & test
# cryptsetup luksRemoveKey /dev/mdX
reboot & test

 

I did per instructed, rebooted, used the new key and everything was fine. My only docker functioned normally and i could read data i had on the array and in the cache drives (very little atm). I copied a fresh file across and it was fine too. Removed the old password per instructions and rebooted. Tried the old password: as expected - it doesn't work. New password: still works.

 

I did not do my 'quick way' (change, rather than add > remove) because i agree it is far more risky, and i think maybe it'd cause problems with anything was running. So i didn't do it, and i don't recommend anyone else tries it.

 

So THANK YOU (and 'limetech').

 

Last question(s): i read that there's 8 key slots available to use. Do i still have 7 left, or is a used/deleted slot forever taken? And does will it matter what slot this, or any other key is in? Does this new key now revert to the 1st slot?

 

 

@Derek_, glad it worked well for you.

 

23 minutes ago, Derek_ said:

 

Where X is the disk number, and done for all encrypted disks either array or cache:
# cryptsetup luksAddKey /dev/mdX
reboot & test
# cryptsetup luksRemoveKey /dev/mdX
reboot & test

Just for other readers of this thread - note that for the array disk you must use the /dev/mdX devices (not /dev/sdX), whereas for the encrypted cache drive you need to find the actual device name /dev/sdX and then use it adding "1" for first (only) partition on that disk. You do not do this for parity drives - they are not LUKS devices.

23 minutes ago, Derek_ said:

So THANK YOU (and 'limetech').

You're very welcome.

23 minutes ago, Derek_ said:

Last question(s): i read that there's 8 key slots available to use. Do i still have 7 left, or is a used/deleted slot forever taken? And does will it matter what slot this, or any other key is in? Does this new key now revert to the 1st slot?

Great question. You do have 7 left. What technically happened is that for each drive, you added a key into slot #1 (second slot), then restarted and tested, and then removed the key from slot #0, marking it "disabled". The next time you do the same exercise (assuming no fiddling in between, I'm simplifying this a bit), you will add a key into the first free slot - which will now be #0. 

So if I understand your underlying question, you can repeat this process an infinite number of times - as long as you remove the old keys. The eight slots can keep up to eight keys simultaneously. 

19 minutes ago, doron said:

Just for other readers of this thread - note that for the array disk you must use the /dev/mdX devices (not /dev/sdX), whereas for the encrypted cache drive you need to find the actual device name /dev/sdX and then use it adding "1" for first (only) partition on that disk. You do not do this for parity drives - they are not LUKS devices.

Yes, i forgot to mention that parity wasn't part of it, i guess i implied it as parity isn't encrypted. But thank you for clarifying that.

 

I found it quite handy to use the terminal command:

# lsblk

...which outputted all my devices. Anything with the word "crypt" against it was what i added/removed the password for. I've trimmed my output to just show the encrypted devices, so you won't see parity or anything else. Below, sdX is my cache (btrfs encrypted RAID1), mdX is my data array but not the parity disk as @doron has mentioned (XFS encrypted):

sdb        8:16   0 238.5G  0 disk  
└─sdb1     8:17   0 238.5G  0 part  
  └─sdb1 254:2    0 238.5G  0 crypt		<<< This one
sdc        8:32   0 238.5G  0 disk  
└─sdc1     8:33   0 238.5G  0 part  
  └─sdc1 254:3    0 238.5G  0 crypt /mnt/cache	<<< This one
md1        9:1    0   5.5T  0 md    
└─md1    254:0    0   5.5T  0 crypt /mnt/disk1	<<< This one
md2        9:2    0   5.5T  0 md    
└─md2    254:1    0   5.5T  0 crypt /mnt/disk2	<<< This one

The community here is really good Glad i paid up, i'm getting the hang of it

 

45 minutes ago, Derek_ said:

I found it quite handy to use the terminal command:

# lsblk

Yep, that could come really handy, even allowing you to script the whole process, if you pass it via a simple filter, e.g.

lsblk | grep " crypt " | sed -r 's/[^a-z]*// ; s/([a-z0-9]*) .*/\1/'

45 minutes ago, Derek_ said:

The community here is really good Glad i paid up, i'm getting the hang of it

 

Welcome aboard! 🙂

22 hours ago, doron said:

Yep, that could come really handy, even allowing you to script the whole process, if you pass it via a simple filter, e.g.

lsblk | grep " crypt " | sed -r 's/[^a-z]*// ; s/([a-z0-9]*) .*/\1/'

Welcome aboard! 🙂

Simple.. yeah 😮

40 minutes ago, Derek_ said:

Simple.. yeah 😮

Isn't it?... 🙂

All it does is take lsblk output lines that contain "crypt", and extract the first alphanum token out of them. Run the line on your server and see what you get.

 

Might be a good idea to write a script to do a key change amass. If I get some spare time later today I might hack up something.

Yeah, nah   I'm far too much a noob, and i'm not likely to change the encryption password very often at all.

 

But if you have this scripting wizardry, perhaps suggest it to the devs who can GUIfy it and thank you for your brilliance

On 11/20/2019 at 8:07 AM, Derek_ said:

But if you have this scripting wizardry, perhaps suggest it to the devs who can GUIfy it and thank you for your brilliance

Wizardry huh. More like rustiness. In fact, even that filter was kinda heavy-handed - a better version would have been

lsblk | grep "crypt" | sed -r 's/[^[:alnum:]]*([[:alnum:]]*) .*/\1/'

At any rate, I did hack up that script. You can find it here.

 

EDIT: Moved the script to its own thread.

 

Edited November 26, 20196 yr by doron

Sorry to bump this ancient thread, but are these instructions still current? 

 

Also, do I need to change the key on the parity drive or does it not matter?

Edit: I see above that I do not.

 

Thanks

Edited August 16, 20241 yr by Teeman

@Teemanyou now have a plugin that takes care of that.

I don't want to change immediately, just add a new key. So that's why I want to do it manually.

4 hours ago, Teeman said:

I don't want to change immediately, just add a new key. So that's why I want to do it manually.

In that case yes, the guidance above holds. The "lsblk" filter will list the devices that are candidates for the transaction. The array must be started. The parity drives will not be on that list.