Ssh key and ssh-agent

Support
#1

Hello all,

I have a setup that uses SFTP for local network backups, and I recently changed the server to limit the number of failed authentication attempts. The SFTP storage uses an ssh key for authentication, but I believe I’ve found an issue where the key specified for the storage is ignored and the keys stored by ssh-agent are used. This is on MacOS 11.2.1 using licensed duplicacy-web rather than just the CLI version.

When setting up a new storage backend, I specified the host name, the user name, the key file to use, and then click the folder icon to browse for the storage location. This works! I can choose the folder on the remote server perfectly fine. But when continuing to the next configuration page, I get an authentication error. Clearly there are two code paths for authentication here, which I believe is a bug or at the least unexpected.

To prove this theory, I placed my SSH server into debug logging level and captured several key authentication attempts failing, which should not be happening. I have specifically provided a key to be used, no other key should ever be attempted! The error was obvious once I looked at the logs themselves, because the key I use for duplicacy is an ED25519 key, but the logs mention several RSA keys which are used for legacy systems I have access to. Here is a snippet from those logs.

Jun 21 16:30:01 rhodes sshd[735954]: Connection from 192.168.1.73 port 53159 on 192.168.1.21 port 22 rdomain ""
Jun 21 16:30:01 rhodes sshd[735954]: debug1: userauth-request for user duplicacy-user service ssh-connection method none [preauth]
Jun 21 16:30:01 rhodes sshd[735954]: debug1: attempt 0 failures 0 [preauth]
Jun 21 16:30:01 rhodes sshd[735954]: debug1: user duplicacy-user matched 'User duplicacy-user' at line 1
Jun 21 16:30:01 rhodes sshd[735954]: debug1: userauth-request for user duplicacy-user service ssh-connection method publickey [preauth]
Jun 21 16:30:01 rhodes sshd[735954]: debug1: attempt 1 failures 0 [preauth]
Jun 21 16:30:01 rhodes sshd[735954]: debug1: userauth_pubkey: test pkalg ssh-rsa pkblob RSA SHA256:zj9Wx033fSaQTZ/PaLo3kXLs3YFePJ7HwZwAq9RUdms [preauth]
Jun 21 16:30:01 rhodes sshd[735954]: debug1: temporarily_use_uid: 1001/1001 (e=0/0)
Jun 21 16:30:01 rhodes sshd[735954]: debug1: trying public key file /home/duplicacy/.ssh/authorized_keys
Jun 21 16:30:01 rhodes sshd[735954]: Failed publickey for duplicacy-user from 192.168.1.73 port 53159 ssh2: RSA SHA256:zj9Wx033fSaQTZ/PaLo3kXLs3YFePJ7HwZwAq9RUdms
[SNIP] Repeats for 3 more keys
Jun 21 16:30:01 rhodes sshd[735954]: debug1: userauth-request for user duplicacy-user service ssh-connection method publickey [preauth]
Jun 21 16:30:01 rhodes sshd[735954]: debug1: attempt 5 failures 4 [preauth]
Jun 21 16:30:01 rhodes sshd[735954]: debug1: userauth_pubkey: test pkalg ssh-ed25519 pkblob ED25519 SHA256:HWJIsLtXgeof4hkJqDigRbKFqJibM9KRWCgKBkN2Y3Q [preauth]
Jun 21 16:30:01 rhodes sshd[735954]: debug1: temporarily_use_uid: 1001/1001 (e=0/0)
Jun 21 16:30:01 rhodes sshd[735954]: debug1: trying public key file /home/duplicacy/.ssh/authorized_keys
Jun 21 16:30:01 rhodes sshd[735954]: debug1: fd 5 clearing O_NONBLOCK
Jun 21 16:30:01 rhodes sshd[735954]: debug1: /home/duplicacy/.ssh/authorized_keys:1: matching key found: ED25519 SHA256:HWJIsLtXgeof4hkJqDigRbKFqJibM9KRWCgKBkN2Y3Q
Jun 21 16:30:01 rhodes sshd[735954]: debug1: /home/duplicacy/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Jun 21 16:30:01 rhodes sshd[735954]: Accepted key ED25519 SHA256:HWJIsLtXgeof4hkJqDigRbKFqJibM9KRWCgKBkN2Y3Q found at /home/duplicacy/.ssh/authorized_keys:1

The expected behavior here is that when I specify a key file in the storage configuration, that key and only that key will be used for authentication. Using other keys stored in the ssh-agent is, at a minimum, very confusing and at its worst a security concern (though not likely a vulnerability since the user must have the keys added to their agent, and the username on the remote host must exist).

It’s completely possible that I’m missing some critical detail here, but I know when I configure my ssh client to use a specific key for a host configuration, that key and only that key are used. I would have expected the same behavior from duplicacy, perhaps incorrectly. Any help here would be great, since I absolutely want to get my maximum auth attempts back down to something sensible.

#2

The web GUI has its own code to list the remote directory via SFTP only using the key file provided. However, when querying about the status of the storage, it invokes the CLI to run the info command.
The CLI behaves differently – if the ssh-agent is available, the CLI will try to log in via ssh-agent first, even if a key file is provided.

But, doesn’t the log show that the ED25519 key was accepted after several attempts with RSA keys?

#3

Yes, after multiple failures, as long as I increase my SSH server’s failed authentication attempts, it eventually works. That’s not really an acceptable solution, though. I want to turn the failed auth attempts down to something more sane, which is best common practice anyway, and IMO the key offered in the storage setup is the key that should be used.

#4

Is this an issue that might get attention, or am I going to have to find some alternative? I’m really not willing to leave my SSH server in a mode where it’s not properly locked down, and I really think specifying the key file should cause duplicacy to only use that key rather than any key in ssh-agent. I’d also rather not hack up my sshd_config to make an exception (though that may not even be possible to begin with).

#5

Can you add the ED25519 key to ssh-agent and maybe allow it to be used with the sftp storage server only?

#6

The local user (ssh-agent is running under) is my user account. The user on the remote host is for the duplicacy user only, and has a limited environment it is able to access for sftp purposes.

I also have several keys in ssh-agent, which is what is causing the multiple failures. It’s attempting every key in ssh-agent. For a key auth based server, I don’t really want a situation where a user tries multiple keys until they discover a working one.

I guess I’m confused what the purpose of allowing specifying the key file is if duplicacy is just going to attempt to use ssh-agent first? It seems like the proper code path here would be that if a key is specified, use that. If it fails, allow the user to configure duplicacy to use ssh-agent known keys. If that fails, then bail out. But in any case, the number of keys being attempted here is the cause of the auth failures.

#7

I’m still experiencing this issue, and at this point I’m running out of options. The SSH server in question is directly connected to the Internet, so it has some security hardening measures applied to it. Not least of which is limiting the number of authentication attempts with and without a key to prevent attempts at brute forcing or using leaked credentials.

Duplicacy not attempting to use the key that has been specified for the storage is extremely confusing to me. If I explicitly specify a key, I would have expected that to be the method attempted, and then possibly falling back to ssh-agent managed keys. Regardless, with or without the Duplicacy user key in my ssh-agent keyring, other keys exist for my user and they are tried sequentially. Since the remote user on the system us not my normal user account, the problem is presenting itself as Duplicacy attempting to log in as the backup user with my personal key for the server, which is not allowed.

Is there a plan to make Duplicacy use the specified key for the storage pool? If not, how do I make that feature request officially?