Drive is not ready

Wow. just wow. No comment here…

Define “see”? You can use duplicacy to enumerate revisions, files in each revision, and restore a bunch or all files from a specific revision. There is a feature in the works to mount the revisions as a filesystem for you to be able to browse with native tools such as Explorer. But if you’re asking whether duplicacy keeps your files plaintext at the destination—then no. You can look at what’s there—a few folders with binary encrypted chunks. But this is not unlike NTFS nor any other file system—it’s an illusion that is created for you to represent binary data with higher abstraction level. Here is a good discussion on this exact topic, to avoid repeating this here: File Format/ Accessbility. You may also want to read the paper if you are interested in how duplicacy works.

1 Like

Ok, so i have duplicacy backing up to a mapped driver over ssh using sftpDrive software.
image
if i browse the files of the mapped drive, will i be able to see the actual backed up files like if i did a copy/paste sorta speak?

Backup directly to SFTP server instead of mounting it and backing up to a mounted disk: doing the latter only reduces reliability and introduces unnecessary complexity, failure points, and risk (e.g. ransomware destroying your backup much easier).

Please read the topics I linked in my previous comment.

1 Like

i am reading the paper now. Thans for that information.

ok, ill change the settings now then and not backup to the NAS via ssh.

My key has a passphrase, will that be an issue? i cant remember if duplicacy can hanlde passphrases or not?

well, duplicacy may be able to handle pass phrases but it doesnt like my key for some reason. I am using openssh and all the other sftp clients use this same key just fine…

You mean the opposite, right? It’s ok to back up via ssh.

I think it was implemented long time ago: SSH key with passphrase

1 Like

yeah, i ment the opposite haha.


ok, keyphrase worked, just labled password is all, however, duplicacy does not like the key. All my other clients used this key. I might have to recreate key pair just for duplicacy in a newer cipher?

You need to update your sftp server to use modern cyphers, or switch duplicacy to compatibility mode (sftpc): Which ciphers does duplicacy support for SFTP? - #4 by saspus

What is your SFTP server? Isn’t it Synology by a chance?

1 Like

server has all modern keys available. This key is a RSA 3072 key. RSA is old. I can do the ECDSA keys as well.
image

I am using Bitvise as my server:)

hmm, i just generated a new keypair using the ecdsa 521 and duplicacy still doesnt like it.

How do i switch the gui to compatibility mode?

thanks

Ok, this is what bitvise support said to me:

the error in the screenshot is unrelated to the public key. The problem is that the client is trying to use the encryption algorithm “aes256-cbc”, which is disabled by default in recent SSH Server versions. The algorithm is disabled because CBC algorithms have a security weakness against active attacks, and are therefore not recommended for use.

I don’t think bitvise support is correct.

That error means that your private key is encrypted by aes256-cbc, but earlier versions (1.4.0 or older) of the web GUI couldn’t decrypt private keys encrypted by this algorithm. This was first reported in Which ciphers does duplicacy support for SFTP?

So you can either upgrade the web GUI to the latest version, or regenerate your private keying using aes256-ctr rather than aes256-cbc.

1 Like

i am using the newest version 1.6.3 of the GUI, i just installed it today:)

According to my server settings, i am using the ctr encryption. That is whats throwing me off of why i keep getting the error. CBC is not even turned on in bitvise by default in encryption settings. Its super strange and driving me crazy hahaha.

according to my server settings, cbc is not enabled. CTR is, but not CBC

I know it will all work out. Im not to worried

here is the screen shot of the encryption methods it is able to use

image

aes256ctr is on there but keys dont use aes. AES is the encryption for the end to end tunnel once authentication has happened via the keys. yes, AES does use a “key” sort of speak but i can not generate key pairs that use AES256ctr, thats impossible to do because private keys do not use AES. AES is part of the setup during the handshake process when authentication is happening using public/private keys, but AES is not used to generate private keys. public/private asymmetrical key pairs that can be created are only used for authentication, not encrypting the connection.

Does your private key file start with lines like this:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,EAA83BBE439FD1AA75DF7B49F3EC15B6
1 Like

no it does not.

Just letters and number after : BEGIN RSA PRIVATE KEY-----

That means your private key is not encrypted. How did you generate the key?

1 Like

using the bitvise key generator with aes 256 ctr encryption enabled.

my private key does have the AES ctr label in it but its not at the beginning. The aes 256 ctr is for the symmetric encryption of the end-to-end tunnel, while the RSA uses asymmetric encryption for authentication.

Symmetric keys are used by SSH in order to encrypt the entire connection. Contrary to what some users assume, public/private asymmetrical key pairs that can be created are only used for authentication, not encrypting the connection. The symmetrical encryption allows even password authentication to be protected against snooping.

image

Can you generate a new key in the same way and send it to me?

1 Like

yeah i can do that. might be in the morning. I have a computational fluid dynamics lab report due at freakin midnight.

if it doesnt work, i can always use the CLI from my ubuntu box to make a key or even putty. but let me send you my key and see if you can figure out what the hell is going on hahaha

thanks a ton