LUKS Encryption and Unattended boot on Headless Servers

The anaconda installer on Redhat-based Linux distributions provides the user with an option to encrypt the /home partition by selecting a simple check-box. This adds an obviously valuable security/privacy feature to the system if it's selected. Consequently, this prompts the user for a password during the boot process, which then decrypts the partition and mounts it in the designated location on the filesystem. The default behaviour is not very well suited for unattended reboots or on headless servers.

The crypttab(5) manual page provides great information on how to facilitate the process for unattended boots:

The /etc/crypttab file describes encrypted block devices that are set up during system boot.

Empty lines and lines starting with the "#" character are ignored. Each of the remaining lines describes one encrypted block device, fields on the line are delimited by white space. The first two fields are mandatory, the remaining two are optional.

Setting up encrypted block devices using this file supports three encryption modes: LUKS, TrueCrypt and plain. See cryptsetup(8) for more information about each mode. When no mode is specified in the options field and the block device contains a LUKS signature, it is opened as a LUKS device; otherwise, it is assumed to be in raw dm-crypt (plain mode) format.

The first field contains the name of the resulting encrypted block device; the device is set up within /dev/mapper/.

The second field contains a path to the underlying block device or file, or a specification of a block device via "UUID=" followed by the UUID.

The third field specifies the encryption password. If the field is not present or the password is set to "none" or "-", the password has to be manually entered during system boot. Otherwise, the field is interpreted as a absolute path to a file containing the encryption password. For swap encryption, /dev/urandom or the hardware device /dev/hw_random can be used as the password file; using /dev/random may prevent boot completion if the system does not have enough entropy to generate a truly random encryption key.


  • Create a keyfile that will serve as the console password replacement
  • Ensure DAC (Discretionary Access Control) rules add a level of security, as keyfile will be stored on persistent storage
  • Add the keyfile to the accepted method of decryption
  • Edit the /etc/crypttab file to instruct the system to use the keyfile instead of console passphrase

Create keyfile

Execute the following in the terminal as the root user to create the keyfile:

# dd if=/dev/urandom of=/root/keyfile bs=1024 count=4


Restrict the permissions to allow root user only to read the file:
# chmod 0400 /root/keyfile -c

Add to LUKS pool

Add the keyfile to the pool of accepted LUKS passwords/keyfiles for the selected device. The specific device name can be seen in the /etc/crypttab file as the first field, prepended by /dev/mapper/.
# cryptsetup luksAddKey /dev/mapper/luks-xxxx-UUID-xxx /root/keyfile luks

Update crypttab

Finally, update the /etc/crypttab file, replacing the third field (none) with the keyfile (/root/keyfile), as explained in the crypttab(5) manpage.
# vim /etc/crypttab
#Copy the line and comment out the first as backup, just in case.
#luks-xxxx-UUID-xxxx  UUID=xxxx-UUID-xxxx    none
luks-xxxx-UUID-xxxx  UUID=xxxx-UUID-xxxx    /root/keyfile

Popular posts from this blog

RHEL 7 and CentOS 7 syslog Rate Limit

Set Focus to Follow Mouse Cursor in GNOME 3

Centos 7 pulseaudio