How to create new "crypt" remote from command line

hi all,
I'd like to add a new "crypt" remote based on another one of my remotes.
I can easily do that through the interactive rclone config command.

I'd like to automate this, instead, and do it with a single command line with arguments.
how should I do that?

I've seen an example for Google Drive here:
https://rclone.org/commands/rclone_config_create/
but I'm not sure how the keys are named in the case of the "crypt" remote.

any help is appreciated. thank you!

thanks, @asdffdsa! I'll try it out.
does that mean that, as a rule of thumb, apart from the type, all the other parameters are named exactly as in the config file?

final question: is there a way to let rclone pick a password and a salt, printing both out for safekeeping?

fair enough. thank you for your help!

for future reference: filename_encryption has to be either standard, obfuscate, or off, not true.

upon usage of that newly created remote rclone was complaining about that true, so I don't think it should be used.

anyway, I've also seen that the command in the second post stores the passwords in cleartext.
instead, the rclone obscure command should be used.

thus:

rclone config create \
   $CRYPT crypt \
   remote $REMOTE \
   password  $(rclone obscure $PASS) \
   password2 $(rclone obscure $SALT) \
   directory_name_encryption true \
   filename_encryption standard

perhaps rclone should check the flags better as i have shown rclone will create the crypt with filename_encryption true
and it will encrypt my passwords without the need for obscure

@calisro ?

okay, I've tried again, running the latest beta (like earlier).
if I execute your example, rclone does obscure the passwords.
if I execute a real life scenario with a long password, rclone does not obscure it.

I guess somewhere there is some logic that says "if I get a value which is long enough, I'll assume it's already obscured", and that's why my passwords were clearly visible in the config file!
you can try again yourself with password my_very_long_and_stupid_password... it does not get obscured for me!

to be precise, as I was saying, it creates the remote without issues, but it was complaining about that at the first use:

Failed to create file system for "thecrypt:": Unknown file name encryption mode "true"

agreed. :slight_smile:

I've always been using the beta, v1.51.0-360-g518d3981-beta on Linux.

my point is that rclone does different things based on the length of the password value (and password2).
have you tried re-running your command but specifying my_very_long_and_stupid_password as password? does it still obscure it, in your case?

it is...

... I didn't even know I could set a config password! I'll investigate.

but still, different behavior based on value length is really counter-intuitive.

rclone config
Enter configuration password:
password:

e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config

Your configuration is encrypted.
c) Change Password
u) Unencrypt configuration
q) Quit to main menu

1 Like

@asdffdsa ... still: :smiley:

right, so you confirm the behavior that I was highlighting, then...

I don't know who to tag but this feels like a bug.

It's already adjusted in the latest beta and should be in the 1.52 release..

Just as a FYI the options for crypt (or any backend) are documented on their pages

https://rclone.org/crypt/#standard-options

Those show exactly what goes in the config file. You can also get that help on the command line with rclone help backend crypt.

does this mean that I already had the --obscure and --no-obscure flags in my version, v1.51.0-360-g518d3981-beta?
still, isn't it a bug that rclone picks either flag based on the length of the password value?
or am I mistaken?

thanks, Nick! I did look at the docs before opening the issue, of course, but it was not entirely clear to me. is this command:

rclone config create \
   thecrypt crypt \
   remote remote:crypt \
   password password \
   password2 password2 \
   directory_name_encryption true \
   filename_encryption standard

equivalent to this one?

rclone config create \
    thecrypt crypt \
   --crypt-remote remote:crypt \
   --crypt-filename-encryption standard \
   --crypt-directory-name-encryption true \
   --crypt-password password \
   --crypt-password2 password2

also, I'm guessing that I have to start with rclone config create thecrypt crypt and then I have to append the arguments, but it's not really clear to me. :confused:
after all, the "crypt" page talks mostly about the crypt remote, and I wouldn't know how to interpret the "standard options" that I see mentioned about the "crypt command" when I'm applying those to the "create" command.
I hope you at least understand some of my confusion. :sweat_smile:

thanks!

I'm not sure exactly what that beta is, but if you check for the flag, that is your best bet.

It automatically tries to understand what you want. If you don't want that, you'd pick either option and go that route to force a direction based on your needs.

if I'm not interpreting the beta labels wrong, the github issue got fix and pushed to v1.51.0-330-g98c34e41-beta, and since I was using v1.51.0-360-g518d3981-beta the answer was yes, I had that flag.
I guess the most up-to-date answer, which works in the current beta and will work starting with v1.52, is something like:

rclone config create \
   $CRYPT crypt \
   remote $REMOTE \
   --obscure \
   password  $PASS \
   password2 $SALT \
   directory_name_encryption true \
   filename_encryption standard

I know, but I believe that THAT's the cause of the confusion.
explicit is better than implicit -- pick a behavior and people will adapt by using flags to accomplish their goals.
otherwise, there will be someone (like me! lol) trying a command with password shortpwd and seeing that it gets obscured, only to try the real-life case of a long password and getting burnt by this behavior.

It got that way because someone asked for it and it came to be. Try to remember, your use case may not be best for everyone.

It changed and is documented in the new version to make it more apparent so I think we are beating a dead horse as they say.