LUKS + KeyFile + AutoMount? [SOLVED]

  • Hi subzero79,

    Have you been able to implement the instructions from


    https://blog.iwakd.de/headless-luks-decryption-via-ssh


    in omv 5?


    In the decrypt.target file, I am having problems with the line:

    Code
    Requires=systemd-cryptsetup@crypto.service srv.mount start-full-system.service


    The system does not seem to create a systemd-cryptsetup@crypto.service and I can figure what to replace srv.mount with.


    Also when I runt the command


    Code
    # systemctl status systemd-cryptsetup@crypto.service


    I get:

    Code
    Unit systemd-cryptsetup@crypto.service could not be found.

    It's like omv5 does not read the crypttab.



    I am stuck. Any direction would be appreciated.

  • I followed your instructions on the git page.

    When I went to add a device that was unlocked I go the following error in a GUI popup window:


    Any ideas?


    BTW if this works, do you think the early ssh method mentioned in the original like would work?

  • No, it won’t work.

    The plugin fork did a lot of changes internally.

    The old ssh method relied a lot on systemd. How it was mechanized is documented in a blog post which was mentioned in the fork. You can follow that post and organize the units manually. Or you can use the other ssh method which uses drop bear at initramfs.


    I do not use it since I have omv as virtual machine so I can automate unlock something like `ssh pve qm terminal $vmid`


    I have to check the plugin error, look like is missing the db section entry, that should be added at install of the plugin.

  • Thanks subzero79 for mentioning the drop bear method. I think it works perfectly.


    For any one else that would like to unlock LUKS partitions remotely by ssh using dropbear at boot up here is what I did.

    * My setup is as such: OMV 5, LUKS+UnionFS+SnapRaid which I setup using https://michaelxander.com/diy-nas/. Becarefull not to reboot here if you are using unionfs becuase the system will panic and drop you to rescue mode because the LUKS drives have not been encrypted. (post 247546)

    * I updated my /etc/crypttab to look like this

    Code: /etc/crypttab
    # <target name> <source device> <key file> <options>
    sdb-crypt /dev/sdb none luks,initramfs
    sdc-crypt /dev/sdc none luks,initramfs
    sdd-crypt /dev/sdd none luks,initramfs

    Just by doing this at the next reboot the system will ask you for the pass phrase for each disk. This is nice in itself.


    Also note you can change luks,initramfs to luks,initramfs,keyscript=decrypt_keyctl if you want the same password to cached for 60 seconds and used on all the drives. There are other scritpts that my be hand in /lib/cryptsetup/scripts


    Setting up Dropbear

    * I guided by the the instructions on on how to setup Dropbear at https://www.arminpech.de/2019/12/23/debian-unlock-luks-root-partition-remotely-by-ssh-using-dropbear/ I did this:

    ** apt-get install dropbear-initramfs

    ** I copied my public key from by putty client to /etc/dropbear-initramfs/authorized_keys You have to do this because Dropbear has disabled password based logins.

    ** Changed the DROPBEAR_OPTIONS line in /etc/dropbear-initramfs/config

    Code: /etc/dropbear-initramfs/config
    DROPBEAR_OPTIONS="-p 2222"

    ** Ran update-initramfs -k all -u


    Results

    When your system reboots it will wait for you to enter the passphrase for each disk. But now you can SSH into the system too.

    I used putty with my private key that is paired with the public key that I added in the step above to port 2222.

    You login as root and are automatically taken to the command prompt.

    Enter bin/cryptroot-unlock and respond the passphrases for each disk.

    Afterwards you will be logged out and the boot process will proceed as normal.



    #OMV5.x









  • Posting here for anyone that is subscribed to this thread that may be able to help.

    LUKS Automount no longer working on new hardware


    I moved my OMV setup from an old Intel server to a HP small form factor PC and now the auto unlock with crypttab only works with my first data disk (data1) the other three disks (data2,data3,data4) won't auto unlock when OMV loads. It works if I both unlock and mount them manually with the web interface. I don't understand why the first drive unlocks and the others don't.


    data 1,2, and 3 are on the same usb enclosure, with data4 being an internal drive.


    This worked fine on the old server, I tried setting up a brand new install of OMV on a flash drive as a test and got the same result: only the first UUID will unlock. Newly formatted LUKS drives wont auto mount either so I know its not a problem with the existing drives.


    I can always just unlock and mount manually easily as this system runs 24/7/365 without many reboots but it worked fine before and I don't understand why it doesn't now just because I moved to a new PC. Maybe its something related to the order disks are detected when debian starts on this PC? It would make more sense if there was a reasonable explanation.


    EDIT: Now manually unlocking and mounting the drives isn't working ether.


    When I manually unlock the drives it shows this error when trying to mount them because the drives aren't listed in fstab.

    Code
    Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; mount -v --source '/dev/disk/by-label/data2' 2>&1' with exit code '1': mount: /dev/disk/by-label/data2: can't find mount source /dev/disk/by-label/data2 in /etc/fstab.

    If they ARE listed in fstab the startup will fail because it tries to mount them and it cannot because they are locked, and then OMV drops to emergency shell.


    So unless I comment out the drives from fstab when it drops to emergency mode, start OMV, then uncomment them, then manually unlock and mount the drives, my OMV just doesn't work now.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!