I’ve struggled with this one for a while now, so it’s time to ask…
What is a good, safe way of passing the repository password to a scheduled task running on a Synology NAS?
My initial thought was to set the “RESTIC_PASSWORD” environment variable for each user that restic runs for, however the environment is not persistent between sessions, so when a scheduled task runs for a user, it starts with the standard environment.
The disks are not encrypted, so I don’t want to save a plain text file with the password in it, the same goes for the scheduled task, I don’t want to save the password in the command to be run because chances are that piece of information is not encrypted when it is saved to disk.
Maybe I’m looking at this in the wrong way completely, so any suggestions are more than welcome.
PS. The reason the disks aren’t encrypted is because it reduces the max read/write speed too much.
If your concern is that a regular user can retrieve the password, you can use RESTIC_PASSWORD_FILE and put the file in, maybe
/etc or somewhere where a regular user can’t access it. I think this is a better approach because even exporting RESTIC_PASSWORD in every session, you can always retrieve the password by just typing
echo $RESTIC_PASSWORD, so even when the HDD is not encrypted, a password file located in a “secure” location will be harder to locate than exporting the password in a variable. You can also put this password file in an USB if you want to keep it away from the machine.
Personally, I create a script for each persistent repository in
/usr/local/bin/restic-$REPONAME which is chmod 700 and owned by root. This script is basically:
exec restic "$@"
This allows me, as root, to have a bunch of shortcuts to invoke restic for a particular repository without having to remember/type the password or location.
Isn’t better to create a new user to perform
root tasks as specified in the documentation? I know it is just easier to just the root account but in terms of security, everyone knows and expect to find a “root” user but maybe less people expect you to have another user for this “root” task. At the end, I know if “root” is compromised your’re hugged anyways, but I find that having a restic binary with the right permissions, in some kind of level is like isolating the backup process, which can be very convenient (I don’t know if “isolated” is the right term here) and you can have that user to hold the credentials like in your script. I did this using this script and I find it very convenient, at least for me. I just set a couple of cron jobs for the user, the script and restic binary are in
~/bin and the configuration files (which holds the credentials) are created by the script with
chmod 700 permissions so only this specific user can run restic, the script and can read/write the configuration files. I did this thinking that maybe is a little bit safer than having
root to deal with this and because I don’t really like to use
root except for when I really have to.
Sure, and you could absolutely do that as part of the same script.
In reply to everyone who’s responded so far:
I’m not concerned about local users having access to the files. I’m concerned about the password being stored on the disk in an un-encrypted state at any point (if for example the device gets stolen). I realised earlier that when I do
export RESTIC_PASSWORD=mypasswordhere it is saved in the bash history, so that’s something to consider at some point too.
The only thing I’ve been able to think of is to have a USB cable plugged in with a USB stick on the other end, and then feed that through a wall or somewhere so that if the worst happens the cable would just be unplugged and left behind…
But there must be an easier way surely?
EDIT: And after writing all this I realised that maybe I should create a small, encrypted file with its own filesystem, which I mount manually on boot. Then I can use the
RESTIC_PASSWORD_FILE variable to point to the file on that encrypted mini “partition”.
Why would you care if they have access to your backups, when they have access to the current, up-to-date filesystem? They can get all of your data from that anyway.
The solution is full-disk encryption, not encrypting your backup password.
I should have probably clarified that no data stored on the NAS in an un-encrypted state is sensitive. Restic runs on the clients (which all use full disk encryption) and uses the NAS for the repository.
I want to run Restic on the NAS so I can run
prune there instead of from the clients.
Also, by clients I mean a couple of laptops. It’s only a home setup.
Then a password file stored in an USB or encrypted-partition/volume should be alright. You should also consider to sync the repository to an external HDD from time to time or a cloud storage (for cloud storage you could use
rclone to do the sync) so if your NAS get stolen or even when it is just that it died, you could continue to use the restic repository stored in your external HDD or start a new NAS with the same repository without having to start a new repository and lose all previous snapshots.
Ah, I see.
How you approach this depends on whether you want to have to decrypt the password each time forget/prune runs (at which point you might as well just add another key, and use that password manually). If you want to decrypt the password once on boot then you have several options:
- A small LUKS volume that you unlock at boot, then mount, which contains the password in a file.
- Memorize a password to one of the repo’s keys, and store it in a tmpfs on every boot (e.g.
/tmp on some distros is a tmpfs, or make your own tmpfs).
The second approach is probably the simplest and easiest to maintain, and doesn’t add extra layers for no reason. E.g. restic already has symmetrically-encrypted master keys; LUKS-encrypting a symmetric key (repo password) that encrypts the master key is a second layer of encryption for no benefit.
Using a tmpfs gives the system access to a repo key password until reboot and is exactly as secure as the other options, provided swap is encrypted otherwise the password can leak to swap. (Consider using ramfs instead.)
I have restic as its own user with its own $HOME. The restic binary resides in this $HOME. This is mentioned in the docs somewhere and it works well. You do need to change the acl for the binary. Then, I put the password file in this $HOME and
chmod it so that only the user, i.e. restic, can read it. The backups themselves are remote on B2. Good enough for my laptop and casual perusers.
I’ve played around with several options for a few days and eventually I ended up using Synology DSM’s built-in encrypted folder function to create a location for the
--password-file. The folder has to be manually decrypted on boot, but that should be a relatively rare occasion. This has solved the problem for now and is a fairly user friendly solution.
Not necessarily related to the topic, but related to running Restic on a Synology Diskstation, I had to specify
$TMPDIR since the default
/tmp/ is too small.
Hello all, I was desparately searching the net for instructions on how to install restic on a Synology NAS in the first place but didn’t find any. You appear to be using it, so how did you get it running?
You may have worked it out, but for anyone else trying to run restic on a Synology NAS:
- Find your CPU architecture; start here https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Compatibility_Peripherals/What_kind_of_CPU_does_my_NAS_have
And then google which architecture your CPU uses (i386, AMD64, ARM, ARM64)
- Download the appropriate linux binary from https://github.com/restic/restic/releases/latest
- Unpack it in /usr/local/bin/ and symlink the binary to /usr/local/bin/restic
tar -xavf restic_0.9.5_linux_arm.bz2) (
ln -s /usr/local/bin/restic /usr/local/bin/restic_0.9.5_linux_arm)
- You may have to set the correct permissions with
- Before you run restic, you may have to specify the environment variable
$TMPDIR since the default
/tmp/ is too small (on my device).
- Now you can run restic by simply typing
restic. Or via a scheduled task.
Cool, I set it up now. If you need rclone as a backend, that’s a single Go binary as well.
I see this is a bit of an old thread, but I thought I’d add a couple of thoughts:
One commenter mentioned that the password might be visible by typing 'echo $RESTIC_PASSWORD. Of course the defense against this is to unset the variable after you’ve finished ‘export RESTIC_PASSWORD=""’
Another commenter mentioned that typing this at the command prompt leaves it in the history. I recently discovered that in most versions of bash, if you precede the command with a space, then its not stored in the history. (see HISTCONTROL = ignorespace). An alternative is to use “set +o history” and then -o to turn it back on again.
If you want a “private shell” that won’t leave a history trace, you can also just
unset HISTFILE. This allows you to maintain history within the shell, but when the shell terminates it won’t update the history file on disk. Kind of like an “incognito mode” for your shell.