Unlocking LUKS with USB key - method - seeking help to improve - Page 3
FedoraForum.org - Fedora Support Forums and Community
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 31 to 45 of 51
  1. #31
    Join Date
    Jun 2009
    Location
    Biggleswade, Bedfordshire, England
    Posts
    22

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    Update for Fedora 16

    Dracut has changed again, so the modifications to cryptroot-ask.sh are different.

    Modify cryptroot-ask.sh in /usr/share/dracut/modules.d/90crypt

    Above line 101 (if [ $ask_passphrase -ne 0 ]; then), add the following:

    Code:
    usbkey=/dev/disk/by-id/usb-Ut165_USB_Flash_Disk_00000000000688-0\:0
    if [ -e $usbkey ]; then
      ask_passphrase=0
      echo "USB Key detected - unlocking partition $device ..."
      dd if=$usbkey bs=1 count=4096 | cryptsetup luksOpen $device $luksname --key-file=-
    fi
    Where usbkey= matches your USB device, as per the instructions for Fedora 15.

    Note: With systemd and the new 3.x kernel, there appears to be no need for delays to wait for devices to be detected.

  2. #32
    Join Date
    Aug 2007
    Posts
    24

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    Please note that F16 will miss some UUIDs if they are not ready on time, this seems to be updated in F17.

  3. #33
    Join Date
    Oct 2012
    Location
    India
    Posts
    4

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    Hello,

    I had fedora-16 running with 3.1.0-7 kernel and the USB Luks was working fine (without prompting password). Today I have updated the system and now F16 kernel updated to 3.4.9 and the USB+Luks is not working. I was prompted for the password. Is there any additional configuration required for USB+Luks if I upgrade the kernel?

    Thank you.

    Best,
    Sathish.

    ---------- Post added at 03:53 PM ---------- Previous post was at 02:01 PM ----------

    I have also added the following lines in to cryptroot-ask.sh file:

    usbkey=/dev/disk/by-id/usb-SanDisk_Cruzer_Edge_20060A2F0083A5-0\:0
    if [ -e $usbkey ]; then
    ask_passphrase=0
    echo "USB Key detected - unlocking partition $device ..."
    dd if=$usbkey bs=4096 count=6 | cryptsetup luksOpen $device $luksname --key-file=-
    fi
    And executed /usr/libexec/plymouth/plymouth-update-initrd command. Now I am getting the following messages:

    USB Key detected - unlocking partition mylukspartition
    /sbin/cryptroot_ask: line 150: dd: command not found

    and prompts for the password..

    Any suggestion to solve this?

    Thank you.

    Best,
    Sathish.

  4. #34
    Join Date
    Jun 2009
    Location
    Biggleswade, Bedfordshire, England
    Posts
    22

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    This caught me out with F17 a little while ago. I guess the updates to dracut have rippled down to F16 now. My apologies for not posting an update here.

    The issue is down to 'dd' not being loaded into the initrd image. You need to modify module-setup.sh in /usr/lib/dracut/modules.d/90crypt/ and add inst /usr/bin/dd into the install() section. e.g.

    Code:
    install() {
        dracut_install cryptsetup rmdir readlink umount
        inst "$moddir"/cryptroot-ask.sh /sbin/cryptroot-ask
        inst "$moddir"/probe-keydev.sh /sbin/probe-keydev
        inst_hook cmdline 10 "$moddir/parse-keydev.sh"
        inst_hook cmdline 30 "$moddir/parse-crypt.sh"
        inst_hook pre-pivot-cleanup 30 "$moddir/crypt-cleanup.sh"
        inst_simple /etc/crypttab
        inst "$moddir/crypt-lib.sh" "/lib/dracut-crypt-lib.sh"
        inst /usr/bin/dd
    }
    These two files are the only ones needed for LUKS unlocking, so I would urge people to keep a back-up copy as RPM updates do not check for modifications to shell scripts and updates to dracut will replace any mods.

    You will need to run /usr/libexec/plymouth/plymouth-update-initrd after these modifications to create a new initrd file. A tip you may find useful is to block a new kernel from updating if you see an update to dracut. Update dracut, modify the two scripts, then apply the kernel update. A new initrd will be created and it saves you a step and a reboot.

  5. #35
    Join Date
    Oct 2012
    Location
    India
    Posts
    4

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    Hello gaztronics,

    Thanks to you. Your guidance fixed the issue and USB-Luks is working fine. The only difference is that the path of dd command in F16 is /bin/dd.

    Thanks again.

    Best,
    Sathish.

  6. #36
    Join Date
    Feb 2013
    Location
    russia
    Posts
    2

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    Hi all, I have that issue (fedora 18 x64):
    /etc/default/grub http://fpaste.org/ndo0
    and usb flash, labled "key" with file "lukskey" in root
    but when dracut is executing got that error:

    systemd-cryptsetup-generator[46]: Unknown kernel switch rd.luks.key=/lukskey:LABEL=key. Ignoring

    Any ideas?
    Last edited by ambush; 11th February 2013 at 02:49 PM.

  7. #37
    Join Date
    Feb 2013
    Location
    Prague
    Posts
    8

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    Hi ambush,
    the solution of problem is there: https://bugzilla.redhat.com/show_bug.cgi?id=905683
    Both solutions are working - rd.luks.key or "Unlocking LUKS with USB key" - in F18

  8. #38
    Join Date
    Feb 2013
    Location
    russia
    Posts
    2

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    vzak11, thank you, works good.

  9. #39
    Join Date
    Jun 2009
    Location
    Biggleswade, Bedfordshire, England
    Posts
    22

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    Caution for Fedora 19: I have not worked out how to implement this method with the latest dracut/systemd changes. Help and advice welcome from those in the know.

  10. #40
    Join Date
    Feb 2009
    Posts
    24

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    For me to get rd.luks.key on Fedora 19 to work, I needed to add statements below to /etc/dracut.conf and rebuild the initramfs:

    # dracut modules to omit
    omit_dracutmodules+=" systemd "

    # dracut modules to add to the default
    add_dracutmodules+=" lvm crypt "
    Note: I am using LVM so if you are not you should be able to omit 'lvm'.

  11. #41
    Join Date
    Oct 2012
    Location
    India
    Posts
    4

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    Hello,

    I have problem with USB Luks in F19. I store the key into a USB using the following command:

    dd if=lukskey of=/dev/sdb bs=4096 count=6

    And the device id is /dev/disk/by-id/usb-SanDisk_Cruzer_Edge_20060774500A2F0057AC-0:0. How can I specify the rd.luks.key in /etc/default/grub file?

    I am currently using F16 with USB luks successfully but unable to make it on F19.

    Could someone help me?

    Thank you.

  12. #42
    Join Date
    Oct 2012
    Location
    India
    Posts
    4

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    Update:

    I copied the key file into /dev/sdb1 and configured grub as follows:

    rd.luks.key=lukskey:/dev/sdb1

    Now, I am not getting password prompt which is great.. but once the key accepted it takes 2 minutes to get login screen. Is it normal or I am missing any configuration?


    Thank you.

  13. #43
    Join Date
    Aug 2007
    Posts
    24

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    In the bug report 905683 there was a proposed workaround and patch that should solve this problem. But even with the patch, the password dialogue still appeared for me. Tracking down the problem I found out that actually all this is working fine. However there are incompatibilities between the old non-systemd way of booting and new with systemd used. Thus switching to systemd requires some changes and I hope this post will help.

    I. The incompatibilities
    a) rd.luks.key
    - non-systemd format is:
    rd.luks.key=<keypath>:<keydev>:<luksdev>

    Note the <keypath> is relative to the <keydev> mounting point.

    - for systemd it is “the password file”
    In here the key path is the 'full' path, so not relative to the key device mount point.

    b) crypttab file handling (if not explicitely blocked by 'rd.luks.crypttab=0')
    If command line 'rd.luks.uuid=' entry is found also in crypttab the latter is preferred, with following exceptions:
    - non-systemd
    If the crypttab 3rd entry (password/file) is 'none', the command line 'rd.luks.key=' will be used instead.

    - systemd
    If the crypttab 3rd entry (password/file) is 'none', the command line 'rd.luks.key=' will NOT be used instead.

    c) rd.luks.key.tout
    - non-systemd
    It specifies the timeout for mounting the key storage device, when it passes and the device is not found the password dialogue appears.

    - systemd
    This parameter is not available directly in systemd. It means that having a key file on external device that is not mounted quickly enough the key file will not be used.

    e) rd.luks.uuid
    - non-systemd
    The shortest but unique beginning of UUID is acceptable.

    - systemd
    The full long UUID number must be specified.
    (bugzilla 980764)


    II. How to switch to systemd?
    a) use full path, and ONLY the path (so remove any ':<>:<>' after it), in 'rd.luks.key='

    b) ensure valid full key path is in crypttab (not 'none' nor '-') or do not use crypttab by
    setting 'rd.luks.crypttab=0'.
    Note: the crypttab file that goes into initramfs is not the same as /etc/crypttab found in the system. It is based on it but entries are filtered out by dracut during the image creation. The logic adds only system directories, the '/home' is omitted. Thus if there is a need of having '/home' in crypttab, its mount point must be specified in fstab and the fstab must be explicitly added during dracut image creation with '--add-fstab=' option.

    c) create systemd mount unit file for the key device or alternatively add such entry into fstab, with the 'x-systemd.device-timeout=' option in it. This will work as 'rd.luks.key.tout' for old way. If using fstab way the appropriate fstab file must be included during dracut image creation as mentioned above ('--add-fstab=' option).



    Example:
    Assume there are following standard partitons:
    - swap luks with UUID=_swap_luks_uuid_
    - /home luks with UUID=_home_luks_uuid_
    - key device with UUID=_key_dev_uuid_ with the key.file in its root directory, vfat formatted

    1) old non-systemd way
    - block systemd during dracut image generation and add vfat module for key device by adding this into /etc/dracut.conf.d/luks-workaround.conf:
    Code:
    omit_dracutmodules+=" systemd "
    add_drivers+=" vfat"

    - fstab
    Code:
    /dev/mapper/luks-_home_luks_uuid_ /home <rest of the options>
    /dev/mapper/luks-_swap_luks_uuid_ swap <rest of the options>
    -crypttab (unless not using it)
    Code:
    luks-_home_luks_uuid_ UUID=_home_luks_uuid_ none <rest of the options>
    luks-_swap_luks_uuid_ UUID=_swap_luks_uuid_ none <rest of the options>
    - command line
    Code:
    rd.luks.uuid=luks-_just_beginning_of_home_luks_uuid_ rd.luks.uuid=luks-_just_beginning_swap_luks_uuid_ rd.luks.key=key.file:UUID=_key_dev_uuid_  rd.luks.key.tout=5
    -regenerate initramfs/grub.conf:
    Code:
    grub2-mkconfig -o /boot/grub2/grub.cfg
    dracut -f /boot/initramfs-`uname -r`.img
    2) new systemd way
    - add fstab for key device mount and timeout (and to get /home in generated crypttab if needed) and add vfat module for key device during dracut image generation by adding this into /etc/dracut.conf.d/luks-workaround.conf:
    Code:
    add_fstab+=" /etc/fstab"
    add_drivers+=" vfat"
    - fstab (assume the key device will be mounted on /mnt/keydev)
    Code:
    /dev/mapper/luks-_home_luks_uuid_ /home <rest of the options>
    /dev/mapper/luks-_swap_luks_uuid_ swap <rest of the options>
    UUID=_key_dev_uuid_ /mnt/keydev vfat defaults,ro,umask=0277,x-systemd.device-timeout=5 0 0
    -crypttab (unless not using it)
    Code:
    luks-_home_luks_uuid_ UUID=_home_luks_uuid_ /mnt/keydev/key.file <rest of the options>
    luks-_swap_luks_uuid_ UUID=_swap_luks_uuid_ /mnt/keydev/key.file <rest of the options>
    - command line (the 'rd.' might be omitted)
    Taking everything from command line, ignoring crypttab:
    Code:
    rd.luks.crypttab=0 rd.luks.uuid=luks-_home_luks_uuid_ rd.luks.uuid=luks-_swap_luks_uuid_ rd.luks.key=/mnt/keydev/key.file
    Alternatively nothing might be added to the command line providing everything is in crypttab. However, if any default initramfs is used it won't boot then, so having UUIDs in command line might be helpful.

    - regenerate initramfs/grub.conf:
    Code:
    grub2-mkconfig -o /boot/grub2/grub.cfg
    dracut -f /boot/initramfs-`uname -r`.img
    Note: as the command line key works thanks to the systemd patch, the timeout when the key device is not present is not working. It is possible to switch to the password adding 'nofail' to the fstab for key device, so:
    Code:
    UUID=_key_dev_uuid_ /mnt/keydev vfat defaults,ro,umask=0277,x-systemd.device-timeout=5,nofail 0 0
    and deactivate the the key file in command line:
    Code:
    rd.luks.crypttab=0 rd.luks.uuid=luks-_home_luks_uuid_ rd.luks.uuid=luks-_swap_luks_uuid_ rd.luks.key=none
    Last edited by prudy; 7th January 2014 at 08:09 PM.

  14. #44
    Join Date
    Aug 2007
    Posts
    24

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    For in a nutshell version skip to 'Automate this' below.
    The problem with systemd fallback to password request is that the crypttab services have strong dependency for the key device. Rule 'RequiresMountsFor=', pointing at the key file, is created by the cryptsetup-generator in systemd. It is then transformed to 'Requires=' and 'After=' rules. It means that if the key device is not present/mounted the cryptsetup will not be even started due to dependency. This results in getting the systemd console instead of password request.

    The adequate rule would have to be 'WantsMountsFor=', that would transform then to 'Wants=' and 'After=' rules, but there is nothing like that in systemd (yet?).

    Systemd allows using snippet files overriding service files. The workaround for password fallback would be to unset the 'RequiresMountsFor=' rule overriding it to empty and then set custom 'Wants=' and 'After=' rules. Well, it seems that overriding does not work, even if mentioned in the manual, it is only possible to add new dependencies but not changing them.

    Hopefully with a small trick it is still possible to achieve fallback to password request.
    1. Cannot override 'RequiresMountsFor=' to empty, so let it be. Instead of giving the path to the mounted key file, give the path to a symlink to that file. With this, 'RequiresMountsFor=' will be satisfied as symlink always exists, so cryptsetup service will start. Moreover the password will be requested when link is dead (so the key file device is not mounted).
    Use symlink in /etc/crypttab:
    Code:
    luks-_home_luks_uuid_ UUID=_home_luks_uuid_ /tmp/luks-_home_luks_uuid_ <rest of the options>
    luks-_swap_luks_uuid_ UUID=_swap_luks_uuid_ /tmp/luks-_swap_luks_uuid_ <rest of the options>
    Where /tmp/luks-_home_luks_uuid_ and /tmp/luks-_swap_luks_uuid_ are symlinks to the same /mnt/keydev/key.file.

    Note the symlink must be inside initramfs, not in runtime filesystem. But do not create it manually, it will be created automatically.

    2. Ensure the mount dependency will not get back automatically follow the symlink access request. To do this DO NOT put 'x-systemd.automount' into fstab. Also ensure key device is not automatically mounted and not giving error when cannot be mounted. So in fstab:
    Code:
    UUID=_key_dev_uuid_ /mnt/keydev vfat ro,umask=0277,x-systemd.device-timeout=8,noauto,nofail 0 0
    3. Create systemd snipped for each crypttab service. The snippet files (*.conf) must go into /etc/systemd/system/<service>.d/ to have a priority over generated service files. The naming convention for the cryptsetup service seems to be:
    systemd-cryptsetup@<encoded luks-_home_luks_uuid_>
    Encoding simply replaces '-' with '\\x2d'.
    Basing on the example setup there will be:
    Code:
    /etc/systemd/system/systemd-cryptsetup@<encoded luks-_home_luks_uuid_>.d/wants-password.conf
    /etc/systemd/system/systemd-cryptsetup@<encoded luks-_swap_luks_uuid_>.d/wants-password.conf
    The content of the first snipped conf file is:
    Code:
    [Unit]
    Description=Fixed %N
    After=mnt-keydev.mount
    Wants=mnt-keydev.mount
    
    [Service]
    ExecStartPre=-/usr/bin/ln -s /mnt/keydev/key.file  /tmp/luks-_home_luks_uuid_
    Where:
    - mnt-keydev – is, again encoded in systemd form ('-' for '/', no '/' at the beginning), mount directory to key file

    And for the second snipped just one line changes to:
    Code:
    ExecStartPre=-/usr/bin/ln -s /mnt/keydev/key.file  /tmp/luks-_swap_luks_uuid_
    Automate this.
    1. Put the attached script in /usr/lib/dracut/modules.d/90crypt-systemd-fix/module-setup.sh
    It takes care of the crypttab links replacing the key path with the symlink, in the crypttab in generated initramfs and creates snippet files. It works for me but might have some weakness so check if everything was created properly in intramfs.
    2. Leave the crypttab in original form with the key path, not with symlinks
    3. Add another line in /etc/dracut.conf.d/luks-workaround.conf:
    Code:
    add_dracutmodules+=" crypt-systemd-fix"
    so it looks now:
    Code:
    add_drivers+=" vfat"
    add_fstab+=" /etc/fstab"
    add_dracutmodules+=" crypt-systemd-fix"
    4. As everything comes from crypttab file, purge the command line from any luks.

    4. Create new image:
    Code:
    dracut -f
    Truly automate.
    I created the systemd poposal patch for this in 905683.
    Attached Files Attached Files
    Last edited by prudy; 20th April 2014 at 11:22 PM.

  15. #45
    Join Date
    Aug 2007
    Posts
    24

    Re: Unlocking LUKS with USB key - method - seeking help to improve

    Fedora 21 - using luks key on external device still does not work, the solution from previous post stopped working too.
    Below are workarounds for Fedora 21.

    Prerequisite:
    • 11111111-1111-1111-1111-111111111111 - UUID of the luks for /home (e.g. /dev/sda1)
    • /dev/mapper/home - attached decrypted luks for /home
    • 22222222-2222-2222-2222-222222222222 - UUID of the luks for swap (e.g. /dev/sda2)
    • /dev/mapper/swap - attached decrypted luks for swap
    • 3333-3333 - UUID of the device (vfat) with luks key in its root directory
    • unlocker.key - common key file to unlock luks partitions


    /etc/crypttab
    Code:
    home UUID=11111111-1111-1111-1111-111111111111 /tmp/unlocker.key
    swap UUID=22222222-2222-2222-2222-222222222222 /tmp/unlocker.key
    /etc/fstab
    Code:
    /dev/mapper/home /home ext4 x-systemd.device-timeout=0 1 2
    /dev/mapper/swap swap swap x-systemd.device-timeout=0 0 0
    UUID=3333-3333 /mnt/unlocker vfat ro,umask=0277,x-systemd.device-timeout=3,noauto 0 0
    where the x-systemd.device-timeout is the timout after which the fallback to passphrase is issued if key device is not found

    /etc/systemd/system/systemd-cryptsetup@.service.d/luks-key-device.conf
    Code:
    # This is a workaround for systemd not able to ask for a luks password
    # if the device with luks key file is not available (e.g. USB not inserted).
    # Bugzilla 905683 "rd.luks.key is ignored"
    
    [Unit]
    Description=Bugzilla 905683 Cryptography Setup for %I
    Documentation=https://bugzilla.redhat.com/show_bug.cgi?id=905683 http://forums.fedoraforum.org/showpost.php?p=1696031&postcount=45
    After=mnt-unlocker.mount
    Wants=mnt-unlocker.mount
    RequiresMountsFor=/tmp/unlocker.key
    
    [Service]
    ExecStartPre=-/usr/bin/ln -s /mnt/unlocker/unlocker.key /tmp/unlocker.key
    That's all. Additionally, if resume from swap partition is needed:

    /etc/systemd/system/mnt-unlocker.mount.d/umount-initramfs.conf
    Code:
    # Starting with Fedora 21, when a device is mounted in initramfs,
    # its .mount systemd unit is set to inactive when leaving initramfs,
    # but it cannot be started again immediately after that in OS.
    # Maybe the reason is that switch root is no-block.
    # Anyway this file makes this possible.
    
    [Unit]
    Conflicts=initrd-cleanup.service
    /etc/dracut.conf.d/luks-workaround.conf
    Code:
    # Note: All this is actually needed only for resume from encrypted swap
    #       If resume is not used this file might be removed.
    
    # Use fstab for discovering mount options
    use_fstab="yes"
    
    # Define initramfs fstab entry for luks key device.
    # A timeout defines time after which fallback to password request is used if the device is not present/inserted
    # This line is actually a copy of the same entry from /etc/fstab
    fstab_lines+=("UUID=1111-1111 /mnt/unlocker vfat ro,umask=0277,x-systemd.device-timeout=5,noauto 0 0")
    
    # Bring up resume device (swap partition) - relevant entry is needed in /etc/crypttab and /etc/fstab
    add_device+=" /dev/mapper/swap"
    
    # Include workaround for systemd to fallback to passphrase request for resume partition if no luks key device is present
    install_items+=" /etc/systemd/system/systemd-cryptsetup@.service.d/luks-key-device.conf"
    
    # Include workaround for systemd to mount luks key device again in OS, which was just mounted in initramfs
    install_items+=" /etc/systemd/system/mnt-unlocker.mount.d/umount-initramfs.conf"
    As the resume is done in initramfs, the image must be updated:
    Code:
    dracut -f

Page 3 of 4 FirstFirst 1 2 3 4 LastLast

Similar Threads

  1. help unlocking a folder to all users
    By DeadPark121 in forum Using Fedora
    Replies: 11
    Last Post: 7th October 2008, 05:03 PM
  2. Locking and unlocking screen, please help!
    By Impact4ever in forum Using Fedora
    Replies: 3
    Last Post: 31st August 2005, 03:30 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •