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:

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

# systemctl status systemd-cryptsetup@crypto.service

I get:

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:

failed to execute XPath query '//system/storage/luks'


Error #0:
OMV\Config\DatabaseException: Failed to execute XPath query '//system/storage/luks'. in /usr/share/php/openmediavault/config/database.inc:262
Stack trace:
#0 /usr/share/openmediavault/engined/rpc/luks.inc(591): OMV\Config\Database->set(Object(OMV\Config\ConfigObject))
#1 [internal function]: OMVRpcServiceLuksMgmt->setCrypttab(Array, Array)
#2 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
#3 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('setCrypttab', Array, Array)
#4 /usr/sbin/omv-engined(537): OMV\Rpc\Rpc::call('LuksMgmt', 'setCrypttab', Array, Array, 1)
#5 {main}

Any ideas?

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

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

# <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

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.

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.

List the drives in the crypttab file as I noted above. That should prompt the kernal to ask for passwords for the luks drives.

You might also have to run

update-initramfs -k all -u

To update the initramfs image.

Sorry for refreshing that "very old" thread again but I am struggeling with one thing:

I would like to unlock more than 1 disk on startup with an USB stick. In my case I have 5 disks. It does indeed unlock the drives successfully but then the usb drive interfers with the names and mountpoints.

My drives are sda - sde and after having them decrypted they should map on sda-crypt - sde-crypt accordingly.

On boot the fstab is not working the devicelist "in a row" so it is likely that the usb stick occupies /dev/sdc and then it messes up with the additional mountpoints etc. so that for example mergerfs does not load properly either.

Is there a nice and decent way to get this solved? A delay maybe? Or can I make the usb stick recognised by the system as always sdf for example?

Is there some reason why are not using UUID= instead of /dev/sdx in your crypttab file?

Quote from gderf

Is there some reason why are not using UUID= instead of /dev/sdx in your crypttab file?

Good point, maybe I was a little lazy. I will change it to UUID and give it a go once I am back in the office.