I have a Red Hat 6.5 Linux implementation that uses LUKS to encrypt the system and - for reasons that aren't relevant - I would like to "turn off" boot encryption checking for a period of time. It will be turned on again at some point so even if it is possible to remove the LUKS encryption entirely, that is not a solution I am interested in.
What I want is to auto-provide the LUKS password on boot so that it doesn't need to be entered manually - thus logically "turning off" encryption even though still actually enabled.
Now, while this is straightforward for secondary devices ie. by creating a key file, applying the key file to the encrypted devices and amending /etc/crypttab to reference the key file, one still has to enter at least one password on boot - because, if the primary device is LUKS encrypted, then it first has to be decrypted before /etc/crypttab is accessible.
There is a way I have seen of removing the requirement to enter the initial password which is:
This all looks good, except that I don't want a removable not-encrypted device involved. I simply want the server to boot as though it wasn't encrypted.
The only way I can see to achieve this is to replace removable not-encrypted device with normal not-encrypted device. In which case the boot process would read normal not-encrypted device, get the key and use it to decrypt the encrypted devices ...hey presto encryption is disabled.
The only device I can find on my system that fulfills the normal not-encrypted device criteria is /dev/sda1 ie. /boot , so I performed the above steps with step 3 and 4 as follows:
Unfortunately I can't seem to get this to work.
Red Hat boots and I don't get asked for a password (as expected), however towards the end of the boot process, it fails with "Kernel panic - not syncing: Attempted to kill init! ..."
This behaviour is identical whichever of the following I use:
So my questions are as follows:
thanks in advance for any help
After much digging I have finally found the answer (which works on both CentOS 6.6 and 7). Thanks to the following 2 resources in particular:
What I did is as follows (as root user):
# insert a password into my chosen password file
echo -n "anypassword" > /etc/mypasswdfile
# instruct the LUKS device to take the password from my password file
vi /etc/crypttab and replaced the 3rd parameter "none" with "/etc/mypasswdfile"
# add my password file as a valid key for the luks device
cryptsetup luksAddKey /dev/sda2 /etc/mypasswdfile
# configure dracut to add the following 2 items to the initramfs (so accessible at boot)
echo 'install_items="/etc/mypasswdfile /etc/crypttab"' > /etc/dracut.conf.d/99-mypwfile.conf
# instruct dracut to apply the configuration
dracut -f
# reboot the server
reboot
And that's it. The server reboots without requesting a password. (This can be disabled/enabled at will by removing/adding the keyfile from the LUKS device via the cryptsetup command)
I never had a need for this, but can certainly relate to its usefulness. So, your post prompted me to review how this could be done, and the only way I see is to get the unlocking scripts/details into initramfs.
This is a much easier process in debian based distros, because it is possible to inject scripts into initramfs via initramfs-tools .. dynamically at boot. See this and this and this
RHEL based distros would require the use of dracut (in recovery mode) to rebuild initramfs. So, I think you can solve this problem by rebuilding the initramfs and injecting your unlocking scripts in there .. that way we can be sure your root/boot device have been unlocked before the kernel needs to mount them. This Gentoo thread suggests a way to get at and modify initramfs contents. As to the best way to inject your unlock scripts in initramfs, I am not sure about that.
I will certainly have a go at this when I am less busy. It does sound a rather useful thing to be able to setup.