Sftp key failing

Bug
#1

While using key based authentication for SFTP backups, my client fails with the message:

2021-10-13 14:51:19.170 ERROR STORAGE_CREATE Failed to load the SFTP storage at sftp://duplicacy-user@server/duplicacy: ssh: handshake failed: ssh: disconnect, reason 2: Too many authentication failures
Failed to load the SFTP storage at sftp://duplicacy-user@server/duplicacy: ssh: handshake failed: ssh: disconnect, reason 2: Too many authentication failures

My shell is configured with multiple keys for various different uses, and my ssh config file specifies which key for use for the endpoints I normally use. Ex: github, work servers, personal servers

Please describe what you expect to happen (but doesn’t):
I expect duplicacy to honor the key I configured while setting up the storage profile.

Please describe what actually happens (the wrong behaviour):
Duplicacy fails to connect, because it appears to be iterating through all of the keys in my ssh-agent configuration instead of the key specified at setup time.

This bug has been frustrating me for quite some time now, and if a solution can not be offered I will have to request a refund for all of my licenses. It would be a real shame to have to go through that hassle, given the fact that the SFTP browser in the web UI clearly works properly.

#2

My understanding is that an ssh client would just forward the key challenge to the ssh agent, which then decides which key to use. Duplicacy shouldn’t be able to iterate through all keys.

Can you make sure that the valid key is configured correctly for the storage? In particular, is there IdentitiesOnly yes to exclude other keys?

#3

Yes, in my .ssh/config I have IdentitiesOnly yes for all hosts.

#4

If you unset the environment variable SSH_AUTH_SOCK then the CLI will only use the key that you provide. So what you need to do is to unset this variable when starting the web GUI. Which OS are you running?

#5

If I change the order that my keys are added to ssh-agent, then duplicacy actually works. This is how I know it’s iterating through keys in the agent rather than Duplicacy actually offering a key that I’ve specified.

Is there a way to make Duplicacy not use ssh-agent at all, and instead use the key I supplied during storage setup?

#6

The CLI checks SSH_AUTH_SOCK and if it is set the CLI will try to connect to ssh-agent first at the address contained in SSH_AUTH_SOCK. By unsetting SSH_AUTH_SOCK you can avoid the ssh-agent.

#7

I need ssh-agent, so disabling isn’t an option. I guess tomstate.the request more directly- please use the provided key first, and fall back to the agent. If a user explicitly specifies a key, that’s clearly the key they want used rather than dipping into the agent.

It should just be reversing the priority.

#8

You can unset SSH_AUTH_SOCK only for the web GUI, but that depends on your OS. That is why I asked you which OS you’re running.

This is meant to be a workaround. In the next web GUI release I’ll unset SSH_AUTH_SOCK when invoking the CLI so this issue will go away.