Conflict with 1Password SSH Helper

[n9yty]

I've been having problems with versions since 9.1.3 on my Mac, but only on certain hosts... I looked through the debugging logs and didn't find anything conclusive except that in the end when it was using hte agent for SSH login (using privkey only, no password) it just failed. Then I saw a reference to 1Password and remembered that I turned on SSH Agent support there. I disabled it and now tthe latest version of Cyberduck works fine. Is this a conflict that can be resovled so both can exist together or not? Strange that it did work in 9.1.3.

[n9yty]

Further note that I did not have the key for this host imported into 1Password - but why doesn't Cyberduck just use the key configured for the host before trying the agent? I could see falling back to 1Password if none of the supplied configuration worked but it seems to just give it over to 1Password entirely?

[AliveDevil]

Please describe your situation further, as we can't reproduce any ssh-agent issues with 1Password.
Following things have to be configured, in order for 1Password to correctly provide authentication information:

• In ~/.ssh/config an entry for IdentityAgent ~/Library/Group\ Containers/2BUA8C4S2C.com.1password/t/agent.sock or configured SSH_AUTH_SOCK
• Configured your host with IdentitiesOnly yes and IdentityFile - identity file is the SSH public key as exported from 1Password,
  or when using the new SSH Bookmarks the path to ~/.ssh/1Password/sh256_Thumbprint.pub
  ❗ Cyberduck doesn't support the Include-directive

If you didn't configure SSH_AUTH_SOCK or IdentityAgent there's nothing Cyberduck can do to connect to the 1Password SSH agent.
If you didn't configure IdentitiesOnly and IdentityFile Cyberduck will try every SSH key in 1Password, until one works, triggering "too many authentication failures" quickly.
Please provide the debug log file for one connection attempt where Cyberduck fails to use the configured SSH agent, ideally delete the previous log file, and send a clean one.

[n9yty]

You missed my point.

I had enabled it in 1Password and may use it for other things, but in CyberDuck I had sites SPECIFICALLY CONFIGURED with the key file to use but it was breaking the login because that key was not in 1Password. I don't want it in 1Password. But I have the keyfile, and had it configured in CyberDuck, but having that option enabled was breaking things.

My point is, I guess, that if the configuration is complete in 1Password it should use that information and not try to reference other sources. If information is missing, then consult other sources all you want.

[AliveDevil]

I've tried to reproduce your use case:

• 1Password, with configured SSH agent
• "id_type" and "id_type.pub" in ~/.ssh
• Cyberduck configured to use id_type in the dropdown
• Connect in Cyberduck and suppress every attempt of Cyberduck to access a specific key in 1Password
• SSH server stops the connection after four failed attempts

In that case, Cyberduck 9.1.3 and 9.1.6 behave exactly the same: Trying every SSH agent key, until the SSH server stops it, and this behavior hasn't changed recently - we are prioritizing password authentication, but agent-authentication is done before using the configured private key.
This behavior though is different from what we've published on our docs-page for SFTP connections, and we'll have to revisit this.

You can edit the .duck-file in the application support bookmarks-folder to disable ssh agent authentication, by creating the "Custom" dict, and appending following data:

	<key>Custom</key>
	<dict>
		<key>ssh.authentication.agent.enable</key>
		<string>false</string>
	</dict>
</dict>
</plist>

If Custom already exists, add the key-string pair in the dict-part.

Alternatively, if you don't want Cyberduck to use SSH agent authentication ever again, use

• defaults write ch.sudo.cyberduck ssh.authentication.agent.enable false
  in Terminal.