Red Hat linux - "turn off" encryption checking

Question

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:

1. create a key file
2. apply the key file to the encrypted device ie. enabling the key for the device to be decrypted
3. Copy the key file to a removable not-encrypted device (eg. a flash drive)
4. append rd.luks.key=absolute path to key file : removable not-encrypted device to the booting kernel line in /boot/grub/grub.conf
5. On boot, make sure the removable not-encrypted device is inserted and can be referenced by the boot process.

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:

1. as above
2. as above
3. copy key file to /boot/keyfile.key
4. append rd.luks.key=/boot/keyfile.key:/dev/sda1
5. n/a

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:

• rd.luks.key=/boot/keyfile.key:/dev/sda1
• rd.luks.key=/keyfile.key:/dev/sda1
• rd.luks.key=/keyfile.key
• rd.luks.key=/someKeyFileThatIknowDoesNotExist.key:/dev/sda1

So my questions are as follows:

1. Is what I am trying to do possible
2. If yes, then...
   • where should I be putting the key file
   • what is the rd.luks.key value I should use to reference the key file

thanks in advance for any help

Answer 1

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:

• Disabling LUKS encryption
• RedHat Bug 751640 - dracut ignores crypttab keyfile

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)

Answer 2

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.