Possible to setup open LUKS without entering a password at boot time?

JockVSJock

Labbing on open LUKS tonight, and things are going well.

Was wondering if its possible not to have to enter a password for the partition that is encrypted, while the RHEL OS is booting up? I mean is there any other place to enter it so that the OS boots up without having to enter the password? Hopefully what I'm asking makes sense.

I did notice that under /boot/grub.conf there is an entry

rd_NO_LUKS

Jang in Chp 5 refers to this entry as

disables detection of volumes encrypted to the LUKS system.

So that means if I were to remove that, it won't detect the volume that is encrypted?

brombulec

Of course it's possible to mount encrypted filesystem without interactive password request.
Follow these steps and you can mount on boot filesystem:
Part 1: preparing and testing

1. choose an empty filesystem (for example /dev/sdc1) - it will be formatted and encrypted!!!
2. # cryptsetup luksFormat /dev/sdc1
and enter a passphrase
3. # cryptsetup luksOpen /dev/sdc1 name_of_your_filesystem
4. # mkfs.ext4 /dev/mapper/name_of_your_filesystem
5. # mkdir /mnt/encrypted_fs
6. # mount /dev/mapper/name_of_your_filesystem /mnt/encrypted_fs
7. # umount /mnt/encrypted_fs
8. # cryptsetup luksClose name_of_your_filesystem

Part 2: add key and mount on boot

1. # dd if=/dev/urandom of=/etc/encrypted/key bs=2048 count=2
2. # chmod 600 /etc/encrypted/key; chown root:root /etc/encrypted/key
3. # cryptsetup luksAddKey /dev/sdc1 /etc/encrypted/key
and enter a passphrase.
4. create file /etc/crypttab with the following contents:
name_of_your_filesystem /dev/sdc1 /etc/encrypted/key
5. change /etc/fstab file and add the following line:
/dev/mapper/name_of_your_filesystem /mnt/encrypted_fs ext4 defaults 1 2
The definition of all fstab fields are available on the internet or man pages.

And that's it

rd_NO_LUKS is a kernel parameter - the kernel will not look for LUKS encrypted volumes. therefore will be no attempts to find key files,passphrase prompts and so on.

asummers

It's worth noting that if anything is likely to go wrong - it is probably going to be /etc/crypttab. It is not possible to test it using a mount -a command and an error prevents the o/s from booting

brombulec

asummers wrote: »

It's worth noting that if anything is likely to go wrong - it is probably going to be /etc/crypttab. It is not possible to test it using a mount -a command and an error prevents the o/s from booting

I disagree - If you know what you're doing there is no place for an error.
And you can always add rd_NO_LUKS to kernel parameters or boot from CD/DVD/USB and fix the crypttab file. Of course you have to protect/backup/copy to safe place your key file

asummers

brombulec wrote: »

I disagree - If you know what you're doing there is no place for an error.
And you can always add rd_NO_LUKS to kernel parameters or boot from CD/DVD/USB and fix the crypttab file. Of course you have to protect/backup/copy to safe place your key file

You are of course entitled to your opinion. I stand by my comment. The crypttab is an area which can and does cause issues - extra care should be taken.

JockVSJock

asummers wrote: »

It's worth noting that if anything is likely to go wrong - it is probably going to be /etc/crypttab. It is not possible to test it using a mount -a command and an error prevents the o/s from booting

You can still recover by booting into Single mode and fixing it. Happened to me while labbing. I had to think back in my head the steps I took and I realized I missed /etc/crypttab.

asummers

JockVSJock wrote: »

You can still recover by booting into Single mode and fixing it. Happened to me while labbing. I had to think back in my head the steps I took and I realized I missed /etc/crypttab.

Case in point ... I think this has happened to everyone at least once.