I've been running Unraid for years, and I now have multiple disks (luks-encrypted) and dataset (zfs encrypted), and I would like achieve something which I am not sure I can:

 

1. Change the location from where cryptosetup loads it's key
2. Supply the encryption password for the array preferably using a script at boot (I have the script)

 

This enables me to use the following setup where the dataset loads their key from an encrypted drive, to which I can provide the key at boot time via a script.

 

Is this at all possible? 🙏🏼

 

//Thomas

 

PS: I primarily want this to avoid the key being stored unencrypted anywhere on my drives

Edited April 26, 20251 yr by Ulf Thomas Johansen
Add. info

I think this still stems from autostarting an encrypted array...

 

 

you can technical call the command and folder key form anywhere, but to unlock and maintain a unlock it has to be at original maintainer or required kernel level path...
 

from my understanding, that is the secure root home folder /root

 

on unriad the issues is more where is the file and what your using as a tmp location ...

Thank you for responding, but I am still questioning having to temporary store the keyfile somewhere on my disk.

 

Ideally it should be a configurable location, for which I could input a path to a zfs encrypted area for which I have to supply a password during boot (currrently doing this now, but I have to copy the keyfile from the secured disk to /root, and deleted it when I'm done).

 

Agreed, I might be paranoid but I like control over where this file is.

Edited May 1, 20251 yr by Ulf Thomas Johansen

if you reveiw the 2 forum post they have script to do just that...

It does indeed, and I have been using something similar but I've just downloaded the keyfile from protected dropbox url. But what I wanted to achieve was to have the actual keyfile locally, encrypted and when unlocked Unraid would read the keyfile from that location.

To try to achieve this I have created a wrapper script for the cryptsetup command which intercepts the luksOpen command, removes the --key-file parameter (as it points to /root), and reissues the command with the path for my keyfile. This all works when done manually, but fails during boot. I can only assume that there are some code somewhere, that stops this from working during boot, so for now I am copying the keyfile to the /root folder and all is good.

Stil not giving up though

 

Automation requires the password to be part of the script...
-Even if its a couple separate random files that cat together for the password...

Manual scripr run can and will prompt as that what the script is told to do...

I understand what your trying to do now, I'm not sure how To achieve that without a password of some kind in the script...
The safest secure way would be to have a yubi security key be the key password...

 

Plunging in and unpluging a device...

which are feature requests...

 

 

without have mutiple text files downlaoed to /tmp and read in a order to have the pasword. I'm not aware of a way to do this... like this needs a unassigned disk that has an encrypted storage space...

 

... I have to think more on this ...

good luck

I could see a udev rule be used with a device... that runs and pulls stuff form the usb...

https://superuser.com/questions/101042/udev-mount-encrypted-volume-upon-usb-stick-insertion

Thanks for chiming in. This is what I currently do:

 

Unraid connects to a remote server

I get a telegram with a link to this server 

I put in a key

Key is retrieved by the waiting script

Key is used to unlock a local zfs-key-drive

On this drive I can store other keys

When script is done it unmounts and unloads the keys for the zfs-key-drive

 

To achieve this I have created a wrapper script for cryptsetup, but I cannot seem to intercept the actual cryptsetup unlock which Unraid sends. My thinking was that as an advanced setting we should be able to configure the path to the keyfile, which in my case would be the zfs-key-drive.

Voila!

 

 

 

Cool, its sounds like you found a good solution...

For others who might come as that is a solid plan here some secondary notes and info especal for zfs encrpted disks...

AS, Yes, it's possible to configure Unraid to securely auto-decrypt both LUKS-encrypted disks and ZFS-encrypted datasets at boot, without storing unencrypted keys on the system. Here's a comprehensive approach based on community practices and available tools:

 

Automate the decryption of your Unraid array and ZFS datasets at boot, using a script that retrieves the encryption key from a secure, remote location. This ensures that the key isn't stored unencrypted on the Unraid system, enhancing security.

So how to implement?
Implementation Steps:

 

1. Secure Key Storage

Store your encryption key on a secure, remote server. Options include:

A private GitHub repository with restricted access

An SFTP/FTPS server within your local network

A Raspberry Pi or similar device acting as a key server

more info here: https://www.jackpearce.co.uk/posts/automatically-decrypting-mounting-unraid-array-at-boot/

 

*Ensure that the key can be revoked or moved if necessary, adding an extra layer of security in case of unauthorized access.

 

2. Create a Fetch Script

Develop a script on your Unraid server to retrieve the key at boot. For example, using curl to fetch from a GitHub repository:
Example:

fetch_key.sh sotred on flash drive /boot/config ...

#!/bin/bash
curl -H "Authorization: token YOUR_GITHUB_TOKEN" \
     https://raw.githubusercontent.com/yourusername/yourrepo/main/keyfile \
     -o /root/keyfile

*Replace YOUR_GITHUB_TOKEN, yourusername, and yourrepo with your actual GitHub token and repository details.

 

3. Integrate with Unraid Boot Process

Modify Unraid's /boot/config/go file to execute your fetch script during the boot process

example go file:

#!/bin/bash
# Fetch the encryption key
/boot/config/fetch_key.sh
# Start the Unraid web interface
/usr/local/sbin/emhttp &

--Ensure that fetch_key.sh is executable and located at /boot/config/fetch_key.sh.

 

For zfs:

4.Configure ZFS Datasets

For ZFS-encrypted datasets, set the key location to the fetched keyfile:

see github project: https://github.com/samssausages/ZFS_crypto_unlock

example:

zfs change-key -o keylocation=file:///root/keyfile poolname/datasetname

 

Then, load the key and mount the dataset:

zfs load-key poolname/datasetname
zfs mount poolname/datasetname

 

5. Automate with User Scripts Plugin

Utilize Unraid's "User Scripts" plugin to automate the key loading and dataset mounting:GitHub+1Unraid Forums+1

Install the "User Scripts" plugin from the Unraid Community Applications.

Create a new script with the following content:

#!/bin/bash
zfs load-key poolname/datasetname
zfs mount poolname/datasetname

 

Set the script to run at "Array Started" to ensure it executes after the array is online. via user script plugin / go file or udev rule ...

 

6. Secure Key Deletion

After the array and datasets are decrypted and mounted, delete the keyfile to prevent it from remaining on the system:

once array is unlocekd.. (as we will need the key file for shutdown as well...

rm -f /root/keyfile

You can add this command to the end of your fetch script or create a separate script scheduled to run after the array starts.

 

How is this a befit?

Enhanced Security: The encryption key isn't stored unencrypted on the Unraid system, reducing the risk of unauthorized access.

Automation: The decryption process is automated, eliminating the need for manual intervention at each boot.

Flexibility: Using remote key storage allows for easy key revocation or updates without direct access to the Unraid server.

 

some considerations...

Network Dependency: Ensure that the Unraid server has network access during boot to retrieve the key.

Key Management: Securely manage your remote key storage, including access controls and backups.

Testing: Thoroughly test the setup to confirm that the array and datasets decrypt and mount correctly at boot.

Great guide @bmartino1. I've opted to store my downloaded keyfile in a tmpfs area which is mounted at boot, and unmounted when the unlock process is completed. Adds additional security as the keyfile is never stored on disk as tmpfs is in RAM only.