Hi. I am running Duplicati 2.0.4.5_beta_2018-11-28 on Manjaro Linux. I can back up fine to AWS S3 storage but if I try to move my S3 key to a variable so it doesn’t show up in the process list it cannot connect to S3.
I get this error:
Fatal error => The request signature we calculated does not match the signature you provided. Check your key and signing method.
Amazon.S3.AmazonS3Exception: The request signature we calculated does not match the signature you provided. Check your key and signing method. —> Amazon.Runtime.Internal.HttpErrorResponseException: The remote server returned an error: (403) Forbidden. —> System.Net.WebException: The remote server returned an error: (403) Forbidden.
…
…
I don’t know S3 specifics, so let’s try some generic step-by-step debugging to see where this issue arose.
Does printenv AUTH_USERNAME AUTH_PASSWORD give correct answer, or do special characters change?
Does it work with a typed --auth-username and --auth-password password (instead of getting from URL)?
Does it still work if environment variables are substituted for those options instead of typing them by hand?
Note that this is just testing, and not enough to hide your credentials. But beware of the e option for ps too, because environment variables can also be seen. There do seem to be some controls on who can obtain.
A permissions-protected –parameters-file might be another option, if environment variables aren’t working.
What sort of error does S3 hand you if you just do something like a bad password intentionally? That error message sounds a little more exotic than just a wrong password, but it’s too S3-deep for me to interpret… Web research can certainly find people talking about it. Meanwhile, it’d still be good to know where it stops working in between your “works” and “does not work” cases. Maybe that will reduce the scope of search…
If you want to use Dupliacti.CommandLine.exe, then I like the suggestion to use --parameters-file.
Alternatively, you could define the job in the Web UI and schedule it from there. The jobs will run without details being exposed in the process list. Note that you need to protect the Duplicati-server.sqlite file (as you would the parameters-file approach) as it contains the credentials.
If you don’t want an automatic schedule, you can use something like duplicati-client to manually kick off jobs defined in the Web UI.
Thanks for the responses. It seems that Duplicati is setting some value for the key since if I don’t provide the --auth-password="…" parameter, it complains that no secret AWS key was given. I wonder if it’s being garbled or not really passed on to Amazon. The only potentially special character in my key is the percent sign “%” but bash doesn’t seem to care about it. I took variables out of the equation by removing the “&auth-password=…” from the URL and added the --auth-password="…" to the command arguments with the same result. If I change the password to be incorrect, I get the same error about key and signing method. I like the param file idea but I don’t think it will solve the error since I will be putting the --auth-password="…" in there instead of the command. The result seems to be the same using a param file.
I tried to compile Duplicati to have it print out the key it is using but I can’t get it to compile on my Linux system. Might be a prerequisites issue. Not sure what they are. Said something about NGettext and ICatalog could not be found.
Percent is special in some contexts, for example in a URL it’s followed by two hexadecimal digits giving the character value. How does one find out what password S3 actually wants? Certain characters get encoded.
So if I go into the GUI to make a dummy job with key percent%character then save that and go to Commandline, the box with Target URL has turned it into auth-password=percent%25character
So the question is whether the percent you see is meant as a percent or as the start of an encoded sequence. If meant as percent, then the question is whether it needs to be encoded even if not in a situation where a URL is expected. If it works after encoding (or copy-and-paste from a Target URL), there’s the solution to making it work, although my inclination would be to consider it a workaround…
Thanks for the help. I’m going to give up for now. I tried every way I could think of to put my secret key into an argument rather than in the URL. I even tried replacing the “%2B” in my key with “+” but all gives the same error. I’m going to use the Web GUI I think. I might revisit later. Take care.