How to auto mount LUKS device (encrypted partition) using fstab in Linux

In my last article I had shared the steps to encrypt a partition using LUKS. Now in this article I will continue with LUKS disk encryption and will share the steps to auto mount LUKS device with and without encrypt key during boot up of the Linux node. If you have not enabled auto mount using secret key then you can use LUKS passphrase to manually mount the encrypted partition.

 

Below are some more articles on LUKS based Disk Encryption

 

How LUKS Disk Encryption Works?

  • The entire block device can be encrypted using LUKS; it's well suited for protecting the data on removable storage media or the laptop disk drives
  • LUKS Disk Encryption uses the existing device mapper kernel subsystem
  • It also provides passphrase strengthening, which helps protect against dictionary attacks

 

Auto mount encrypted partition using fstab without key (prompts for LUKS passphrase)

From our last article we already have an LUKS encrypted partition /dev/sdb1, Now you can manually mount the encrypted partition every time node bootsor you can use fstab to auto mount LUKS device during boot stage using LUKS passphrase.

IMPORTANT NOTE:

If you perform this activity without using encrypt key then the reboot will halt with a user prompt asking for LUKS passphrase to mount the LUKS device. Alternatively you can also configure Network Bound Disk Encryption wherein the client will get this key from tang server to auto mount LUKS device.

Add below entry to your /etc/fstab

/dev/mapper/secret      /secret                 ext4    defaults        0 0

 

Next add below entry to /etc/crypttab. Here we are providing the LUKS device name, the mapped partition and the key file location. But since at this stage we have not created any key file, we will put it as none.

secret  /dev/sdb1       none

Next reboot the node and check if the reboot halts waiting for LUKS passphrase to mount the encrypted device

How to auto mount LUKS encrypted partition using key at boot in Linux

 

Mount LUKS device using fstab with key (No prompt for LUKS passphrase)

LUKS Disk Encryption can use up to 8 key slots to store passwords. We can use these keys to auto mount LUKS device.

Use the below command to check the currently utilised key slots. Here as you see only one key slot is in use where we have set the LUKS passphrase of the encrypted partition.

[root@node1 ~]# cryptsetup luksDump /dev/sdb1
LUKS header information for /dev/sdb1

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        256
MK digest:      4f 28 47 d0 91 cd 30 1f c0 78 73 b9 0e 83 cd d6 77 99 bf c8
MK salt:        dc 91 2a 87 49 44 a9 2a 75 f7 f4 18 ee 39 54 e2
                2f 72 e0 21 ba 07 59 84 75 58 c6 a9 ad 7e 43 ae
MK iterations:  19006
UUID:           1da14492-aec4-4924-905d-e5aa28cbcff4

Key Slot 0: ENABLED
        Iterations:             296206
        Salt:                   06 af 5b fc 27 a3 3c 84 02 d8 1e 89 ec fc c9 15
                                d8 c4 5e 3c 58 9b 92 0a e3 e5 48 5d 6b da cf 65
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

To add a new encrypt key to auto mount LUKS device use the below command.

[root@node1 ~]# cryptsetup luksAddKey /dev/sdb1
Enter any existing passphrase:
Enter new passphrase for key slot:
Verify passphrase:

Next verify the key slots again

[root@node1 ~]# cryptsetup luksDump /dev/sdb1
LUKS header information for /dev/sdb1

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        256
MK digest:      4f 28 47 d0 91 cd 30 1f c0 78 73 b9 0e 83 cd d6 77 99 bf c8
MK salt:        dc 91 2a 87 49 44 a9 2a 75 f7 f4 18 ee 39 54 e2
                2f 72 e0 21 ba 07 59 84 75 58 c6 a9 ad 7e 43 ae
MK iterations:  19006
UUID:           1da14492-aec4-4924-905d-e5aa28cbcff4

Key Slot 0: ENABLED
        Iterations:             296206
        Salt:                   06 af 5b fc 27 a3 3c 84 02 d8 1e 89 ec fc c9 15
                                d8 c4 5e 3c 58 9b 92 0a e3 e5 48 5d 6b da cf 65
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: ENABLED
        Iterations:             729190
        Salt:                   3b a3 55 c0 5a d6 d0 0f 26 84 84 c4 a7 d1 83 23
                                9c 2d 6d ea 9f 76 83 04 36 8b d4 d6 19 07 ba 10
        Key material offset:    264
        AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

As you see now we have one more key slot added and is enabled. We will use this key to auto mount LUKS device.

NOTE:

To remove a key slot you can use "cryptsetup luksRemoveKey /dev/device" where the device or partition will be /dev/sdb1 for our demo.

Now let us create a key file which will be used to get the LUKS passphrase while booting the system. So at the reboot stage the system will not halt asking for passphrase and will get the key to auto mount LUKS device from this key file and continue to boot without password.

To create a key file execute the below command. Here my key file "lukskey" will be available under /root

[root@node1 ~]# dd if=/dev/random bs=32 count=1 of=/root/lukskey
1+0 records in
1+0 records out
32 bytes (32 B) copied, 0.000294018 s, 109 kB/s

To check the content of the lukskey file use xxd. As you see it is filled with random data.

[root@node1 ~]# xxd /root/lukskey
0000000: cd37 d965 8eb6 e1cd b009 467f 524b bf8e  .7.e......F.RK..
0000010: 5a53 7250 19c0 78b5 6d68 3f9c c8b6 6bf9  ZSrP..x.mh?...k.

Now let us add this key to our LUKS device

[root@node1 ~]# cryptsetup luksAddKey /dev/sdb1 /root/lukskey
Enter any existing passphrase:

Verify the new keyslot. Now we have a new keyslot enabled.

[root@node1 ~]# cryptsetup luksDump /dev/sdb1
LUKS header information for /dev/sdb1

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        256
MK digest:      4f 28 47 d0 91 cd 30 1f c0 78 73 b9 0e 83 cd d6 77 99 bf c8
MK salt:        dc 91 2a 87 49 44 a9 2a 75 f7 f4 18 ee 39 54 e2
                2f 72 e0 21 ba 07 59 84 75 58 c6 a9 ad 7e 43 ae
MK iterations:  19006
UUID:           1da14492-aec4-4924-905d-e5aa28cbcff4

Key Slot 0: ENABLED
        Iterations:             296206
        Salt:                   06 af 5b fc 27 a3 3c 84 02 d8 1e 89 ec fc c9 15
                                d8 c4 5e 3c 58 9b 92 0a e3 e5 48 5d 6b da cf 65
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: ENABLED
        Iterations:             729190
        Salt:                   3b a3 55 c0 5a d6 d0 0f 26 84 84 c4 a7 d1 83 23
                                9c 2d 6d ea 9f 76 83 04 36 8b d4 d6 19 07 ba 10
        Key material offset:    264
        AF stripes:             4000
Key Slot 2: ENABLED
        Iterations:             683556
        Salt:                   1a 13 aa 01 e1 c2 71 33 29 5f ae fc 25 71 2e c8
                                9f 9f 85 df 4b 80 61 4d 8d 52 35 7c 66 0a d0 af
        Key material offset:    520
        AF stripes:             4000
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Next modify your crypttab and provide the keyfile details to make sure system does not halts asking for passphrase of luks device.

[root@node1 ~]# vim /etc/crypttab
secret  /dev/sdb1       /root/lukskey

Next reboot your node

[root@node1 ~]# reboot

I am sure this time your system should come up automatically without prompting for any passphrase to mount the LUKS encrypted partition.

Post reboot I will validate my mounted file system and I see as expected /secret is already in mounted state

[root@node1 ~]# df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   25G  3.8G   20G  16% /
devtmpfs                 1.9G     0  1.9G   0% /dev
tmpfs                    1.9G     0  1.9G   0% /dev/shm
tmpfs                    1.9G  9.2M  1.9G   1% /run
tmpfs                    1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sda1                488M  134M  319M  30% /boot
/dev/mapper/secret       4.8G   20M  4.6G   1% /secret
tmpfs                    379M  8.0K  379M   1% /run/user/42
tmpfs                    379M     0  379M   0% /run/user/0

 

In coming articles I will share the steps to extend or shrink (resize) LUKS encrypted partition in Linux.

 

Lastly I hope the steps from the article to auto mount LUKS device using fstab to boot with LUKS passphrase and with LUKS key on Linux was helpful. So, let me know your suggestions and feedback using the comment section.

 

References:
An overview on LUKS encryption

33 thoughts on “How to auto mount LUKS device (encrypted partition) using fstab in Linux”

  1. Just wondering why one would go to all the trouble of encrypting their disk data and then make the boot process automatically recover the pass phrase rather than prompting the user for it? Am I overlooking something?

    Reply
    • We never know what we get as a requirement. Honestly even I wonder this question but there always should be a solution handy (if/when required) 🙂

      Reply
      • It can be used as a solution to unlock a second encrypted hard drive or partition, by storing its keyfile onto the root partition that will be unlocked with password. Otherwise you would have to enter the passphrase for every encrypted drive/partition which is tedious...

        Would there be a way to have BOTH password and keyfile decryption ? for example, to store the keyfile on a USB key which automatically unlocks the drive if present, or asks for LUKS password otherwise ? Maybe if the usb is mounted first, and both a passphrase and keyfile are present in the device keyslots ? I suppose that the crypttab must have the "luks"

        Reply
    • To answer your question, encrypting a USB Drive is in the case of it being stolen by a third party and loaded onto another machine. And having it loaded onto the original owner's machine may become a tedious task when inserting and mounting it.

      Reply
  2. I am using this to mount encrypted volume on my home server using a usb key. Generally the usb key is not plugged in. So on reboots I enter the passphrase. However when I am traveling and in a urgency the machine needs to be rebooted. My non techie family plugs in the usb and reboots the server. Its super convenient as they cant use dvorak layout on the keyboard

    Reply
      • I had written another article to use NBDE and tang server to get the passphrase automatically for LUKS encrypted partition but if your question is for runtime requirement i.e. if we do luksOpen then the tool should automatically get the passphrase then that is something in my todo list. We can use expect script and do some dirty WA but I am also checking for similar solution. This is something already in my to-do list.

        Reply
  3. This is very close to what I am looking for, however, my goal is to defend against ransomware by backing up normally unmounted LUKS partitions on my file server to a remove server. I want to mount those partitions via script, run backups with duplicity, then dismount the partitions. The file server boots remotely without a passphrase and because I can recreate a Linux OS at will, I am concerned only for my data partitions. This is a network that I typically manage remotely for long periods of time before I am local again, so theft has to be considered.

    Everything about duplicity backup and restore works with gpg keys to encrypt and decrypt using a "passless" ssh connection to my remote server, and all keys are kept in a remote location I can access if my file server and workstation have been replaced. This has all been confirmed in DR testing, but I am stuck trying to devise a scheme that allows me to mount and dismount a LUKS partition programmatically before and after each backup. Right now a calendar reminder has me ssh to file server, manually mount LUKS, cron runs duplicity, and then I manually dismount LUKS.

    ** caveats **
    I recognize two flaws in my infrastructure. First is that my gpg key is stored as an environment variable so data could be restored by a reasonably sophisticated bad actor. My mitigation is that the crown jewels are symmetrically encrypted, and reside on an unmounted LUKS. Restoring them won't be much help to the bad actor. The second flaw is that malware can find my passless ssh connection, connect, and encrypt my remote duplicity volumes. This is somewhat mitigated because the device is a file server that no one actually uses as a workstation, so email isn't likely a problem. I am perfectly happy to ssh from my workstation to my file server and mount & dismount LUKS manually providing the passphrase on the occasions I need them.

    I feel like using (cryptsetup) --key-file or environment variables within the script simply create convenience by exposing my LUKS passphrase to malware. I am aware that "if malware can find your files, you have have bigger problems".

    Does this mean that no scheme will work?

    TIA

    Reply
    • I use cryptsetup to securely store all the private and public keys for my network. And these keys are deployed on target nodes at a certain location wherein using a script these keys are first collected by mounting the encrypted partition on a loopback device, then deployed on target hosts using passphrase and lastly the encrypted partitions are then unmounted from the loop device. This is completely possible and safe. The cryptsetup passphrase are encrypted and is not in readable format. All you can see is some numbers so there is nothing to be worried here to be read by a hacker. More over once we unmount the partition after our job is done, no one can access these files unless the partition is mounted again.

      Reply
  4. I have a similar problem: a hard where the '/' partition is encrypted and has to be decrypted at boot.
    I created a keyfile, added it as a key into slot 0, and the key file is in '/boot', the only partition that is *not* encrypted. However, when I reference the file in '/etc/crypttab' as '/boot/keyfile' it doesn't find it. Even using the UUID of the '/boot' partition didn't work. Does anybody know how I can fix that?

    Reply
    • I have not tried on Ubuntu but you can scroll up and check comment from Benjamin who seems to have used this steps on Kubuntu 18.04 and it worked for him.

      Reply
  5. Why 2 keyslots are needed to auto mount 1 partition or am I understanding it wrong?
    You created a keyslot, and another to add the keyfile, to automount with no password.
    What does the first one do?

    Reply
    • Thank you for highlighting this. I have created Key Slot 1 just for demonstration and left it there. You only need one key slot to auto mount the partition which I created for Key Slot 2
      You can use cryptsetup luksOpen --test-passphrase --key-slot 0 /dev/sdb1 to verify the passphrase of your keyslot

      Reply
  6. Hi,
    I tried to follow your instruction on an Ubuntu Server 20.04. It works well but after rebooting it basically seems it decrypts the partition (HDD) but it doesn't mount it. After booting I have to manually mount via 'sudo mount' command. Any idea how to fix it?
    I found during the apt upgrade, I found this message:
    cryptsetup: WARNING: 'Private' is missing some arguments, see crypttab(5)
    'Private' is the location I am trying to mount. Are there arguments needed to be mounted in Ubuntu 20.04?
    Any help would more than welcome. Thanks

    Reply
    • Hi Carlos, if you have updated your fstab then it should mount automatically
      here Private is the mount point or the LVM path?
      because you can try using UUID if this is the LVM path, sometimes kernel fails to recognise a device by name and we must use ID of the path

      Reply
      • Hi, Thanks for you fast replay. 'Private' is the mounting point. Are you suggesting I try to repeat the whole steps and change the LVM path (e.g. /dev/sdc1) instead use the UUID (e.g. UUID=0209...) ?

        Reply
        • No I assumed that was the LVM path but for mount point this will not help. Can you please share the content of /etc/crypttab and /etc/fstab for this encrypted path. The error says cryptsetup is missing some arguments so it is some configuration problem most likely. You can also check in the logs for any more information

          Reply
          • For /etc/crypttab:
            #
            Private UUID=01b742d6-8d5c-450d-9c3c-5d65d85ce2db9 /root/lukskey
            For /etc/fstab:
            LABEL=writable / ext4 defaults 0 0
            LABEL=system-boot /boot/firmware vfat defaults 0 1
            /dev/mapper/Private /Private ext4 defaults 0 0

            Reply
            • These look correct (assuming your passphrase is Private, do you anything else in the logs to further debug this?

              Reply
              • I solved it. It's kind of weird, but after decrypting the partition, the file format is "vfat" not "ext4". I cannot explain why, the partition I encrypted from an Ubuntu Desktop and after decrypting uses non-ext4 format. Anyway it works now. Thanks for your help!

                Reply
  7. Fantastic! A clear description of getting a volume encrypted and mounted automatically. I tried using some other google suggested websites, but yours got my volume working in no time flat! Now I can safely transfer my home directory to the encrypted volume.
    Peter

    Reply

Leave a Comment

Please use shortcodes <pre class=comments>your code</pre> for syntax highlighting when adding code.