Howto: Store keyfile on remote device / RTRR between encrypted NASes

Backup, Restore, Netbak Replicator, Cloud Storage Services
Post Reply
New here
Posts: 8
Joined: Sun Feb 14, 2016 5:53 am

Howto: Store keyfile on remote device / RTRR between encrypted NASes

Post by marky0736 » Wed Mar 30, 2016 6:36 am


after spending hours on getting this to work, I decided to put together a quick tutorial on how you can mount encrypted volumes with a keyfile that is not stored on the NAS itself. Most of the information that is needed to do this is spread across this forum, the German forum and some other sites.

First, let me outline my current configuration and what it does:

- NAS Main Server, encrypted file system, has to be manually entered after boot. Never powered down, used as main server on the network.
- Backup NAS, encrypted file system, auto-mounted after boot. Usually powered off, wakes up once a week to do an rtrr-backup of the main server.

The main point is that the keyfile to mount the Backup NAS is not stored on the Backup NAS itself, but on the Main Server, so if the main server is powered down, the Backup NAS' encrypted volumes won't be mounted automatically (of course you can do so manually as through Web-GUI). I still wonder why QNAP won't allow users to utilize keyfiles on a remote share or USB device, but anyhow, here's how to do it.

The following steps are a brief summary on what you have to and require some proficieny.

1.) Create Keyfile

The first thing you do is create a keyfile. SSH into the NAS you want to mount automatically and create it:

Code: Select all

storage_util --encrypt_pwd pwd=YOUR_PASSWORD > /tmp/keyfile.key

The result will be an encoded keyfile which will later be used to automount the volumes. Please note that this is not identical to the keyfile you can download with the storage manager's download-function!!! This contains your encrypted password and is way shorter than the QNAP-file.

Make sure your keyfile does not have linefeed at the end of the first line. Load it into vi or use Windows notepad to double-check.

2.) Copy Keyfile to secure Location and create Backup User

The next thing you want to do is copy the keyfile you just produced to its final destination. The safest place in my opinion is the Main NAS, which can only be decrypted by manually entering the password after boot.

So what you want to do is create a share, e.g. "BackupMount" on your Main NAS and copy the keyfile into this share.

Next you want to create a user that will later access the keyfile on your Main NAS to mount the encrypted volumes on your Backup Nas. In this example, we'll create a user called "BackupNAS". Make sure the password for this user is absolutely unique. This password should not be identical to any password used to decrypt volumes or gain access rights to your NAS because this will later be available in plain text to possible intruders!!! In this example, this password is USERPASS.

Limit access for this user to the share which holds the keyfile. This should be the only share with access rights (Read-Only is enough). Do not grant access to this share to any other users on the NAS.

3.) Write automount-script

The next thing to do is create an automount-script that will later be called on system startup on the Backup-NAS.

In this example it would look like this:

Code: Select all

mkdir /keylocation
mount.cifs // /keylocation -o username=BackupNAS,workgroup=WORKGROUP,password=USERPASS
cryptsetup -v luksOpen /dev/mapper/cachedev1 ce_cachedev1 --key-file=/keylocation/keyfile.key --key-slot 0
mkdir /share/CE_CACHEDEV1_DATA
mount -t ext4 /dev/mapper/ce_cachedev1 /share/CE_CACHEDEV1_DATA/

where is the IP-Adress of you Main NAS (the place you stored the keyfile on)
BackupMount is the share you created on this device and stored the keyfile in
BackupNAS is the username you created on this device and
USERPASS is the password for this user.
WORKGROUP of course is the workgroup name of your samba network
and keyfile.key is the keyfile your created in step 1.

In this example, we'll call the script

Again, make sure your script does have correct linefeeds. Either load it into vi or edit it on Windows, but make sure it's properly formatted afterwards. If you're unsure if it's okay, use dos2unix (download from sourceforge) to make sure it's properly formatted.

4.) Copy automount-script on persistent device

As we want to execute this script on startup later, it's important that you store it on a device that is not replaced by flash-memory after reboot. The best option is an USB-Stick, as you can quickly pull it out if you don't want your device to be automatically decrypted for whatever reason.

So put USB-Stick into your Backup-NAS and format it with ext4. Otherwise you might have problems making the script executable.

Copy the automount-script on the USB-Stick. Again: Make sure it's properly formatted for linux (see above).

ssh into your Backup-NAS and find the USB-Stick first (it's in /share/external/). Note the device name of the USB-Stick. You will need it later.

Make the script executable using

Code: Select all

chmod +x

You might now want to test the script. Please note:
- the script can't be executed from the current directory, so "" won't work. Use "./" to test it.
- the last step in the script might take a while (2-3 minutes) smoke a cigarette or have a cup of coffee in the meantime. Don't lose patience.

5.) Setting up auto-execution of the script

Now this is a little bit dirty, but it's what I found and it works although I don't really like its implementation.

Go to /etc/conf/

Edit the file "qpkg.conf"

Append the following section:

Code: Select all

Name = CryptMount
Version = 0.1
Author = marky
Date = 2016-01-01
Shell = /share/external/DEV3301_0/
Install_Path = /share/external/DEV3301_0
Enable = TRUE

DEV3301_1 ist the device name of your USB-Stick you noted above

As you can see, most of the information is unimportant, only Shell and Install_Path are relevant.

6.) Final check.

Now you can reboot your Backup-NAS and be patient. After some time you will be able to access all shares and even the storage manager will show the volume with an open lock.

Of course it's up to you what to do next, set up a time schedule for unattended backups with no need for interaction or just adjust the procedure to your needs.

That's it for now, I'm sure I forgot something, but it's quite a longish procedure to describe.

Feel free to comment, hope it might help some people save a little time.


P.S.: My native language is German, so I'd like to apologize for my mistakes :ashamed:

Post Reply

Return to “Backup & Restore”