Rcd With Encrypted Config File

I'd like to setup rclone an instance in some hosting provider such as DigitalOcean or Linode. My idea is to have an rclone REST API for my remotes.

I'd hate hate to store the config file unencrypted since I do not control that computer, so I'm wondering if rcd supports encrypted config files? The problem is that even if it supports it, I wouldn't want to run the command the rcd command giving it the decryption password as it would be pointless, since rcd would basically run forever.

Is there maybe a way to pass in the config file's password when interacting with rcd on each request? Like send it as part of the body (POST) payload?

There does exist a syntaxt for defining remotes as part of a command, if that is what you are looking for:
https://rclone.org/docs/#backend-path-to-dir

Hopefully that is something you can use?

Ultimately it is very difficult to do anything truly secure on hardware you don't control, but in all likelihood you just have to make it "not trivial" for your usecase.

Sorry, I just realized that I rambled a lot and my question didn't make much sense.

What I want to do is to decrypt the config file when I run a command. That way I don't have to run rcd with the password parameter or always having the password in memory in a host I do not have full control over.

For example if I do POST http://127.0.0.1:5572/config/listremotes to view my remotes, i'd like to pass the config's file password in that request.

I don't have a lot of experience with the RC personally, but I would think you could use what is described in the first link with this:
https://rclone.org/rc/#accessing-the-remote-control-via-http
To send a command along with the secure keys so nothing sensitive is actually stored permanently on the remote server.

If that isn't helpful then you probably need some input from someone who has more experience with the RC or a similar setup because this is very different from anything I use myself. Good luck :slight_smile:

I see what you are getting at.

The problem at the moment is that rclone won't start at all if it finds an encrypted config file. So what you are asking is delaying the decryption...

Assuming that is possible somehow, then passing the password for each request would be OK, but overkill, rclone only needs the password once to unlock the password file. So that could be a separate API call.

Perhaps the user interface should be a remote control command (say config/file) to change the config file where you could supply a password. You'd then start rclone rcd with an empty config file and then change to it when you wanted to do real stuff. You could then change back to the empty one when you had finished and this could wipe the password from memory. This would also need to clear the fs cache so as not to leave any old credentials in memory.

rclone will keep the password in memory as it needs to write to the config file when the tokens change. However as noted above you could change the config file and wipe the password when done.

Sounds like an acceptable solution (assuming I'm understanding this right).

So basically I'd run rcd with an empty config file, and then change it with something like POST config/file with the config file itself included when I wanted to use it. When I'm done, I'd just send over another empty file?

This would be interesting specially since my real config file wouldn't have to be stored at the host at all, since i'd send it over when I needed it.

I was thinking a path to a local file rather than the contents of the config file.

So start using empty config, switch to using encrypted config file then switch back when done.

Remember rclone needs to write back to the config file so a local encrypted file would probably work better.

If you think that is worth implementing then please make a new issue on github :smiley:

Thanks, yeah that still sounds reasonable. I will open an issue on it and hopefully people are interested on it.

1 Like

Sorry for the delay. The issue is here.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.