Sftpc with duplicacy-web GUI

[stefandz]

Apologies for such a niche request! I am trying to connect via the legacy sftpc:// protocol to a server with a non-standard port (in case that is useful - in this case 11111). If configuring via the SFTP tab when adding a storage option via the web GUI in the form server.address:port, I get no common algorithm for key exchange.

This is to be expected, but I can’t see how to force the legacy connection, or how to manually configure any preference files to enable this by hand. I tried prepending the server address with sftpc:// but that gave me Failed to create the sftp client: dial tcp: address sftpf://server.address:11111: too many colons in address.

I appreciate that what I am trying to do is insecure and to be discouraged, but is there a way of making this happen? I ask only because there is no way of improving the security on the RAID server but apart from that it is totally functional and I am reticent to scrap it.

Many thanks in advance for your help!

[saspus]

Configure some storage and then change the url in duplicacy.json.

ask only because there is no way of improving the security on the RAID server

How so? What server is this? If you can ssh to it — you should be able to install modern OpenSSH. And if this is a local server in the lan — some light FTP server, to avoid spending resources encrypting and decrypting traffic or one of the other options that don’t involve encryption overhead and/or outdated software.

[stefandz]

Thanks for your help. In the linked forum post in my previous post you can read my long process of desperately trying to get this server (a Buffalo Linkstation Duo) to run anything other than the stock, outdated sftp server.

I managed to add the following to the duplicacy.json file:

        {
            "name": "raid",
            "url": "sftpc://user@server.address:11111/mnt/array1/backup-location",
            "encrypted": false,
            "ras_encrypted": false,
            "erasure_coding": "",
            "credentials": {
                "ssh_password": "password"
            }
        }

However, this still doesn’t work. The storage appears within the web GUI, but running a backup job linked to it fails. Looking at the log, we find:

Running backup command from /home/local_user/.duplicacy-web/repositories/localhost/5 to back up /home/local_user/folder
Options: [-log backup -storage raid -threads 1 -stats]
2022-02-13 21:35:01.905 INFO REPOSITORY_SET Repository set to /home/local_user/folder
2022-02-13 21:35:01.905 INFO STORAGE_SET Storage set to sftpc://user@server.address:11111/mnt/array1/backup-location
Enter SSH password:2022-02-13 21:35:02.510 ERROR PASSWORD_READ Failed to read the password: EOF
exit status 100

Reviewing the duplicacy.json file after running the command shows that the credentials entry has been removed, so we now have:

        {
            "name": "raid",
            "url": "sftpc://user@server.address:11111/mnt/array1/backup-location",
            "encrypted": false,
            "ras_encrypted": false,
            "erasure_coding": "",
            "credentials": {}
        }

Any suggestions as to what I might be doing incorrectly?

[saspus]

I think password there is supposed to be encrypted. Maybe duplicacy can’t decrypt it and destroys the record for the user to re-enter it?

I would do this:

1. setup temp SFTP server on e.g. your local machine, with the same password.
2. setup the storage location with SFTP to the local server
3. Exit duplicacacy-web process
4. replace sftp://user@localhost:port/… with sftpc://actualuser@actualhost:actualport… and don’t touch the encrypted password.

Depending on how much validation duplicacy (does not) do – it might be enough to fool it.

@stefandz

n the linked forum post in my previous post you can read my long process of desperately trying to get this server (a Buffalo Linkstation Duo) to run anything other than the stock, outdated sftp server.

I did not realize that was a link to a thread :). Still, not clear to me what prevents you from using existing ancient OpenSSH server there to upload new OpenSSH server, configure it to auto-start and bind to a different port, connect to that port, and replace old OpenSSH binary with a new one? Or better yet keep the old one and have both of them running, in case the rest of the OS has some dependencies on that ancient SFTP server; but you are going to have your own new instance there.

[stefandz]

OK. This all worked, after a fashion.

Tricking Duplicacy into generating an encrypted password by setting up a local SFTP server (the Python sftpserver package was a quick way to do this) worked fine. However, then running a backup job failed due to lack of initialisation. I faked this by copying the config file that had been generated on my local SFTP server across manually and creating empty snapshots/backup_name and chunks folders on the remote SFTP server. Not sure of the security of doing this (likely poor) but since I shall never reuse my local server, it feels just like moving the structure to a different NAS.

Thanks for all your help! To answer why not upload a new OpenSSH server - that NAS has almost no RAM, very little flash and uses a PowerPC CPU. Everything you have written is possible - but I really don’t want to mess with the NAS, given that messing with Duplicacy is easier and better supported. Thanks again to you and to @gchen.