LUKS disk encryption plugin

  • While the password is escaped for the shell, it is not enclosed in single quotes. I will look at changing this. Until then avoid characters that are interpreted by the bash shell like parentheses, ampersand, and dollar symbols.

    Just saw the updated LUKS plugin and that this was fixed. Thank you for doing this

  • Is it possible so halt on boot and wait für the encrypted disks to be unlocked through ssh?


    I want to setup 2 encrypted drives and ZFS on top, so to prevent the pool to fail I need the drives unlocked quite early. Since there is almost no reboot, manual unlocking is fine for me, but it has to be possible through SSH, since I am physically not near the server.


    Edit: I managed to unlock my drives during boot by sticking to this howto
    Keyfile is stored in root directory.

    Chaos is found in greatest abundance wherever order is being sought.
    It always defeats order, because it is better organized.
    Terry Pratchett

    Einmal editiert, zuletzt von riff-raff ()

  • Hello,


    I've got a stressful problem with my encryption trough this plugin.


    I created a full-disk encryption for my drives and everything is running fine. But I was bored to enter the password trough the gui and wanted to do it trough ssh. I realised none of those command worked:


    > cryptsetup open /dev/sdd sdd-crypt
    > sudo cryptsetup luksOpen /dev/sdd sdd-crypt


    Maybe a key problem, adding a new key trough GUI create this issues similar to ml1950. My pass is made of 45 random char using all sorts special ones.


    Code
    Unable to add the key to the encrypted device: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; /bin/bash -c 'echo -n '>[' | cryptsetup luksAddKey -q '/dev/sdd' <(echo -n 'haha')' 2>&1' with exit code '2':
    
    
    
    
    Error #0: exception 'OMV\Exception' with message 'Unable to add the key to the encrypted device: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; /bin/bash -c 'echo -n '>[' | cryptsetup luksAddKey -q '/dev/sdd' <(echo -n 'haha')' 2>&1' with exit code '2': ' in /usr/share/openmediavault/engined/rpc/luks.inc:530 Stack trace: #0 [internal function]: OMVRpcServiceLuksMgmt->addContainerKey(Array, Array) #1 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array) #2 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('addContainerKey', Array, Array) #3 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('LuksMgmt', 'addContainerKey', Array, Array, 1) #4 {main}


    So my question is:



    What is my password? apparently it was never registered as I saved it (or maybe I got the wrong command), how can I unlock those drives through cli and add now key cli or gui ?



    Thanks in advance

  • @eenca


    Your sudo user does not get the correct path set.
    Edit the sudoers file to set a path or work as root.


    If you do not know your password you are FUBAR.


    The correct command is (man cryptsetup):
    cryptsetup luksOpen <device> <name>


    to add a key (you need THE PASSWORD)
    cryptsetup luksAddKey <device> [<key file with new key>]

  • Thanks for your answer.


    I can unlock on the GUI and I have the password saved in my password manager.


    I forgot to add the output: when I try to unlock with both command I have:


    > No key available with this passphrase.


    What does it have to do with my sudoer file?

  • I can unlock on the GUI and I have the password saved in my password manager.


    What does it have to do with my sudoer file?

    It has nothing to do with your sudoers file - my fault (I read PATH... and "command not found").


    Try it on the console.
    A wild guess: Your password contains characters that are not parsed properly, e.g. *

  • It does contain multiple "special character", my question is how do I fix that?


    I cannot have data only accessible trough a GUI with some magical black box that parse my password and my data volume is too big for me to just format the disks.


    Thanks

  • HI, this thread seems kind of alive still, so maybe someone can help me here.


    I'm unlocking my encrypted drive manually in the OMV(4) webgui, but on bootup all the mounts based on that drive already failed and are not re-triggered after manual unlock.


    That is: the drive itself is mounted, but not all the dependent mounts like shared folders etc.


    Is this supposed to work? Is either the plugin checking the mount unit hierarchy and re-triggers all dependent mounts or is systemd itself supposed to re-try when a previously unavailable dependency comes online? If both is not: How would I fix this? Is there some place where I could add custom scripts to be executed on manual unlock?


    Thanks in advance!

    • Offizieller Beitrag

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Just to doublecheck:


    Is the following order correct?
    1. Install LUKS Plugin
    2. Restart OMV
    3. Encrypt a HDD with a password/keyfile
    4. UNLOCK the HDD
    5. Format the unlocked HDD
    6. Mount the unlocked HDD


    right? Or does it have to be formatted while locked?

  • Thank you for this plugin, it is working perfectly.



    I may suggest a micro improvement?
    Remark in the plugin description that a reboot is required.


    This is not necessary for all plugins and everyone has a knowledge of a part of the system.
    If you forget to reboot, you get a
    "Check that kernel supports aes-xts-plain64 cipher" error.
    Than you try to load modprobe dm-mod but
    'modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.14.94-mvebu/modules.dep.bin'...

    ... and so then begins the pilgrimage on the Internet ;)


    Thank you,
    RIccardo

    • Offizieller Beitrag

    Remark in the plugin description that a reboot is required.

    Required for what? It might be required on an arm board but most systems shouldn't need to reboot.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    now that I'm on arm I'd have liked to have found this indication.

    I still don't know why you need to reboot? What is the reboot "fixing"? dm-mod isn't required for luks.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    I also had to reboot that the plugin does work (HC2)

    What wasn't working that made you reboot? I didn't have to reboot on my RPi test system.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Right after the plugin install it was impossible to use it, I got failure in the interface( Check that kernel supports aes-xts-plain64 cipher ) and in the command line.


    Looking around, someone suggested some module was missing (and I tried) but it was not this.
    After a ...while, I realized I could try to reboot (I know that does not sound good "just reboot and see, maybe it works"): in this case that "fixed" the issue and I was able to unlock the disks.


    You say that dm-mod is not required and I don't know what was wrong,
    Riccardo

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!