Cannot connect anymore via SFTP using SSH private key

[merkste]

Describe the bug
With the current version of Cyberduck (8.5.6 (39394)) I cannot use an existing SFTP bookmark that uses SSH key authentication. The key is provided explicitly as path to the key file in the configuration. It worked before (Jan/Feb). Nothing changed on the server side and I can still connect via SSH from the CLI. I suspect from the logs that something goes wrong when selecting the key. Cyberduck seems to try several keys from .ssh which leads to too many authentication attempts.

To Reproduce
Can't say yet without further experiments.

Expected behavior
Existing bookmarks should keep working in newer releases of Cyberduck.

Desktop (please complete the following information):

• OS: MacOS
• Version 13.2.1

Log Files
On request, contains sensitive information.

[ylangisc]

Without a debug log file with a failed connection attempt it's impossible to find the reason. Feel free to anonymize the parts you consider as sensitive although no password or whatsoever are logged.

[dkocher]

We have documentation for possible causes with too many authentication attempts when connecting to an SSH server.

We recently made improvements to match the authentication attempt order of OpenSSH

• Specifying public keys in IdentityFile #13935
• Prioritise password authentication if one is set. #13700
• Prioritize identity set in bookmark before enumerating #13680

[merkste]

Yes, my issue looks similar to #13680.

[merkste]

For the time being, is there an option to disable using the agent and just use the provided key file?

[merkste]

Hi! Sorry, it took me a while.

1. Log file is here:
   cyberduck.log
2. Connection via the command-line sftp -i <path-to-key> -oPort=<port> <user>@<host>
3. It seems to me that for unknown reasons, the provided key (kfle) is not used. Instead, keys from .ssh are tried. For the last test I deleted .ssh to see whether the provided key is used now; no success.

Please let me know if you need further information.

[merkste]

Problem persists in Version 8.5.7 (39535)

[ylangisc]

Please make sure to have a ~/.ssh/config in place with an entry for your host, e.g.:

Host my.hostname.com
        User myusername
        IdentityFile ~/.ssh/mykeyfile
	IdentitiesOnly yes

[merkste]

I do not understand. I believed the point of providing the key in the configuration is to use that key and not to pick up something from .ssh. Can you please elaborate? I used to keep this specific key separate (and this worked until recently). Also, my .ssh uses a Host * configuration with named key dirs under .ssh/ids .

[ylangisc]

We try to imitate the behaviour of the ssh client which also tries any keys available through the ssh-agent before an explicitly specified key (-i option) is tried - unless your ~/.ssh/config contains a IdentitiesOnly yes entry. You can verify this behaviour by adding -v to your ssh command. Also refer to man ssh_config regarding the IdentitiesOnly setting.
In your log file I can see that your ssh-agent has 4 identities configured which are tried before the explicit key.

[merkste]

I see. Interestingly, the key provided by -i is still used first:

debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 4 keys
debug1: Will attempt key: <path-to-key> RSA <...> explicit agent
debug1: Will attempt key: <other-key> RSA <...> agent
debug1: Will attempt key: <other-key> RSA <...> agent
debug1: Will attempt key: <other-key> RSA <...> agent
debug1: Will attempt key: <other-key-by-host>  explicit

Do I miss something? My .ssh config read as follows:

# Look for key in directory %h=host for key %r = remote user
IdentityFile /<user>/.ssh/ids/%h/%r

Host *
IgnoreUnknown UseKeychain
AddKeysToAgent yes
UseKeychain yes

Though, thanks for pointing to IdentitiesOnly yes. It was indeed missing and I re-added it to the config.

[merkste]

... and of course, with that option it works in Cyberduck, too. But I am still curious, what's going on. :-D

[WhatImListnTo]

Sorry but I just encountered this same issue. I agree that this is super confusing. The latest version of CyberDuck under Windows 10 does not at all face this issue. Only the MacOS version does. This is also confusing. The error messages states to contact your Webhosting provider for help. I did this, and they wanted to take all sorts of actions that would not have solved this issue.

The solution is to create ~/.ssh/config containing:
IdentitiesOnly yes

Again, Windows does not require this. Only MacOS does. This does not make sense to me.