Which ciphers does duplicacy support for SFTP?

[gecko]

Trying to add my local SFTP server as a storage for Duplicacy. Unfortunately it doesn’t appear to support the ciphers that my SSHD server is offering - when trying to add the SFTP server in the Web-UI, I get the following error when trying to choose a directory:

Failed to create the sftp client: ssh: handshake failed: ssh: unknown cipher "aes256-cbc", only supports "aes256-ctr"

This is unfortunate, as I have followed a guide to harden my SSH server to make it safe for external WAN access, but clearly in the process of hardening it, I have disabled the ciphers that Duplicacy likes to use.

This is the first time I’ve had trouble accessing my SSH or SFTP server, as I have used both SSH and SFTP on many apps on both MacOS and iOS, so it’s a shame Duplicacy doesn’t appear to support the same range of ciphers that many others do.

[gecko]

Interestingly, just now adding my SFTP server as a storage using the CLI worked fine, so it’s something about using the Web-UI that is causing this.

[gecko]

Update:

I believe this is actually a problem with the passphrase on the SSH key file, not the cipher. As the CLI prompts for the key passphrase, it isn’t a problem connecting to the SFTP server using the CLI. As a test, I disabled Public Key authentication in the server’s sshd_config file, and enabled password authentication, and then I was finally able to add the SFTP server using the Web-UI.

This is interesting, as according to this Using WebGUI + SFTP + encrypted private key, this How to use and SFTP storage with the webgui using certificates (video), and this Duplicacy Web Edition 1.0.0 is now available, it should be possible to enter the ssh key passphrase in the password field, but it isn’t working for me. I’m pasting the exact same passphrase into the field as I am for the CLI (direct from my password manager), so I don’t know what the problem is here

[saspus]

Just FYI, Duplicacy has a compatibility mode sftp backend sftpc with more outdated ciphers included; but that includes weaker ciphers, so not sure if that is applicable to your case. The aes256-cbc is supposed to be supported through GitHub - golang/crypto: [mirror] Go supplementary cryptography libraries

If that error message is a result of wrong passphrase – then it’s a bug @gchen may want to know about.

[gecko]

@saspus Thanks for your reply. But yeah, I don’t think it actually has anything to do with the ciphers after all, seeing as I was able to successfully add the exact same SFTP server when using the CLI (and the server was running the exact same sshd_config as when trying with the Web-UI).

So it seems like there’s a bug in the Web-UI that has something to do with encrypted ssh keys and trying to put their passphrase in the password field of the Web-UI. Strange that the error it was reporting in the UI was to do with ciphers

Not sure I can do much more debugging on this issue without some guidance.

[gchen]

This is the exact issue as x/crypto/ssh: AES256-CBC isn't supported for passphrase-protected OpenSSH keys · Issue #37939 · golang/go · GitHub. The CLI doesn’t have this issue because it was built with a more recent version of golang.org/x/crypto.

I’ll release a new web GUI version this week to fix this issue.

[gecko]

Ah, that makes sense! I was thinking it was an issue with the ciphers being offered by the SSH (SFTP) server, but what you’re saying is that it’s the cipher that’s encrypting the actual key that is the issue? Great that you’re planning on updating this, thanks for your work

EDIT: I created a new keypair using a more up-to-date version of OpenSSH / ssh-keygen (the one that comes pre-installed on macOS is older), and can confirm that I can now successfully add my SFTP server on the Web-UI just fine. Thanks so much

[Droolio]

I was wondering @gchen, while you’re at it, could you possibly add a setting in the Web Edition that would allow emailing reports without verifying the TLS certificate of the SMTP mail server? As per:

Failed to send the email: x509: certificate signed by unknown authority

There’s a workaround that may allow skipping the TLS cert verification, but I’m more interested in fixing the mail server… Turns out the mail server isn’t responding with the correct certificates, and this seems to be a specific issue with Exchange 2013. Remember, I’m testing this with a public SSL certificate as well as self-signed. BOTH self-signed cert and the real cert are valid and installed correctly, but it appears the previously expired certificates are still bound to the SMTP service …

The problem I have is that I’ve encountered Exchange 2010/2013 servers with receive connectors that still use an internal self-signed certificate.

While the servers do have third party SSL certificates properly installed on receive connectors for external use, Exchange will always picks the internal receive connector based on the connecting client IP (LAN), and present the internal self-signed certificate only - which Duplicacy can’t verify all the way down the chain. I also can’t change the FQDN on the internal receive connector to the third party certificate, as I believe this may break some internal stuff.

I have Vertical Backup email reports just fine, through the same SMTP server (and with TLS), but Duplicacy Web Edition is ultra-strict when it comes to verifying the certificate chain.

Could we have an option to skip the TLS certificate verification?

[gecko]

Where is the known_hosts file kept for the Web-UI? With the CLI it’s in the .duplicacy directory, but I don’t see that with the Web-UI.

After adding my SFTP storage with the newly generated key to test, I made some changes to my SFTP server’s keys so that I can add it to the Web-UI in earnest for backups, but now it’s rejected because the host key has changed

[gchen]

Ok. I’ll just add a new key to the email configuration part but not a GUI control (so you’ll need to edit the duplicacy.json file directly). Would this be good enough?

[gchen]

You can find the known_hosts file under ~/.duplicacy-web/repositories/localhost/*/.duplicacy.

[Droolio]

Yup that would be awesome, thank you.