UnRAID encryption auto-start
You want to start your encrypted UnRAID array automatically after a reboot. Normally you’d follow the procedure outlined in this thread, but what if you didn’t want to run another SMB share? What if you didn’t want a server that constantly serves the password file, unprotected?
Well, here’s another solution you can opt for.
Procedure
- On another computer on the same network as the UnRAID server, create and run the following Python script:
main.py
:
#!/usr/bin/env python3
from os.path import exists
import http.server
# Define settings here
PORT = 9999
PASSWORD_FILE_NAME = "password.txt" # in current directory
TIMEOUT = 300 # in seconds
# Read or get password
if exists(PASSWORD_FILE_NAME):
print(f"Password file {PASSWORD_FILE_NAME} exists, reading password from it")
with open(PASSWORD_FILE_NAME) as password_file:
PASSWORD_TO_SEND = password_file.readline().strip()
else:
from getpass import getpass
print("Password file does not exist. Please enter one now.")
PASSWORD_TO_SEND = getpass()
# Set up webserver
class RequestHandler(http.server.BaseHTTPRequestHandler):
def do_GET(s):
s.send_response(200)
s.send_header("Content-Type", "text/plain")
s.end_headers()
s.wfile.write(str.encode(PASSWORD_TO_SEND))
httpd = http.server.HTTPServer(('', PORT), RequestHandler)
httpd.timeout = TIMEOUT
httpd.handle_request()
Some notes:
- Create a
password.txt
file in the same directory as the script and save the encryption password there. - Set the timeout longer than the time it takes your UnRAID server to reboot.
- If you want to manually enter the password and not have it saved as a text file on your other computer, just delete the
password.txt
and the script will prompt you to enter a password when it runs.
- Modify the UnRAID flash so that it fetches the key from your other computer.
(Special thanks to @bonienl on the UnRAID forums for the original script. I’ve tweaked it slightly for it to work with this alternate solution.)
If you have the USB stick mounted on another computer, you can omit the /boot/
part from the file path.
Edit /boot/config/go
and add/modify the following lines:
# ...snip...
# Copy scripts to emhttp event directories
install -D /boot/custom/keyscript/fetch_key /usr/local/emhttp/webGui/event/starting/fetch_key
install -D /boot/custom/keyscript/delete_key /usr/local/emhttp/webGui/event/started/delete_key
# Set execute permission
chmod a+x /usr/local/emhttpd/webGui/event/starting/fetch_key
chmod a+x /usr/local/emhttpd/webGui/event/started/delete_key
# Start webGUI
/usr/local/sbin/emhttp &
Create /boot/custom/keyscript/fetch_key
:
#!/bin/bash
if [[ ! -e /root/keyfile ]]; then
curl other-computer:9999 > /root/keyfile # Make sure to substitute port here if you changed it!
fi
Create /boot/custom/keyscript/delete_key
:
#!/bin/bash
rm -f /root/keyfile
- Now, when you need to reboot your UnRAID machine, remote into your other computer, execute the Python script, and reboot. Upon reboot, the UnRAID server will get the encryption password from your other computer and unlock and mount the array automatically.
Here’s a script that does the above automatically for you:
#!/bin/bash
# Start encryption password server script
python3 main.py &
# SSH into server and issue reboot command
# Make sure to change hostname to correct value
ssh root@unraid-server-hostname reboot
Troubleshooting
Bonjour issues
If you get an error about either the UnRAID server or the other computer not being able to find the host, your network may not support hostname-based discovery. To mitigate this, give your machines (both your UnRAID server and your other computer) a static IP, and use static IPs in the scripts instead.
Benefits
Here are some of the benefits with this approach compared to other solutions:
- The password is only exposed to the local network for a brief period, instead of a server constantly running that exposes the password. Once the timeout is reached, the script that emulates a simple HTTP server terminates.
- If someone gains unauthorized access to your UnRAID server and can inspect the contents of the flash drive, they will be able to tell that the server fetches the password from the other computer in order to start up, but they will not be able to know what the password is (unless, of course, the server is already running, then in which case they can simply inspect the memory).
- If someone gains unauthorized access to your other computer, they will be able to tell that there is a script that serves the password to the UnRAID server, but they will not be able to know what the password is, unless you’ve opted to save the password as a text file. In that case, you can simply lock the computer remotely and they will not be able to access the password.
Downsides
You may want to review a couple of flaws with this approach:
- The communication between your other computer on the network and the UnRAID server is unencrypted. Normally this shouldn’t be an issue on your home network with trusted devices only, but if there is an eavesdropper on your network then they can intercept your encryption password. Consider reviewing your network security before implementing this.
- This requires another computer to be on and accessible on the same network as the UnRAID machine. If your UnRAID server has, for example, your DHCP server, then this approach will not work as the UnRAID server won’t be able to reach your other computer until it has the array started. To mitigate this, ensure that your UnRAID server is not responsible for any part of your network stack.
- The password file sits on your other computer unprotected. You can mitigate the potential risk by typing in the password every time instead of keeping it saved.
Conclusion
As I was writing down this blog post I realized that if you already have access to another computer on the same network as the UnRAID server, you could simply access the WebUI and type in the password after the UnRAID server starts up. So this approach is stupid, right?
Well, this approach will also work for computers where you don’t have graphical access to (such as a headless machine without VNC/RDP access). You will still be able to reboot the server by running this script before rebooting.
As this approach is a bit risky in terms of security, you should carefully evaluate your network security and your threat model before you deploy it.