EpicBrad Posted October 12, 2018 Share Posted October 12, 2018 How would I Change passphrase of encrypted disks/array? Searched and haven't found anything yet. Quote Link to comment
EpicBrad Posted October 12, 2018 Author Share Posted October 12, 2018 (edited) 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, 2018 by EpicBrad Quote Link to comment
JonathanM Posted October 12, 2018 Share Posted October 12, 2018 Google is your friend. Quote Link to comment
tr0910 Posted October 13, 2018 Share Posted October 13, 2018 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. Quote Link to comment
jj_uk Posted January 1, 2019 Share Posted January 1, 2019 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. Quote Link to comment
Derek_ Posted November 15, 2019 Share Posted November 15, 2019 (edited) 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, 2019 by Derek_ Quote Link to comment
doron Posted November 15, 2019 Share Posted November 15, 2019 (edited) @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, 2019 by doron 1 Quote Link to comment
Derek_ Posted November 15, 2019 Share Posted November 15, 2019 Thanks @doron, that is somewhat clearer. Should the array be stopped before doing the deed? Quote Link to comment
doron Posted November 15, 2019 Share Posted November 15, 2019 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. 1 Quote Link to comment
Derek_ Posted November 17, 2019 Share Posted November 17, 2019 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? Quote Link to comment
doron Posted November 17, 2019 Share Posted November 17, 2019 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. 1 Quote Link to comment
Derek_ Posted November 17, 2019 Share Posted November 17, 2019 @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? Quote Link to comment
doron Posted November 17, 2019 Share Posted November 17, 2019 @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. 1 Quote Link to comment
Derek_ Posted November 17, 2019 Share Posted November 17, 2019 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 Quote Link to comment
doron Posted November 17, 2019 Share Posted November 17, 2019 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! 🙂 1 Quote Link to comment
Derek_ Posted November 18, 2019 Share Posted November 18, 2019 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 😮 Quote Link to comment
doron Posted November 18, 2019 Share Posted November 18, 2019 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. Quote Link to comment
Derek_ Posted November 20, 2019 Share Posted November 20, 2019 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 Quote Link to comment
doron Posted November 20, 2019 Share Posted November 20, 2019 (edited) 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, 2019 by doron 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.