How to configure LVM & LUKS to autodecrypt partition?












20















I have recently installed ubuntu server 11.04 with the full lvm encryption(installed from the setup) . I wish now to use a key file to do automatic unlock. I have tried to follow this guide http://ubuntuforums.org/showthread.php?t=837416



I generated a key with this command: sudo dd if=/dev/urandom of=/boot/grub/keyfile bs=1024 count=4



i putted it in /boot/grub because i think that it's not encrypted . When i try to add the key with this commad sudo cryptsetup luksAddKey /dev/sdX /boot/grub/keyfile
it asks me for the passphrase and when i put it nothing happen , nothing is printed to the screen ! I ignore it and continue the others steps and reboot but nothing happened and it ask for the passphrase .



Thanks for the help .










share|improve this question

























  • Do you mean decrypt without entering a passphrase? If the boot process could do that, then the keys necessary to decrypt the volume would need to be on the system somewhere accessible during boot. How would you expect that to protect you from data theft?

    – James Henstridge
    Sep 1 '11 at 1:36











  • yes ,i think that i'll put the key in a hidden partition or a usb flash drive . Is that possible ?

    – isoman
    Sep 1 '11 at 11:04













  • The problem is that if the boot loader can locate the key, then someone inspecting the (unencrypted) boot code will also be able to locate it. If you store the key on a USB stick, you'd want to be quite sure that the stick wouldn't be stolen with the computer. If you're only going to plug the stick in during boot, then it isn't any more convenient than entering a passphrase.

    – James Henstridge
    Sep 2 '11 at 6:32
















20















I have recently installed ubuntu server 11.04 with the full lvm encryption(installed from the setup) . I wish now to use a key file to do automatic unlock. I have tried to follow this guide http://ubuntuforums.org/showthread.php?t=837416



I generated a key with this command: sudo dd if=/dev/urandom of=/boot/grub/keyfile bs=1024 count=4



i putted it in /boot/grub because i think that it's not encrypted . When i try to add the key with this commad sudo cryptsetup luksAddKey /dev/sdX /boot/grub/keyfile
it asks me for the passphrase and when i put it nothing happen , nothing is printed to the screen ! I ignore it and continue the others steps and reboot but nothing happened and it ask for the passphrase .



Thanks for the help .










share|improve this question

























  • Do you mean decrypt without entering a passphrase? If the boot process could do that, then the keys necessary to decrypt the volume would need to be on the system somewhere accessible during boot. How would you expect that to protect you from data theft?

    – James Henstridge
    Sep 1 '11 at 1:36











  • yes ,i think that i'll put the key in a hidden partition or a usb flash drive . Is that possible ?

    – isoman
    Sep 1 '11 at 11:04













  • The problem is that if the boot loader can locate the key, then someone inspecting the (unencrypted) boot code will also be able to locate it. If you store the key on a USB stick, you'd want to be quite sure that the stick wouldn't be stolen with the computer. If you're only going to plug the stick in during boot, then it isn't any more convenient than entering a passphrase.

    – James Henstridge
    Sep 2 '11 at 6:32














20












20








20


20






I have recently installed ubuntu server 11.04 with the full lvm encryption(installed from the setup) . I wish now to use a key file to do automatic unlock. I have tried to follow this guide http://ubuntuforums.org/showthread.php?t=837416



I generated a key with this command: sudo dd if=/dev/urandom of=/boot/grub/keyfile bs=1024 count=4



i putted it in /boot/grub because i think that it's not encrypted . When i try to add the key with this commad sudo cryptsetup luksAddKey /dev/sdX /boot/grub/keyfile
it asks me for the passphrase and when i put it nothing happen , nothing is printed to the screen ! I ignore it and continue the others steps and reboot but nothing happened and it ask for the passphrase .



Thanks for the help .










share|improve this question
















I have recently installed ubuntu server 11.04 with the full lvm encryption(installed from the setup) . I wish now to use a key file to do automatic unlock. I have tried to follow this guide http://ubuntuforums.org/showthread.php?t=837416



I generated a key with this command: sudo dd if=/dev/urandom of=/boot/grub/keyfile bs=1024 count=4



i putted it in /boot/grub because i think that it's not encrypted . When i try to add the key with this commad sudo cryptsetup luksAddKey /dev/sdX /boot/grub/keyfile
it asks me for the passphrase and when i put it nothing happen , nothing is printed to the screen ! I ignore it and continue the others steps and reboot but nothing happened and it ask for the passphrase .



Thanks for the help .







encryption lvm luks






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 12 '14 at 9:17









qbi

15.1k863118




15.1k863118










asked Aug 31 '11 at 22:21









isomanisoman

3641517




3641517













  • Do you mean decrypt without entering a passphrase? If the boot process could do that, then the keys necessary to decrypt the volume would need to be on the system somewhere accessible during boot. How would you expect that to protect you from data theft?

    – James Henstridge
    Sep 1 '11 at 1:36











  • yes ,i think that i'll put the key in a hidden partition or a usb flash drive . Is that possible ?

    – isoman
    Sep 1 '11 at 11:04













  • The problem is that if the boot loader can locate the key, then someone inspecting the (unencrypted) boot code will also be able to locate it. If you store the key on a USB stick, you'd want to be quite sure that the stick wouldn't be stolen with the computer. If you're only going to plug the stick in during boot, then it isn't any more convenient than entering a passphrase.

    – James Henstridge
    Sep 2 '11 at 6:32



















  • Do you mean decrypt without entering a passphrase? If the boot process could do that, then the keys necessary to decrypt the volume would need to be on the system somewhere accessible during boot. How would you expect that to protect you from data theft?

    – James Henstridge
    Sep 1 '11 at 1:36











  • yes ,i think that i'll put the key in a hidden partition or a usb flash drive . Is that possible ?

    – isoman
    Sep 1 '11 at 11:04













  • The problem is that if the boot loader can locate the key, then someone inspecting the (unencrypted) boot code will also be able to locate it. If you store the key on a USB stick, you'd want to be quite sure that the stick wouldn't be stolen with the computer. If you're only going to plug the stick in during boot, then it isn't any more convenient than entering a passphrase.

    – James Henstridge
    Sep 2 '11 at 6:32

















Do you mean decrypt without entering a passphrase? If the boot process could do that, then the keys necessary to decrypt the volume would need to be on the system somewhere accessible during boot. How would you expect that to protect you from data theft?

– James Henstridge
Sep 1 '11 at 1:36





Do you mean decrypt without entering a passphrase? If the boot process could do that, then the keys necessary to decrypt the volume would need to be on the system somewhere accessible during boot. How would you expect that to protect you from data theft?

– James Henstridge
Sep 1 '11 at 1:36













yes ,i think that i'll put the key in a hidden partition or a usb flash drive . Is that possible ?

– isoman
Sep 1 '11 at 11:04







yes ,i think that i'll put the key in a hidden partition or a usb flash drive . Is that possible ?

– isoman
Sep 1 '11 at 11:04















The problem is that if the boot loader can locate the key, then someone inspecting the (unencrypted) boot code will also be able to locate it. If you store the key on a USB stick, you'd want to be quite sure that the stick wouldn't be stolen with the computer. If you're only going to plug the stick in during boot, then it isn't any more convenient than entering a passphrase.

– James Henstridge
Sep 2 '11 at 6:32





The problem is that if the boot loader can locate the key, then someone inspecting the (unencrypted) boot code will also be able to locate it. If you store the key on a USB stick, you'd want to be quite sure that the stick wouldn't be stolen with the computer. If you're only going to plug the stick in during boot, then it isn't any more convenient than entering a passphrase.

– James Henstridge
Sep 2 '11 at 6:32










5 Answers
5






active

oldest

votes


















26














I've just been through this on my new home server, it took a lot of googling and guessing, but I've got it working. I'll attempt to reproduce the steps here. I'm using Ubuntu Server 11.10, and started with a pretty much standard install using encrypted LVM, so I'll just relate the changes I made from there.



Setup:




  • /dev/sda1 is my unencrypted /boot partition

  • /dev/sda5 is my lvm partition which contains everything else -- root, swap, and home

  • /dev/sdc1 is the partition on my USB flash drive where I'll store the keyfile


First, I created a keyfile, just in my home directory:



dd if=/dev/urandom of=keyfile bs=512 count=4


(you can use a larger blocksize or count for a larger key)



Tell cryptsetup the new key (it's the contents that are important, not the filename):



sudo cryptsetup luksAddKey /dev/sda5 keyfile


Then, I formatted my USB flash drive with ext2 and gave it a label. I used a label, so that later I can mount it by label, and replace the USB flash drive in case something goes wrong with it.



sudo mkfs -t ext2 /dev/sdc1
sudo e2label /dev/sdc1 KEYS


(of course, your device will vary)



Now, copy the keyfile to the USB flash drive, owned by root mode 400:



mkdir KEYS
sudo mount /dev/sdc1 KEYS
sudo cp keyfile KEYS
sudo chown root KEYS/keyfile
sudo chmod 400 KEYS/keyfile


Modify /etc/crypttab. Mine originally contained



sd5_crypt UUID=(...) none luks


which I changed to



sd5_crypt UUID=(...) /dev/disk/by-label/KEYS:/keyfile luks,keyscript=/lib/cryptsetup/scripts/passdev


Finally, update the initramfs:



sudo update-initramfs -uv


It now boots using the keyfile on the USB flash drive. If I remove the flash drive (say, when I go on holiday) it doesn't boot and my data is secure.



If anyone knows how to get it to ask for the passphrase if the USB flash drive is missing, that would be handy as a fallback. Hope this helps, any additions or corrections would be more than welcome!






share|improve this answer





















  • 3





    If you aren't sure how to get a password prompt, you could use a bootable partition in the flash drive to load via an alternate initramfs that looks for a keyfile and have the default boot on the hard disk load a regular initramfs that prompts for a password.

    – hexafraction
    Aug 14 '12 at 16:12






  • 1





    @3pic I'm not 100% sure since I did this several months ago. But Ubuntu boots into a virtual file system. keyscript=/lib/cryptsetup/scripts/passdev adds passdev script to it. And then update-initramfs -uv rebuilds the file system archive.

    – VarunAgw
    Nov 28 '15 at 6:15






  • 1





    @RandyOrrison this really is great. It works. But... after it gets past initram it then sits for a min or two minutes with A start job is running for dev-sda8:-keyfile.device (1min 18s...) etc. It passes, everything is mounted, but it hangs for a while. Log says "Timed out waiting for device dev-sda8:-sda7keyfile.device; Dependency failed for Crypto Setup for sda7crypt." Of course, it already was mounted by initram, but.... What am I doing wrong?

    – deitch
    Apr 7 '16 at 9:59








  • 1





    For some reason it does not seem to like / work with systemd; it will simply ignore the keyscript field altogether.

    – Etienne Bruines
    Nov 24 '16 at 0:13






  • 1





    In Ubuntu 17.10+, the update-initramfs tool won't generate an initramfs image capable of booting a luks volume if your root filesystem is on a luks volume and has a key file. You can make it work by leaving "none" as the keyfile value, and setting the options to have keyscript=/etc/my-keyscript, where /etc/my-keyscript is a shell script that prints out the key.

    – Macil
    Oct 31 '17 at 2:05





















6














These instructions from howtoforge.com got me up and running with an automatically decrypting volume.



How to: Automatically Unlock LUKS Encrypted Drives With A Keyfile



Step 1: Create a random keyfile



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


Step 2: Make the keyfile read-only to root



sudo chmod 0400 /root/keyfile


That will make the keyfile readable only by root. If someone get access to this keyfile, then you have a bigger problem on your computer anyway.



Alternatively chown your desired keyfile to root:root and move it into the /root folder



Step 3: Add the keyfile to LUKS



LUKS/dm_crypt enabled devices may hold up to 10 different keyfiles/passwords. So, next to having the already setup password we're going to add this keyfile as additional authorization method.



sudo cryptsetup luksAddKey /dev/sdX /root/keyfile


sdX is of course your LUKS device.



First you'll be prompted to enter an (existing) password to unlock the drive. If everything works well, you should get an output like this:



Enter any LUKS passphrase:
key slot 0 unlocked.
Command successful.


Step 4: Create a mapper



LUKS devices need to create a mapper that can then be referenced in the fstab. Open /etc/crypttab



sudo nano /etc/crypttab


and add then a line like this:



sdX_crypt      /dev/sdX  /root/keyfile  luks


or you can use the UUID of the device:



sdX_crypt      /dev/disk/by-uuid/247ad289-dbe5-4419-9965-e3cd30f0b080  /root/keyfile  luks


sdX_crypt is the name of the mapper that is being created. You can use here any name e.g. "music" or "movies" or "sfdsfawe" ....



Save and close the file by issuing ctrl-x, enter, enter. Ctrl-x closes nano but first it asks to save the file [yes = enter] and what the name shall be [same name = enter].



What we have done there actually is telling that /root/keyfile shall be used instead of password entry to unlock the drive.



Step 5: Mount the device in fstab



Now, we have an unlocked device (well, not yet but when the system is being booted up) and we just need to mount it now. Open /etc/fstab:



sudo nano /etc/fstab


and add a new entry like:



/dev/mapper/sdX_crypt  /media/sdX     ext3    defaults        0       2


Make sure you have the correct mapper name that you added in step 4. Also make sure that the mount point/folder exists. After having added it, save again the file and close it (ctrl-x, enter, enter).



Step 6: Reboot or remount



That's it. Now you can reboot and the additional devices should be auto-unlocked and mounted. You can also test it by remounting all devices:



sudo mount -a





share|improve this answer



















  • 1





    you forget to update initramfs, 100% needed

    – 3pic
    Aug 13 '15 at 7:28



















6














Improving Randy Orrison's answer, here is a small script I created, that will make system fallback to asking user for password if it fails to find the keyfile.



#!/bin/sh

ask_for_password () {
cryptkey="Unlocking the disk $cryptsource ($crypttarget)nEnter passphrase: "
if [ -x /bin/plymouth ] && plymouth --ping; then
cryptkeyscript="plymouth ask-for-password --prompt"
cryptkey=$(printf "$cryptkey")
else
cryptkeyscript="/lib/cryptsetup/askpass"
fi
$cryptkeyscript "$cryptkey"
}

device=$(echo $1 | cut -d: -f1)
filepath=$(echo $1 | cut -d: -f2)

# Ask for password if device doesn't exist
if [ ! -b $device ]; then
ask_for_password
exit
fi

mkdir /tmp/auto_unlocker
mount $device /tmp/auto_unlocker

# Again ask for password if device exist but file doesn't exist
if [ ! -e /tmp/auto_unlocker$filepath ]; then
ask_for_password
else
cat /tmp/auto_unlocker$filepath
fi

umount /tmp/auto_unlocker


Save it and replace keyscript=/lib/cryptsetup/scripts/passdev in /etc/crypttab with the path to this file and run sudo update-initramfs -uv and you are done.






share|improve this answer


























  • I guess your solution is not working for usb drive for more than one keyfile. I mean if i have more than one encrypted partition (home, swap, root). It seams that it does not unmounts USB driver after cat command. Do you have any idea how to fix it?

    – Khamidulla
    Jun 2 '16 at 1:29











  • This is working for me (Xubuntu 17.10) but I had to edit grub and remove "splash". Also I had to save the file in a proper location (/lib/cryptsetup/scripts/unlock_custom) and chmod it 755. Not sure if splash or copying in the specific place made it work for me, but it didn't work before. Anyway, it works but at boot, after Startet AppArmor initialization. I get: A start job is running for dev-disk keyfile.device (1m 30s). After the 90s X starts and I can use my system... no idea how to fix this start job...

    – firepol
    Apr 15 '18 at 21:18



















1














@deitch
I had the same setup like @Randy Orrison and ran into the same issue as you and it turns out is a bug of systemd which tries to mount the / filesystem again as it finds the corresponding entry in /et/crypttab.



To resolve this i just removed the entry for sda5_crypt from /etc/crypttab once the update-initramfs -uv command was ran.



Reeboot and everything works fine as intended.






share|improve this answer































    0














    the service for mounting or starting device where the key is stored takes about 1min 30 secs just like @firepol said. Is there any way the time could be decreased ?






    share|improve this answer























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "89"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f59487%2fhow-to-configure-lvm-luks-to-autodecrypt-partition%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      5 Answers
      5






      active

      oldest

      votes








      5 Answers
      5






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      26














      I've just been through this on my new home server, it took a lot of googling and guessing, but I've got it working. I'll attempt to reproduce the steps here. I'm using Ubuntu Server 11.10, and started with a pretty much standard install using encrypted LVM, so I'll just relate the changes I made from there.



      Setup:




      • /dev/sda1 is my unencrypted /boot partition

      • /dev/sda5 is my lvm partition which contains everything else -- root, swap, and home

      • /dev/sdc1 is the partition on my USB flash drive where I'll store the keyfile


      First, I created a keyfile, just in my home directory:



      dd if=/dev/urandom of=keyfile bs=512 count=4


      (you can use a larger blocksize or count for a larger key)



      Tell cryptsetup the new key (it's the contents that are important, not the filename):



      sudo cryptsetup luksAddKey /dev/sda5 keyfile


      Then, I formatted my USB flash drive with ext2 and gave it a label. I used a label, so that later I can mount it by label, and replace the USB flash drive in case something goes wrong with it.



      sudo mkfs -t ext2 /dev/sdc1
      sudo e2label /dev/sdc1 KEYS


      (of course, your device will vary)



      Now, copy the keyfile to the USB flash drive, owned by root mode 400:



      mkdir KEYS
      sudo mount /dev/sdc1 KEYS
      sudo cp keyfile KEYS
      sudo chown root KEYS/keyfile
      sudo chmod 400 KEYS/keyfile


      Modify /etc/crypttab. Mine originally contained



      sd5_crypt UUID=(...) none luks


      which I changed to



      sd5_crypt UUID=(...) /dev/disk/by-label/KEYS:/keyfile luks,keyscript=/lib/cryptsetup/scripts/passdev


      Finally, update the initramfs:



      sudo update-initramfs -uv


      It now boots using the keyfile on the USB flash drive. If I remove the flash drive (say, when I go on holiday) it doesn't boot and my data is secure.



      If anyone knows how to get it to ask for the passphrase if the USB flash drive is missing, that would be handy as a fallback. Hope this helps, any additions or corrections would be more than welcome!






      share|improve this answer





















      • 3





        If you aren't sure how to get a password prompt, you could use a bootable partition in the flash drive to load via an alternate initramfs that looks for a keyfile and have the default boot on the hard disk load a regular initramfs that prompts for a password.

        – hexafraction
        Aug 14 '12 at 16:12






      • 1





        @3pic I'm not 100% sure since I did this several months ago. But Ubuntu boots into a virtual file system. keyscript=/lib/cryptsetup/scripts/passdev adds passdev script to it. And then update-initramfs -uv rebuilds the file system archive.

        – VarunAgw
        Nov 28 '15 at 6:15






      • 1





        @RandyOrrison this really is great. It works. But... after it gets past initram it then sits for a min or two minutes with A start job is running for dev-sda8:-keyfile.device (1min 18s...) etc. It passes, everything is mounted, but it hangs for a while. Log says "Timed out waiting for device dev-sda8:-sda7keyfile.device; Dependency failed for Crypto Setup for sda7crypt." Of course, it already was mounted by initram, but.... What am I doing wrong?

        – deitch
        Apr 7 '16 at 9:59








      • 1





        For some reason it does not seem to like / work with systemd; it will simply ignore the keyscript field altogether.

        – Etienne Bruines
        Nov 24 '16 at 0:13






      • 1





        In Ubuntu 17.10+, the update-initramfs tool won't generate an initramfs image capable of booting a luks volume if your root filesystem is on a luks volume and has a key file. You can make it work by leaving "none" as the keyfile value, and setting the options to have keyscript=/etc/my-keyscript, where /etc/my-keyscript is a shell script that prints out the key.

        – Macil
        Oct 31 '17 at 2:05


















      26














      I've just been through this on my new home server, it took a lot of googling and guessing, but I've got it working. I'll attempt to reproduce the steps here. I'm using Ubuntu Server 11.10, and started with a pretty much standard install using encrypted LVM, so I'll just relate the changes I made from there.



      Setup:




      • /dev/sda1 is my unencrypted /boot partition

      • /dev/sda5 is my lvm partition which contains everything else -- root, swap, and home

      • /dev/sdc1 is the partition on my USB flash drive where I'll store the keyfile


      First, I created a keyfile, just in my home directory:



      dd if=/dev/urandom of=keyfile bs=512 count=4


      (you can use a larger blocksize or count for a larger key)



      Tell cryptsetup the new key (it's the contents that are important, not the filename):



      sudo cryptsetup luksAddKey /dev/sda5 keyfile


      Then, I formatted my USB flash drive with ext2 and gave it a label. I used a label, so that later I can mount it by label, and replace the USB flash drive in case something goes wrong with it.



      sudo mkfs -t ext2 /dev/sdc1
      sudo e2label /dev/sdc1 KEYS


      (of course, your device will vary)



      Now, copy the keyfile to the USB flash drive, owned by root mode 400:



      mkdir KEYS
      sudo mount /dev/sdc1 KEYS
      sudo cp keyfile KEYS
      sudo chown root KEYS/keyfile
      sudo chmod 400 KEYS/keyfile


      Modify /etc/crypttab. Mine originally contained



      sd5_crypt UUID=(...) none luks


      which I changed to



      sd5_crypt UUID=(...) /dev/disk/by-label/KEYS:/keyfile luks,keyscript=/lib/cryptsetup/scripts/passdev


      Finally, update the initramfs:



      sudo update-initramfs -uv


      It now boots using the keyfile on the USB flash drive. If I remove the flash drive (say, when I go on holiday) it doesn't boot and my data is secure.



      If anyone knows how to get it to ask for the passphrase if the USB flash drive is missing, that would be handy as a fallback. Hope this helps, any additions or corrections would be more than welcome!






      share|improve this answer





















      • 3





        If you aren't sure how to get a password prompt, you could use a bootable partition in the flash drive to load via an alternate initramfs that looks for a keyfile and have the default boot on the hard disk load a regular initramfs that prompts for a password.

        – hexafraction
        Aug 14 '12 at 16:12






      • 1





        @3pic I'm not 100% sure since I did this several months ago. But Ubuntu boots into a virtual file system. keyscript=/lib/cryptsetup/scripts/passdev adds passdev script to it. And then update-initramfs -uv rebuilds the file system archive.

        – VarunAgw
        Nov 28 '15 at 6:15






      • 1





        @RandyOrrison this really is great. It works. But... after it gets past initram it then sits for a min or two minutes with A start job is running for dev-sda8:-keyfile.device (1min 18s...) etc. It passes, everything is mounted, but it hangs for a while. Log says "Timed out waiting for device dev-sda8:-sda7keyfile.device; Dependency failed for Crypto Setup for sda7crypt." Of course, it already was mounted by initram, but.... What am I doing wrong?

        – deitch
        Apr 7 '16 at 9:59








      • 1





        For some reason it does not seem to like / work with systemd; it will simply ignore the keyscript field altogether.

        – Etienne Bruines
        Nov 24 '16 at 0:13






      • 1





        In Ubuntu 17.10+, the update-initramfs tool won't generate an initramfs image capable of booting a luks volume if your root filesystem is on a luks volume and has a key file. You can make it work by leaving "none" as the keyfile value, and setting the options to have keyscript=/etc/my-keyscript, where /etc/my-keyscript is a shell script that prints out the key.

        – Macil
        Oct 31 '17 at 2:05
















      26












      26








      26







      I've just been through this on my new home server, it took a lot of googling and guessing, but I've got it working. I'll attempt to reproduce the steps here. I'm using Ubuntu Server 11.10, and started with a pretty much standard install using encrypted LVM, so I'll just relate the changes I made from there.



      Setup:




      • /dev/sda1 is my unencrypted /boot partition

      • /dev/sda5 is my lvm partition which contains everything else -- root, swap, and home

      • /dev/sdc1 is the partition on my USB flash drive where I'll store the keyfile


      First, I created a keyfile, just in my home directory:



      dd if=/dev/urandom of=keyfile bs=512 count=4


      (you can use a larger blocksize or count for a larger key)



      Tell cryptsetup the new key (it's the contents that are important, not the filename):



      sudo cryptsetup luksAddKey /dev/sda5 keyfile


      Then, I formatted my USB flash drive with ext2 and gave it a label. I used a label, so that later I can mount it by label, and replace the USB flash drive in case something goes wrong with it.



      sudo mkfs -t ext2 /dev/sdc1
      sudo e2label /dev/sdc1 KEYS


      (of course, your device will vary)



      Now, copy the keyfile to the USB flash drive, owned by root mode 400:



      mkdir KEYS
      sudo mount /dev/sdc1 KEYS
      sudo cp keyfile KEYS
      sudo chown root KEYS/keyfile
      sudo chmod 400 KEYS/keyfile


      Modify /etc/crypttab. Mine originally contained



      sd5_crypt UUID=(...) none luks


      which I changed to



      sd5_crypt UUID=(...) /dev/disk/by-label/KEYS:/keyfile luks,keyscript=/lib/cryptsetup/scripts/passdev


      Finally, update the initramfs:



      sudo update-initramfs -uv


      It now boots using the keyfile on the USB flash drive. If I remove the flash drive (say, when I go on holiday) it doesn't boot and my data is secure.



      If anyone knows how to get it to ask for the passphrase if the USB flash drive is missing, that would be handy as a fallback. Hope this helps, any additions or corrections would be more than welcome!






      share|improve this answer















      I've just been through this on my new home server, it took a lot of googling and guessing, but I've got it working. I'll attempt to reproduce the steps here. I'm using Ubuntu Server 11.10, and started with a pretty much standard install using encrypted LVM, so I'll just relate the changes I made from there.



      Setup:




      • /dev/sda1 is my unencrypted /boot partition

      • /dev/sda5 is my lvm partition which contains everything else -- root, swap, and home

      • /dev/sdc1 is the partition on my USB flash drive where I'll store the keyfile


      First, I created a keyfile, just in my home directory:



      dd if=/dev/urandom of=keyfile bs=512 count=4


      (you can use a larger blocksize or count for a larger key)



      Tell cryptsetup the new key (it's the contents that are important, not the filename):



      sudo cryptsetup luksAddKey /dev/sda5 keyfile


      Then, I formatted my USB flash drive with ext2 and gave it a label. I used a label, so that later I can mount it by label, and replace the USB flash drive in case something goes wrong with it.



      sudo mkfs -t ext2 /dev/sdc1
      sudo e2label /dev/sdc1 KEYS


      (of course, your device will vary)



      Now, copy the keyfile to the USB flash drive, owned by root mode 400:



      mkdir KEYS
      sudo mount /dev/sdc1 KEYS
      sudo cp keyfile KEYS
      sudo chown root KEYS/keyfile
      sudo chmod 400 KEYS/keyfile


      Modify /etc/crypttab. Mine originally contained



      sd5_crypt UUID=(...) none luks


      which I changed to



      sd5_crypt UUID=(...) /dev/disk/by-label/KEYS:/keyfile luks,keyscript=/lib/cryptsetup/scripts/passdev


      Finally, update the initramfs:



      sudo update-initramfs -uv


      It now boots using the keyfile on the USB flash drive. If I remove the flash drive (say, when I go on holiday) it doesn't boot and my data is secure.



      If anyone knows how to get it to ask for the passphrase if the USB flash drive is missing, that would be handy as a fallback. Hope this helps, any additions or corrections would be more than welcome!







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Dec 28 '11 at 0:13

























      answered Dec 27 '11 at 23:57









      Randy OrrisonRandy Orrison

      41146




      41146








      • 3





        If you aren't sure how to get a password prompt, you could use a bootable partition in the flash drive to load via an alternate initramfs that looks for a keyfile and have the default boot on the hard disk load a regular initramfs that prompts for a password.

        – hexafraction
        Aug 14 '12 at 16:12






      • 1





        @3pic I'm not 100% sure since I did this several months ago. But Ubuntu boots into a virtual file system. keyscript=/lib/cryptsetup/scripts/passdev adds passdev script to it. And then update-initramfs -uv rebuilds the file system archive.

        – VarunAgw
        Nov 28 '15 at 6:15






      • 1





        @RandyOrrison this really is great. It works. But... after it gets past initram it then sits for a min or two minutes with A start job is running for dev-sda8:-keyfile.device (1min 18s...) etc. It passes, everything is mounted, but it hangs for a while. Log says "Timed out waiting for device dev-sda8:-sda7keyfile.device; Dependency failed for Crypto Setup for sda7crypt." Of course, it already was mounted by initram, but.... What am I doing wrong?

        – deitch
        Apr 7 '16 at 9:59








      • 1





        For some reason it does not seem to like / work with systemd; it will simply ignore the keyscript field altogether.

        – Etienne Bruines
        Nov 24 '16 at 0:13






      • 1





        In Ubuntu 17.10+, the update-initramfs tool won't generate an initramfs image capable of booting a luks volume if your root filesystem is on a luks volume and has a key file. You can make it work by leaving "none" as the keyfile value, and setting the options to have keyscript=/etc/my-keyscript, where /etc/my-keyscript is a shell script that prints out the key.

        – Macil
        Oct 31 '17 at 2:05
















      • 3





        If you aren't sure how to get a password prompt, you could use a bootable partition in the flash drive to load via an alternate initramfs that looks for a keyfile and have the default boot on the hard disk load a regular initramfs that prompts for a password.

        – hexafraction
        Aug 14 '12 at 16:12






      • 1





        @3pic I'm not 100% sure since I did this several months ago. But Ubuntu boots into a virtual file system. keyscript=/lib/cryptsetup/scripts/passdev adds passdev script to it. And then update-initramfs -uv rebuilds the file system archive.

        – VarunAgw
        Nov 28 '15 at 6:15






      • 1





        @RandyOrrison this really is great. It works. But... after it gets past initram it then sits for a min or two minutes with A start job is running for dev-sda8:-keyfile.device (1min 18s...) etc. It passes, everything is mounted, but it hangs for a while. Log says "Timed out waiting for device dev-sda8:-sda7keyfile.device; Dependency failed for Crypto Setup for sda7crypt." Of course, it already was mounted by initram, but.... What am I doing wrong?

        – deitch
        Apr 7 '16 at 9:59








      • 1





        For some reason it does not seem to like / work with systemd; it will simply ignore the keyscript field altogether.

        – Etienne Bruines
        Nov 24 '16 at 0:13






      • 1





        In Ubuntu 17.10+, the update-initramfs tool won't generate an initramfs image capable of booting a luks volume if your root filesystem is on a luks volume and has a key file. You can make it work by leaving "none" as the keyfile value, and setting the options to have keyscript=/etc/my-keyscript, where /etc/my-keyscript is a shell script that prints out the key.

        – Macil
        Oct 31 '17 at 2:05










      3




      3





      If you aren't sure how to get a password prompt, you could use a bootable partition in the flash drive to load via an alternate initramfs that looks for a keyfile and have the default boot on the hard disk load a regular initramfs that prompts for a password.

      – hexafraction
      Aug 14 '12 at 16:12





      If you aren't sure how to get a password prompt, you could use a bootable partition in the flash drive to load via an alternate initramfs that looks for a keyfile and have the default boot on the hard disk load a regular initramfs that prompts for a password.

      – hexafraction
      Aug 14 '12 at 16:12




      1




      1





      @3pic I'm not 100% sure since I did this several months ago. But Ubuntu boots into a virtual file system. keyscript=/lib/cryptsetup/scripts/passdev adds passdev script to it. And then update-initramfs -uv rebuilds the file system archive.

      – VarunAgw
      Nov 28 '15 at 6:15





      @3pic I'm not 100% sure since I did this several months ago. But Ubuntu boots into a virtual file system. keyscript=/lib/cryptsetup/scripts/passdev adds passdev script to it. And then update-initramfs -uv rebuilds the file system archive.

      – VarunAgw
      Nov 28 '15 at 6:15




      1




      1





      @RandyOrrison this really is great. It works. But... after it gets past initram it then sits for a min or two minutes with A start job is running for dev-sda8:-keyfile.device (1min 18s...) etc. It passes, everything is mounted, but it hangs for a while. Log says "Timed out waiting for device dev-sda8:-sda7keyfile.device; Dependency failed for Crypto Setup for sda7crypt." Of course, it already was mounted by initram, but.... What am I doing wrong?

      – deitch
      Apr 7 '16 at 9:59







      @RandyOrrison this really is great. It works. But... after it gets past initram it then sits for a min or two minutes with A start job is running for dev-sda8:-keyfile.device (1min 18s...) etc. It passes, everything is mounted, but it hangs for a while. Log says "Timed out waiting for device dev-sda8:-sda7keyfile.device; Dependency failed for Crypto Setup for sda7crypt." Of course, it already was mounted by initram, but.... What am I doing wrong?

      – deitch
      Apr 7 '16 at 9:59






      1




      1





      For some reason it does not seem to like / work with systemd; it will simply ignore the keyscript field altogether.

      – Etienne Bruines
      Nov 24 '16 at 0:13





      For some reason it does not seem to like / work with systemd; it will simply ignore the keyscript field altogether.

      – Etienne Bruines
      Nov 24 '16 at 0:13




      1




      1





      In Ubuntu 17.10+, the update-initramfs tool won't generate an initramfs image capable of booting a luks volume if your root filesystem is on a luks volume and has a key file. You can make it work by leaving "none" as the keyfile value, and setting the options to have keyscript=/etc/my-keyscript, where /etc/my-keyscript is a shell script that prints out the key.

      – Macil
      Oct 31 '17 at 2:05







      In Ubuntu 17.10+, the update-initramfs tool won't generate an initramfs image capable of booting a luks volume if your root filesystem is on a luks volume and has a key file. You can make it work by leaving "none" as the keyfile value, and setting the options to have keyscript=/etc/my-keyscript, where /etc/my-keyscript is a shell script that prints out the key.

      – Macil
      Oct 31 '17 at 2:05















      6














      These instructions from howtoforge.com got me up and running with an automatically decrypting volume.



      How to: Automatically Unlock LUKS Encrypted Drives With A Keyfile



      Step 1: Create a random keyfile



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


      Step 2: Make the keyfile read-only to root



      sudo chmod 0400 /root/keyfile


      That will make the keyfile readable only by root. If someone get access to this keyfile, then you have a bigger problem on your computer anyway.



      Alternatively chown your desired keyfile to root:root and move it into the /root folder



      Step 3: Add the keyfile to LUKS



      LUKS/dm_crypt enabled devices may hold up to 10 different keyfiles/passwords. So, next to having the already setup password we're going to add this keyfile as additional authorization method.



      sudo cryptsetup luksAddKey /dev/sdX /root/keyfile


      sdX is of course your LUKS device.



      First you'll be prompted to enter an (existing) password to unlock the drive. If everything works well, you should get an output like this:



      Enter any LUKS passphrase:
      key slot 0 unlocked.
      Command successful.


      Step 4: Create a mapper



      LUKS devices need to create a mapper that can then be referenced in the fstab. Open /etc/crypttab



      sudo nano /etc/crypttab


      and add then a line like this:



      sdX_crypt      /dev/sdX  /root/keyfile  luks


      or you can use the UUID of the device:



      sdX_crypt      /dev/disk/by-uuid/247ad289-dbe5-4419-9965-e3cd30f0b080  /root/keyfile  luks


      sdX_crypt is the name of the mapper that is being created. You can use here any name e.g. "music" or "movies" or "sfdsfawe" ....



      Save and close the file by issuing ctrl-x, enter, enter. Ctrl-x closes nano but first it asks to save the file [yes = enter] and what the name shall be [same name = enter].



      What we have done there actually is telling that /root/keyfile shall be used instead of password entry to unlock the drive.



      Step 5: Mount the device in fstab



      Now, we have an unlocked device (well, not yet but when the system is being booted up) and we just need to mount it now. Open /etc/fstab:



      sudo nano /etc/fstab


      and add a new entry like:



      /dev/mapper/sdX_crypt  /media/sdX     ext3    defaults        0       2


      Make sure you have the correct mapper name that you added in step 4. Also make sure that the mount point/folder exists. After having added it, save again the file and close it (ctrl-x, enter, enter).



      Step 6: Reboot or remount



      That's it. Now you can reboot and the additional devices should be auto-unlocked and mounted. You can also test it by remounting all devices:



      sudo mount -a





      share|improve this answer



















      • 1





        you forget to update initramfs, 100% needed

        – 3pic
        Aug 13 '15 at 7:28
















      6














      These instructions from howtoforge.com got me up and running with an automatically decrypting volume.



      How to: Automatically Unlock LUKS Encrypted Drives With A Keyfile



      Step 1: Create a random keyfile



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


      Step 2: Make the keyfile read-only to root



      sudo chmod 0400 /root/keyfile


      That will make the keyfile readable only by root. If someone get access to this keyfile, then you have a bigger problem on your computer anyway.



      Alternatively chown your desired keyfile to root:root and move it into the /root folder



      Step 3: Add the keyfile to LUKS



      LUKS/dm_crypt enabled devices may hold up to 10 different keyfiles/passwords. So, next to having the already setup password we're going to add this keyfile as additional authorization method.



      sudo cryptsetup luksAddKey /dev/sdX /root/keyfile


      sdX is of course your LUKS device.



      First you'll be prompted to enter an (existing) password to unlock the drive. If everything works well, you should get an output like this:



      Enter any LUKS passphrase:
      key slot 0 unlocked.
      Command successful.


      Step 4: Create a mapper



      LUKS devices need to create a mapper that can then be referenced in the fstab. Open /etc/crypttab



      sudo nano /etc/crypttab


      and add then a line like this:



      sdX_crypt      /dev/sdX  /root/keyfile  luks


      or you can use the UUID of the device:



      sdX_crypt      /dev/disk/by-uuid/247ad289-dbe5-4419-9965-e3cd30f0b080  /root/keyfile  luks


      sdX_crypt is the name of the mapper that is being created. You can use here any name e.g. "music" or "movies" or "sfdsfawe" ....



      Save and close the file by issuing ctrl-x, enter, enter. Ctrl-x closes nano but first it asks to save the file [yes = enter] and what the name shall be [same name = enter].



      What we have done there actually is telling that /root/keyfile shall be used instead of password entry to unlock the drive.



      Step 5: Mount the device in fstab



      Now, we have an unlocked device (well, not yet but when the system is being booted up) and we just need to mount it now. Open /etc/fstab:



      sudo nano /etc/fstab


      and add a new entry like:



      /dev/mapper/sdX_crypt  /media/sdX     ext3    defaults        0       2


      Make sure you have the correct mapper name that you added in step 4. Also make sure that the mount point/folder exists. After having added it, save again the file and close it (ctrl-x, enter, enter).



      Step 6: Reboot or remount



      That's it. Now you can reboot and the additional devices should be auto-unlocked and mounted. You can also test it by remounting all devices:



      sudo mount -a





      share|improve this answer



















      • 1





        you forget to update initramfs, 100% needed

        – 3pic
        Aug 13 '15 at 7:28














      6












      6








      6







      These instructions from howtoforge.com got me up and running with an automatically decrypting volume.



      How to: Automatically Unlock LUKS Encrypted Drives With A Keyfile



      Step 1: Create a random keyfile



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


      Step 2: Make the keyfile read-only to root



      sudo chmod 0400 /root/keyfile


      That will make the keyfile readable only by root. If someone get access to this keyfile, then you have a bigger problem on your computer anyway.



      Alternatively chown your desired keyfile to root:root and move it into the /root folder



      Step 3: Add the keyfile to LUKS



      LUKS/dm_crypt enabled devices may hold up to 10 different keyfiles/passwords. So, next to having the already setup password we're going to add this keyfile as additional authorization method.



      sudo cryptsetup luksAddKey /dev/sdX /root/keyfile


      sdX is of course your LUKS device.



      First you'll be prompted to enter an (existing) password to unlock the drive. If everything works well, you should get an output like this:



      Enter any LUKS passphrase:
      key slot 0 unlocked.
      Command successful.


      Step 4: Create a mapper



      LUKS devices need to create a mapper that can then be referenced in the fstab. Open /etc/crypttab



      sudo nano /etc/crypttab


      and add then a line like this:



      sdX_crypt      /dev/sdX  /root/keyfile  luks


      or you can use the UUID of the device:



      sdX_crypt      /dev/disk/by-uuid/247ad289-dbe5-4419-9965-e3cd30f0b080  /root/keyfile  luks


      sdX_crypt is the name of the mapper that is being created. You can use here any name e.g. "music" or "movies" or "sfdsfawe" ....



      Save and close the file by issuing ctrl-x, enter, enter. Ctrl-x closes nano but first it asks to save the file [yes = enter] and what the name shall be [same name = enter].



      What we have done there actually is telling that /root/keyfile shall be used instead of password entry to unlock the drive.



      Step 5: Mount the device in fstab



      Now, we have an unlocked device (well, not yet but when the system is being booted up) and we just need to mount it now. Open /etc/fstab:



      sudo nano /etc/fstab


      and add a new entry like:



      /dev/mapper/sdX_crypt  /media/sdX     ext3    defaults        0       2


      Make sure you have the correct mapper name that you added in step 4. Also make sure that the mount point/folder exists. After having added it, save again the file and close it (ctrl-x, enter, enter).



      Step 6: Reboot or remount



      That's it. Now you can reboot and the additional devices should be auto-unlocked and mounted. You can also test it by remounting all devices:



      sudo mount -a





      share|improve this answer













      These instructions from howtoforge.com got me up and running with an automatically decrypting volume.



      How to: Automatically Unlock LUKS Encrypted Drives With A Keyfile



      Step 1: Create a random keyfile



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


      Step 2: Make the keyfile read-only to root



      sudo chmod 0400 /root/keyfile


      That will make the keyfile readable only by root. If someone get access to this keyfile, then you have a bigger problem on your computer anyway.



      Alternatively chown your desired keyfile to root:root and move it into the /root folder



      Step 3: Add the keyfile to LUKS



      LUKS/dm_crypt enabled devices may hold up to 10 different keyfiles/passwords. So, next to having the already setup password we're going to add this keyfile as additional authorization method.



      sudo cryptsetup luksAddKey /dev/sdX /root/keyfile


      sdX is of course your LUKS device.



      First you'll be prompted to enter an (existing) password to unlock the drive. If everything works well, you should get an output like this:



      Enter any LUKS passphrase:
      key slot 0 unlocked.
      Command successful.


      Step 4: Create a mapper



      LUKS devices need to create a mapper that can then be referenced in the fstab. Open /etc/crypttab



      sudo nano /etc/crypttab


      and add then a line like this:



      sdX_crypt      /dev/sdX  /root/keyfile  luks


      or you can use the UUID of the device:



      sdX_crypt      /dev/disk/by-uuid/247ad289-dbe5-4419-9965-e3cd30f0b080  /root/keyfile  luks


      sdX_crypt is the name of the mapper that is being created. You can use here any name e.g. "music" or "movies" or "sfdsfawe" ....



      Save and close the file by issuing ctrl-x, enter, enter. Ctrl-x closes nano but first it asks to save the file [yes = enter] and what the name shall be [same name = enter].



      What we have done there actually is telling that /root/keyfile shall be used instead of password entry to unlock the drive.



      Step 5: Mount the device in fstab



      Now, we have an unlocked device (well, not yet but when the system is being booted up) and we just need to mount it now. Open /etc/fstab:



      sudo nano /etc/fstab


      and add a new entry like:



      /dev/mapper/sdX_crypt  /media/sdX     ext3    defaults        0       2


      Make sure you have the correct mapper name that you added in step 4. Also make sure that the mount point/folder exists. After having added it, save again the file and close it (ctrl-x, enter, enter).



      Step 6: Reboot or remount



      That's it. Now you can reboot and the additional devices should be auto-unlocked and mounted. You can also test it by remounting all devices:



      sudo mount -a






      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Aug 1 '13 at 20:59









      The New GuyThe New Guy

      16111




      16111








      • 1





        you forget to update initramfs, 100% needed

        – 3pic
        Aug 13 '15 at 7:28














      • 1





        you forget to update initramfs, 100% needed

        – 3pic
        Aug 13 '15 at 7:28








      1




      1





      you forget to update initramfs, 100% needed

      – 3pic
      Aug 13 '15 at 7:28





      you forget to update initramfs, 100% needed

      – 3pic
      Aug 13 '15 at 7:28











      6














      Improving Randy Orrison's answer, here is a small script I created, that will make system fallback to asking user for password if it fails to find the keyfile.



      #!/bin/sh

      ask_for_password () {
      cryptkey="Unlocking the disk $cryptsource ($crypttarget)nEnter passphrase: "
      if [ -x /bin/plymouth ] && plymouth --ping; then
      cryptkeyscript="plymouth ask-for-password --prompt"
      cryptkey=$(printf "$cryptkey")
      else
      cryptkeyscript="/lib/cryptsetup/askpass"
      fi
      $cryptkeyscript "$cryptkey"
      }

      device=$(echo $1 | cut -d: -f1)
      filepath=$(echo $1 | cut -d: -f2)

      # Ask for password if device doesn't exist
      if [ ! -b $device ]; then
      ask_for_password
      exit
      fi

      mkdir /tmp/auto_unlocker
      mount $device /tmp/auto_unlocker

      # Again ask for password if device exist but file doesn't exist
      if [ ! -e /tmp/auto_unlocker$filepath ]; then
      ask_for_password
      else
      cat /tmp/auto_unlocker$filepath
      fi

      umount /tmp/auto_unlocker


      Save it and replace keyscript=/lib/cryptsetup/scripts/passdev in /etc/crypttab with the path to this file and run sudo update-initramfs -uv and you are done.






      share|improve this answer


























      • I guess your solution is not working for usb drive for more than one keyfile. I mean if i have more than one encrypted partition (home, swap, root). It seams that it does not unmounts USB driver after cat command. Do you have any idea how to fix it?

        – Khamidulla
        Jun 2 '16 at 1:29











      • This is working for me (Xubuntu 17.10) but I had to edit grub and remove "splash". Also I had to save the file in a proper location (/lib/cryptsetup/scripts/unlock_custom) and chmod it 755. Not sure if splash or copying in the specific place made it work for me, but it didn't work before. Anyway, it works but at boot, after Startet AppArmor initialization. I get: A start job is running for dev-disk keyfile.device (1m 30s). After the 90s X starts and I can use my system... no idea how to fix this start job...

        – firepol
        Apr 15 '18 at 21:18
















      6














      Improving Randy Orrison's answer, here is a small script I created, that will make system fallback to asking user for password if it fails to find the keyfile.



      #!/bin/sh

      ask_for_password () {
      cryptkey="Unlocking the disk $cryptsource ($crypttarget)nEnter passphrase: "
      if [ -x /bin/plymouth ] && plymouth --ping; then
      cryptkeyscript="plymouth ask-for-password --prompt"
      cryptkey=$(printf "$cryptkey")
      else
      cryptkeyscript="/lib/cryptsetup/askpass"
      fi
      $cryptkeyscript "$cryptkey"
      }

      device=$(echo $1 | cut -d: -f1)
      filepath=$(echo $1 | cut -d: -f2)

      # Ask for password if device doesn't exist
      if [ ! -b $device ]; then
      ask_for_password
      exit
      fi

      mkdir /tmp/auto_unlocker
      mount $device /tmp/auto_unlocker

      # Again ask for password if device exist but file doesn't exist
      if [ ! -e /tmp/auto_unlocker$filepath ]; then
      ask_for_password
      else
      cat /tmp/auto_unlocker$filepath
      fi

      umount /tmp/auto_unlocker


      Save it and replace keyscript=/lib/cryptsetup/scripts/passdev in /etc/crypttab with the path to this file and run sudo update-initramfs -uv and you are done.






      share|improve this answer


























      • I guess your solution is not working for usb drive for more than one keyfile. I mean if i have more than one encrypted partition (home, swap, root). It seams that it does not unmounts USB driver after cat command. Do you have any idea how to fix it?

        – Khamidulla
        Jun 2 '16 at 1:29











      • This is working for me (Xubuntu 17.10) but I had to edit grub and remove "splash". Also I had to save the file in a proper location (/lib/cryptsetup/scripts/unlock_custom) and chmod it 755. Not sure if splash or copying in the specific place made it work for me, but it didn't work before. Anyway, it works but at boot, after Startet AppArmor initialization. I get: A start job is running for dev-disk keyfile.device (1m 30s). After the 90s X starts and I can use my system... no idea how to fix this start job...

        – firepol
        Apr 15 '18 at 21:18














      6












      6








      6







      Improving Randy Orrison's answer, here is a small script I created, that will make system fallback to asking user for password if it fails to find the keyfile.



      #!/bin/sh

      ask_for_password () {
      cryptkey="Unlocking the disk $cryptsource ($crypttarget)nEnter passphrase: "
      if [ -x /bin/plymouth ] && plymouth --ping; then
      cryptkeyscript="plymouth ask-for-password --prompt"
      cryptkey=$(printf "$cryptkey")
      else
      cryptkeyscript="/lib/cryptsetup/askpass"
      fi
      $cryptkeyscript "$cryptkey"
      }

      device=$(echo $1 | cut -d: -f1)
      filepath=$(echo $1 | cut -d: -f2)

      # Ask for password if device doesn't exist
      if [ ! -b $device ]; then
      ask_for_password
      exit
      fi

      mkdir /tmp/auto_unlocker
      mount $device /tmp/auto_unlocker

      # Again ask for password if device exist but file doesn't exist
      if [ ! -e /tmp/auto_unlocker$filepath ]; then
      ask_for_password
      else
      cat /tmp/auto_unlocker$filepath
      fi

      umount /tmp/auto_unlocker


      Save it and replace keyscript=/lib/cryptsetup/scripts/passdev in /etc/crypttab with the path to this file and run sudo update-initramfs -uv and you are done.






      share|improve this answer















      Improving Randy Orrison's answer, here is a small script I created, that will make system fallback to asking user for password if it fails to find the keyfile.



      #!/bin/sh

      ask_for_password () {
      cryptkey="Unlocking the disk $cryptsource ($crypttarget)nEnter passphrase: "
      if [ -x /bin/plymouth ] && plymouth --ping; then
      cryptkeyscript="plymouth ask-for-password --prompt"
      cryptkey=$(printf "$cryptkey")
      else
      cryptkeyscript="/lib/cryptsetup/askpass"
      fi
      $cryptkeyscript "$cryptkey"
      }

      device=$(echo $1 | cut -d: -f1)
      filepath=$(echo $1 | cut -d: -f2)

      # Ask for password if device doesn't exist
      if [ ! -b $device ]; then
      ask_for_password
      exit
      fi

      mkdir /tmp/auto_unlocker
      mount $device /tmp/auto_unlocker

      # Again ask for password if device exist but file doesn't exist
      if [ ! -e /tmp/auto_unlocker$filepath ]; then
      ask_for_password
      else
      cat /tmp/auto_unlocker$filepath
      fi

      umount /tmp/auto_unlocker


      Save it and replace keyscript=/lib/cryptsetup/scripts/passdev in /etc/crypttab with the path to this file and run sudo update-initramfs -uv and you are done.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Apr 13 '17 at 12:23









      Community

      1




      1










      answered Aug 5 '15 at 14:15









      VarunAgwVarunAgw

      286416




      286416













      • I guess your solution is not working for usb drive for more than one keyfile. I mean if i have more than one encrypted partition (home, swap, root). It seams that it does not unmounts USB driver after cat command. Do you have any idea how to fix it?

        – Khamidulla
        Jun 2 '16 at 1:29











      • This is working for me (Xubuntu 17.10) but I had to edit grub and remove "splash". Also I had to save the file in a proper location (/lib/cryptsetup/scripts/unlock_custom) and chmod it 755. Not sure if splash or copying in the specific place made it work for me, but it didn't work before. Anyway, it works but at boot, after Startet AppArmor initialization. I get: A start job is running for dev-disk keyfile.device (1m 30s). After the 90s X starts and I can use my system... no idea how to fix this start job...

        – firepol
        Apr 15 '18 at 21:18



















      • I guess your solution is not working for usb drive for more than one keyfile. I mean if i have more than one encrypted partition (home, swap, root). It seams that it does not unmounts USB driver after cat command. Do you have any idea how to fix it?

        – Khamidulla
        Jun 2 '16 at 1:29











      • This is working for me (Xubuntu 17.10) but I had to edit grub and remove "splash". Also I had to save the file in a proper location (/lib/cryptsetup/scripts/unlock_custom) and chmod it 755. Not sure if splash or copying in the specific place made it work for me, but it didn't work before. Anyway, it works but at boot, after Startet AppArmor initialization. I get: A start job is running for dev-disk keyfile.device (1m 30s). After the 90s X starts and I can use my system... no idea how to fix this start job...

        – firepol
        Apr 15 '18 at 21:18

















      I guess your solution is not working for usb drive for more than one keyfile. I mean if i have more than one encrypted partition (home, swap, root). It seams that it does not unmounts USB driver after cat command. Do you have any idea how to fix it?

      – Khamidulla
      Jun 2 '16 at 1:29





      I guess your solution is not working for usb drive for more than one keyfile. I mean if i have more than one encrypted partition (home, swap, root). It seams that it does not unmounts USB driver after cat command. Do you have any idea how to fix it?

      – Khamidulla
      Jun 2 '16 at 1:29













      This is working for me (Xubuntu 17.10) but I had to edit grub and remove "splash". Also I had to save the file in a proper location (/lib/cryptsetup/scripts/unlock_custom) and chmod it 755. Not sure if splash or copying in the specific place made it work for me, but it didn't work before. Anyway, it works but at boot, after Startet AppArmor initialization. I get: A start job is running for dev-disk keyfile.device (1m 30s). After the 90s X starts and I can use my system... no idea how to fix this start job...

      – firepol
      Apr 15 '18 at 21:18





      This is working for me (Xubuntu 17.10) but I had to edit grub and remove "splash". Also I had to save the file in a proper location (/lib/cryptsetup/scripts/unlock_custom) and chmod it 755. Not sure if splash or copying in the specific place made it work for me, but it didn't work before. Anyway, it works but at boot, after Startet AppArmor initialization. I get: A start job is running for dev-disk keyfile.device (1m 30s). After the 90s X starts and I can use my system... no idea how to fix this start job...

      – firepol
      Apr 15 '18 at 21:18











      1














      @deitch
      I had the same setup like @Randy Orrison and ran into the same issue as you and it turns out is a bug of systemd which tries to mount the / filesystem again as it finds the corresponding entry in /et/crypttab.



      To resolve this i just removed the entry for sda5_crypt from /etc/crypttab once the update-initramfs -uv command was ran.



      Reeboot and everything works fine as intended.






      share|improve this answer




























        1














        @deitch
        I had the same setup like @Randy Orrison and ran into the same issue as you and it turns out is a bug of systemd which tries to mount the / filesystem again as it finds the corresponding entry in /et/crypttab.



        To resolve this i just removed the entry for sda5_crypt from /etc/crypttab once the update-initramfs -uv command was ran.



        Reeboot and everything works fine as intended.






        share|improve this answer


























          1












          1








          1







          @deitch
          I had the same setup like @Randy Orrison and ran into the same issue as you and it turns out is a bug of systemd which tries to mount the / filesystem again as it finds the corresponding entry in /et/crypttab.



          To resolve this i just removed the entry for sda5_crypt from /etc/crypttab once the update-initramfs -uv command was ran.



          Reeboot and everything works fine as intended.






          share|improve this answer













          @deitch
          I had the same setup like @Randy Orrison and ran into the same issue as you and it turns out is a bug of systemd which tries to mount the / filesystem again as it finds the corresponding entry in /et/crypttab.



          To resolve this i just removed the entry for sda5_crypt from /etc/crypttab once the update-initramfs -uv command was ran.



          Reeboot and everything works fine as intended.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 6 '18 at 11:01









          mukul kirtanemukul kirtane

          111




          111























              0














              the service for mounting or starting device where the key is stored takes about 1min 30 secs just like @firepol said. Is there any way the time could be decreased ?






              share|improve this answer




























                0














                the service for mounting or starting device where the key is stored takes about 1min 30 secs just like @firepol said. Is there any way the time could be decreased ?






                share|improve this answer


























                  0












                  0








                  0







                  the service for mounting or starting device where the key is stored takes about 1min 30 secs just like @firepol said. Is there any way the time could be decreased ?






                  share|improve this answer













                  the service for mounting or starting device where the key is stored takes about 1min 30 secs just like @firepol said. Is there any way the time could be decreased ?







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 1 hour ago









                  roshan handeroshan hande

                  11




                  11






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Ask Ubuntu!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f59487%2fhow-to-configure-lvm-luks-to-autodecrypt-partition%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      GameSpot

                      日野市

                      Tu-95轟炸機