I use restic to backup to local and remote targets, some of them are encrypted, some are not (BTW thank you very much for --insecure-no-password).
I use a plain systems service file and in order to backup to S3 I set env variables. This however clashes with --insecure-no-password. My question:
is it possible to pass the S3 keys and the password on the command line?
or use some kind of --secure-yes-password to say that this instance of Restic will use the env variables?
As a workaround I will move to either a script file where I will set and unset env variables, or separate systemd service files so this is not a blocking point, I was rather curious to know if such situation was considered.
Hi @Wpq!
I think you mix two different things: The password used for encrypt the data (more precise: which is used to derive a AES key which then is used to encrypt the data) and credentials to access the backend storage.
--insecure-no-password does just allow to use an empty password (an empty string) which is else caught by restic as an error. Besides this is does exactly the same as every other password. Using a known word like password or test would give you the same effect except that you must know that word… So, this in fact does encrypt your password, but the AES key can be derived by everyone using the empty password.
Sorry for not having been clear. I understand what encryption does and does not (and I am very very grateful for --insecure-no-password, “not encrypted” was a shortcut in my head for “empty password”).
What I meant is that once I set the environment variables for the password (I just mentioned S3 because I was planning to add an example with several env variables and forgot - they do not matter to my question, sorry for that), sessions with --insecure-no-password were rejected because having both a password defined in the environment and this switch are contradictory to Restic:
~/restic [1]> echo $RESTIC_PASSWORD
acomplicatedpassword
~/restic> ./restic --verbose ls latest --insecure-no-password
Fatal: --insecure-no-password must not be specified together with providing a password via a cli option or environment variable
I fixed that point for me via a script that jails env variables so this was more of curiosity whether it is possible to to pass the password on the command line, to avoid too much gymnastics. --password-file is a possibility, I do not think that providing the plain password in the CLI is possible.
But as I said this is not an issue or anything, I was just surprised by the interlock between the env variables and the CLI switches.
The arguments of the restic team why they neither support a direct --password option nor empty passwords are basically that they want to help users not using insecure password settings - which is reasonable.
However, I must also say that I am personally not convinced by those arguments - from a security point of view using a very simple and/or short password like pass, test etc. gives similar (non-existing) security compared to an empty password. And the threat of adversaries seeing a given password via a CLI option IMO only applies to very specific environments where admins are typically aware of the problem - and mitigations using env variables or other password sources are available. But those are just my 2ct - everybody is free to use the software which matches the own philosophy best.
Yes, I know that there was considerable discussion about having effectively nonencrypted backups or not (with all the nuances: empty password, simple password, no password, etc.). I specifically did not want to address this in my question which was strictly technical: about the possibility to mix, in one script, “secure” and “insecure” backups (because of the collision between an env variable and CLI switches).