Is there a way to specify the sftp port number in the gui? If not, it is ok… just need to know so I can set up my NAS properly…
Thanks again!
You can append :port to the server address, such as 192.168.1.100:222.
(I hope it’s ok to re-open this thread for a related issue)
The “:port” suffix works well in the GUI, but I can’t seem to use this in the command-line case (for Linux). I edited the “storage” key in .duplicacy/preferences to add the port there as well, and I can see that it adds an entry to known_hosts, but then the backup ends with this message:
Failed to load the SFTP storage at sftp://abc@def.ghi.jkl:1234/blah: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain
This is a backup to a working Raspberry Pi setup with SFTP enabled but shell access blocked. The initial backups while connected locally worked ok, the box has now been moved off-site, behind a firewall with the outward-facing SSH port routed to a different (high) number.
I can verify proper sftp access from the command line to this new port (with the extra -oPort=1234 option. But adding the port suffix for duplicacy backups doesn’t work as expected.
Is there another way to specify this -oPort=1234 argument inside the preferences file?
It works correctly
[
{
...
"storage": "sftp://user@server.local:22//Volumes/Storage/duplicacy",
...
}
[
Another question is why are you tying to change default SFTP port? This does not increase security at all. Instead, disable password authentication and use key based auth only.
Because it’s a router with several other machines behind it. Port 22 is not available.
The GUI is just a wrapper – it is still the CLI that does all the things under the hood. There is no reason the GUI works but not the CLI. I remember there was a bug in handling the port number in very old versions so please make sure you’re running the latest version.
It looks like the problem is different (and less of a match w.r.t. this original thread).
This fails, with the “handshake failed” message mentioned above:
duplicacy -background backup -threads 4 -stats
But this works:
duplicacy backup -threads 4 -stats
In both cases, I have two env vars set: DUPLICACY_SSH_KEY_FILE and DUPLICACY_PASSWORD.
I’m running 2.1.0 on 64-bit Linux. Very surprising, but no longer a show-stopper - \o/
Do not use -backgound!
It’s an undocumented flag for a reason.
1 Like
@TheBestPessimist, I was about to write the same – since I vaguely remember reading something along those lines elsewhere – but then I tried to search wiki – and it is, in fact, documented: here Global options details, without any recommendation against using it. Perhaps another wiki update is due? 
1 Like