#### What is the problem you are having with rclone?
Similar to the command
rclone obscure password, is there the ability to generate an encrypted output of the password as well as salt. The purpose is to validate if the existing passwords match.
#### What is your rclone version (output from
#### Which OS you are using and how many bits (eg Windows 7, 64 bit)
Microsoft Windows 10 Professional version 1909 Build 18636.1110
No, there isn't a command I'm aware of. You can validate by just typing in passwords and validating you can list the remote as the passwords would change so they'd never be the same.
Can you elaborate further on
just typing in passwords and
list the remote as the passwords would change so they'd never be the same?
The only password currently entered is the configuration password prior to running rclone.
Do you mean
rclone lsd remote:/path or
rclone lsf remote:/path?
I'm not sure what you are trying to validate as I thought you were trying to validate the encryption password/salt.
if that's the case, you'd just make a new config and rclone ls the encrypted remote. If you get results, it's working.
@Animosity022, the intent is to compare the hashes without needing to create a new configuration.
So you'd take two rclone.confs and you want to compare the password/salt of a remote in each?
It would be without having to compare the configuration files. It would simply be a command line output.
There's no extra command that takes the encrypt password and salt and compares them that I'm aware of.
@darthShadow - any other thoughts?
No, I can't remember anything that would help the user.
Thanks @Animosity022 and @darthShadow.
Would it be possible to request it as a feature as it would minimize the need to create additional remotes? It would also enable the ability to automate validation.
Why not just use the same encrypted passwords in both places? Then you can be sure they are the same.
So at the moment you have two different representations of the same password. Why not use the same representation in both places?
$ rclone obscure password
$ rclone obscure password
When you say both places, do you mean file/directory encryption and the salt?
Are you able to elaborate on "same representation"?
Just copy the password / salt from one rclone.conf and use it on the other.
So he's saying use:
In both spots rather than generating another password / salt.
Thanks @Animosity022. Righto.
The use case I am attempting to test is if the current password and salt are valid. This is because when copying sensitive content e.g. passwords, these are only retained in memory for 30 seconds.
For example, if I copy a password and paste it into the configuration, I want to ensure that the password in use is the intended one versus one that is empty.
I think we're circling a bit.
There isn't a current command to do it.
You can re-use the same values and they are valid because you've already tested them.
In your example, I'm assuming you get copying the password from a known location and that known is right. We do that all the time with password managers as you get a quick validation by entering it if you want to validate it's correct.
You can always test the remote as well by executing a command.
@Animosity022, so that I can understand, can you elaborate on "entering it if you want to validate it is correct"? The only option is to enter in the configuration password at the point of running a command. How do I enter in the encryption password and salt? Is the only option to create a new remote?
you might read this for ideas
Decrypt file locally
Thanks @asdffdsa. Sorry if I'm missing something. I read through the details in the link. It seems that the commands are for an encrypted remote (crypt) as opposed to encrypted files and directories. Unless the commands
--crypt can be used for both. If yes, is the command below sufficient?
rclone.exe copyto --stats 10s --progress --log-file=rclone_log.txt --log-level DEBUG --crypt-filename-encryption=off --crypt-directory-name-encryption=false --crypt-password=PASSWORD --crypt-password2=SEED remote:/ /path/to/files/on/local/hard/drive
@asdffdsa, I meant to say, does is it syntactically correct for the purpose of decrypting an encrypted file?