How to pass password to cryptsetup from a memory variable?
I have a hard drive on my CentOS 6 system, not the OS drive, on which I have created a single partition encrypted with cryptsetup and luksOpen. Works fine. I mount it with this script
Code:
#!/bin/bash Performance has been quite robust and I like it so much I am considering encrypting a couple of other partitions. Not to get into a debate on passphrase philosophy... I prefer using one strong passphrase which I can remember for more than one partition rather than multiple phrases which I cannot remember and must write down. That said... I am trying to figure out how to pass the passphrase to cryptsetup within my script. I would propose to prompt myself for the passphrase, store it in a memory variable, pass it to cryptsetup in order to open and mount each partition and then allow the passphrase to evaporate when the script exits. Problem is... I see in the man page how to use a key file to pass information to cryptsetup but not a memory variable. I do not want to write the passphrase into a file which I would then have to worry about protecting. Any suggestions? TIA, Ken |
--key-file, -d name
Read the passphrase from file. If the name given is "-", then the passphrase will be read from stdin. In this case, reading will not stop at newline characters. Something like this (untested) Code:
#!/bin/bash |
Thanks linosaurusroot,
That looks like it might do the trick. I don't do enough scripting these days (since I retired). Ken |
I recommend not storing the password in a variable or a file, just let it prompt you for the password. You shouldn't need the --keyfile or -d option.
The main issue is what does bash do with your password when the script ends, I'll bet you it is still in RAM. |
Granted the password may still be in RAM. However, the encrypted partition(s) will be accessible - protected only by my screen saver/password or ssh/password etc. When the PC is shut down the passphrase will no longer be in RAM (unless a black helicopter lands and the RAM is frozen with freon or something :eek:
I agree with not storing the passphrase in a file. However, with several partitions or files to unlock each time the PC is booted... cryptsetup probably saves it somewhere in RAM while it is doing its thing. It would potentially store it several times in RAM. Ken |
Regardless of whether the passphrase is somewhere in RAM, all of the master keys are definitely in kernel memory and available to anyone with root access ("dmsetup table --showkeys ...") while the container is unlocked. cryptsetup does take pains to destroy any copies of keys or passphrases in its own memory space.
|
Quote:
|
Quote:
|
well... going off of linosaurusroot code and
Quote:
example.gpg contains a single line with newline of the password encrypted to my public key (thus only I can decrypt with my private key). Technically however, it can be anything in the file as long as it matches the password :) The private key is locked, this makes a single password entry to unlock multiple times. It will be your private keys password you'll need to enter however. Code:
#!/bin/bash |
Adding a solution to this old thread, keeping in mind the possible security implications of storing the password in a bash variable. If the 'echo $pass' shown above is not working for you, it is because the echo command is also passing a newline at the end of $pass to cryptsetup, which causes the luksOpen to fail. It tries to open the drive with 'password\n' instead of 'password'. You need to tell echo to not include the newline:
Code:
echo -n $pass | sudo cryptsetup luksOpen /dev/sdc1 sdc1 -d - |
Hello jtshoe and thanks for tickling this old thread. It is always interesting to look back and wonder "what was I thinking?" :D
My most recent approach to this issue is to use a passphrase to unlock the partitions. I have the passphrase stored on a zombie green USB flash drive (makes it easy to locate) which I plug in when I boot one of my serves. A script run as a systemctl one-time .service at startup will: 1 - look for the USB drive file system by its UUID 2 - if found it will mount it 3 - if the key is found on the mounted filesystem it will unlock and mount the encrypted file systems using the key 4 - unmount the flash drive file system If the required flash drive or key is not present the server boots normally but the drives stay locked. I can remove the flash drive once the server is fully booted up. I can then hide, lock up, loose or swallow the flash drive. If a black helicopter shows up I can simply shut down the server(s) and when they are brought back up the data drives will remain locked. Ken |
Would you mind sharing you one-time service script?
Would be very helpful, thx. |
Let me get the pieces together and do a little write up - so I can remember what I did :D I will get it posted later today.
Ken |
As requested, here is what I have at the moment. A key file is used to unlock the dmcrypt Luks encrypted partitions. The key file is stored on a particular flash drive with a specific UUID. This would prevent the key being placed on a random flash drive - unless the script was edited to reference the new UUID. I can of course clone the flash drive to another one with the same UUID by using Clonezilla or similar. All of this has nothing to do with anything as far as real security but it is an artifact from my original experimenting. As to what is actually happening...
My .service file is /usr/lib/systemd/system/unlock-n-mount.service and it contains Quote:
Quote:
Code:
17/11/05_09:37:15 AM starting unlock and mount script Bottom line, what I have presented does in fact work. Please feel free to ask if you have any questions - that helps me to learn as well. Of course I had to enable the thing to make it run Code:
systemctl enable unlock-n-mount Code:
[ken@taylor15 system]$ systemctl status unlock-n-mount.service -l |
All times are GMT -5. The time now is 10:04 PM. |