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

JockVSJockJockVSJock Member Posts: 1,118
in LPI, Red Hat & Linux Foundation
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?
***Freedom of Speech, Just Watch What You Say*** Example, Beware of CompTIA Certs (Deleted From Google Cached)

"Its easier to deceive the masses then to convince the masses that they have been deceived."
-unknown
· Share on FacebookShare on Twitter

Comments

  • brombulecbrombulec Member Posts: 186 ■■■□□□□□□□
    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.
    · Share on FacebookShare on Twitter
  • asummersasummers Member Posts: 157
    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
    · Share on FacebookShare on Twitter
  • brombulecbrombulec Member Posts: 186 ■■■□□□□□□□
    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 :)
    · Share on FacebookShare on Twitter
  • asummersasummers Member Posts: 157
    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.
    · Share on FacebookShare on Twitter
  • JockVSJockJockVSJock Member Posts: 1,118
    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.
    ***Freedom of Speech, Just Watch What You Say*** Example, Beware of CompTIA Certs (Deleted From Google Cached)

    "Its easier to deceive the masses then to convince the masses that they have been deceived."
    -unknown
    · Share on FacebookShare on Twitter
  • asummersasummers Member Posts: 157
    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.
    · Share on FacebookShare on Twitter
Sign In or Register to comment.