Safe method of passing repo password to scheduled task on Synology NAS

Getting Help
2

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.

3

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:

#!/bin/sh

export RESTIC_REPOSITORY=/path/to/repo
export RESTIC_PASSWORD=repo-password

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.

1 Like
4

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.

5

Sure, and you could absolutely do that as part of the same script.

1 Like
6

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”.

1 Like
7

Why?

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.

3 Likes
8

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 forget and prune there instead of from the clients.

Also, by clients I mean a couple of laptops. It’s only a home setup.

9

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.

10

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:

  1. A small LUKS volume that you unlock at boot, then mount, which contains the password in a file.
  2. Memorize a password to one of the repo’s keys, and store it in a tmpfs on every boot (e.g. /dev/shm, or /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.)

1 Like
11

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.

12

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.

1 Like
13

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?

14

You may have worked it out, but for anyone else trying to run restic on a Synology NAS:

  1. 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)
  2. Download the appropriate linux binary from https://github.com/restic/restic/releases/latest
  3. 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)
  4. You may have to set the correct permissions with chmod
  5. Before you run restic, you may have to specify the environment variable $TMPDIR since the default /tmp/ is too small (on my device).
  6. Now you can run restic by simply typing restic. Or via a scheduled task.
2 Likes
15

Cool, I set it up now. If you need rclone as a backend, that’s a single Go binary as well. :slightly_smiling_face:

16

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.

1 Like
17

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.

1 Like
18

I took the idea of @cdhowie a little further and after I made the script I used shc GitHub - neurobin/shc: Shell script compiler ; it’s available on ubuntu but you need to use version 4.x to work properly, the repo should be here:

sudo add-apt-repository ppa:neurobin/ppa

this will generate binary finales that won’t reveal the password, also you can use for example chmod 701 so they are not readable by the users

1 Like
19

Hello @cdhowie, I’m new to Restic and read your comment using a shell script, chmod 700 and placed in /usr/local/bin/restic-$REPONAME. Pretty sure my question will reveal that I know just enough to be dangerous…not clueless but plenty to understand.

I’ve been able to provide a password to Restic by exporting an environmental variable through ~/.bashrc but this just feels like the password is a bit exposed.

Got the --password-file feature to work and that seems like a step in the right direction security wise but typing all that at the command line doesn’t seem efficient.

Can you expand on how you call or activate the script, or how the variables from the script get from the file to the command line / Restic.

  1. Are you typing $script.sh on the command line or somehow activating the script when running a command? For example, when viewing snapshots, restic -r script.sh snapshots?
  2. Are the variables in the script somehow passed to Restic based on the REPO-NAME?
  3. By making root owner, do you need to preface every Restic command with sudo?
  4. Since root is owner, will this approach require a password when using Crontab for automation?

Thank you for any help and the information in your comment.

1 Like
20

Even though this comment is a few years old, I’d like to add that there are at least 2 ways to prevent passwords being added to the bash history:

  1. Enter it with leading spaces like (_=space because this forum would hide the space otherwise) __export RESTIC_PASSWORD='mypassword' as @plutocrat already explained
  2. Another (additional) option is to add a HISTIGNORE entry to your bashrc: HISTIGNORE='*PASSWORD*'. This will exclude all commands containing PASSWORD from being recorded in the history.
2 Likes
21

Thanks for the heads up @noeck I appreciate it.

1 Like