Unable to connect via SFTP

[mathio]

Describe the bug

Connecting via SFTP with password authentication fails. Cyberduck tries to authenticate via public key.
This is happening for Cyberduck version 8+. The issue is not present in Cyberduck 7.10.2.

To Reproduce

1. Create new SFTP connection bookmark
2. Setup authentication via password
3. Set SSH Private Key as "None"
4. Double click the bookmark to connect
5. The connection attempt is rejected, UI shows an error message:

Connection failed
Application error. The connection attempt was rejected. The server may be down, or your network may not be properly configured.

Expected behavior
Connection should not fail.
I was told by my hosting provider the client is trying to connect using public key however it is configured to use password instead. Cyberduck should authenticate using password.

Screenshots

Desktop:

• OS: macOS Catalina 10.15.7
• Version 8.3.3 (also tried with versions 8.2.3 and 8.0.0)

Log Files
Note: The domain was replaced with example.com in all logs.

Related Cyberduck log:

2022-06-08 00:16:40,223 [sshj-Reader-example.com/37.9.175.156:22] DEBUG net.schmizz.sshj.transport.kex.Curve25519SHA256 - Sending SSH_MSG_KEXDH_INIT
2022-06-08 00:16:40,244 [sshj-Reader-example.com/37.9.175.156:22] INFO  net.schmizz.sshj.transport.TransportImpl - Received SSH_MSG_DISCONNECT (reason=BY_APPLICATION, msg=Application error)
2022-06-08 00:16:40,244 [sshj-Reader-example.com/37.9.175.156:22] ERROR net.schmizz.sshj.transport.TransportImpl - Dying because - Application error
net.schmizz.sshj.transport.TransportException: Application error
	at net.schmizz.sshj.transport.TransportImpl.gotDisconnect(TransportImpl.java:533) ~[sshj-0.33.0.jar:?]
	at net.schmizz.sshj.transport.TransportImpl.handle(TransportImpl.java:489) ~[sshj-0.33.0.jar:?]
	at net.schmizz.sshj.transport.Decoder.decode(Decoder.java:113) ~[sshj-0.33.0.jar:?]
	at net.schmizz.sshj.transport.Decoder.received(Decoder.java:200) ~[sshj-0.33.0.jar:?]
	at net.schmizz.sshj.transport.Reader.run(Reader.java:60) ~[sshj-0.33.0.jar:?]

Full log here: cyberduck.log

Related log from hosting provider:

USER [example.com](http://example.com/) (Login failed): authentication via 'ssh-rsa' public key failed

Additional context
I can connect via sftp command line without any issues, therefore I can rule out general network issues.

Workaround
Downgrading all the way down to Cyberduck version 7.10.2 works fine.

[wtw]

I too am experiencing this issue. The log (on my side) does not add anything useful, I am getting „Too many authentication failures“ right now. Don't have any info from the server side.

Additional context
I can connect via ssh without any issues.

Workaround
For me 8.3.0, 8.3.1, 8.3.2 are working fine, 8.3.3 is showing said error. So the cause seems to be something added in that version. Might relate to 63d1d6c?

[Rizzle93]

I am also seeing this on Cyberduck version 8.3.3: getting the 'Too many authentication failures' with existing saved configs and with newly created configs (all using password auth). I've just downgraded to version 8.3.2, and password auth seems to be working for that version

[geroembser]

I also started to have connection issues with version 8.3.3. Downgrading to version 8.3.2 makes everything work again. I've noticed, however, that I can solve the problem in 8.3.3 by deleting the keys from my ssh-agent with ssh-add -d -K. As soon as I'll add them again with something like ssh-add -K the SFTP-login with Cyberduck will no longer work in 8.3.3 (but it does in 8.3.2!). Maybe this information will help someone, so I share it here....

[ylangisc]

@mathio Thanks for the logfile which does not give too much insight why the auth process fails. Any chance to post a logfile generated with version 7.10.2?

[ylangisc]

@wtw @Rizzle93 @geroembser Can you please provide a debug log of a failing connection attempt with version 8.3.3?

[wtw]

@ylangisc Debug log for 8.3.3 is attached, it should include everything around the failed attempt. I anonymized all sensitive data and removed about 400 lines of „DEBUG net.schmizz.sshj.common.ECDSAVariationsAdapter - Key algo: ecdsa-sha2-nistp256, Key curve:“ messages. Mind that this is a bookmark that works with version 8.3.2 without any changes, so the connection details are valid. Same problem persists in version 8.4.0.

As @mathio mentioned there are failing authentication attempts with different keypairs. After these failing authentication attempts some background task returns null, which causes an exception. Authentication method password is never tried, only none and publickey are mentioned in the log. I compared the log briefly with the log from 8.3.2 and only in 8.3.3 I get this error:
2022-06-28 15:36:14,545 [sshj-Reader-XXXSERVERNAMEXXX/XXXIPADDRESSXXX:22] ERROR net.schmizz.sshj.transport.TransportImpl - Dying because - Too many authentication failures, although the same SSH connection attempts should fail in 8.3.2 as well. Can it be that the code is not prepared for such an error and bails out before trying password authentication? Also the sshj dependency was updated between 8.3.2 (0.32.4) and 8.3.3 (0.33.0). Hope any of this guesswork helps. :)

cyberduck-connection.log

[ylangisc]

Thanks @wtw for the log. I can see that password auth would also be tried if all other options do not work but it looks like your server has set MaxAuthTries to 2 which makes the subsequent auth attempts fail. Any chance to also post a log of an auth attempt with version 8.3.2? Still not sure why the order of auth methods has changed.

[wtw]

Sure, it seems that the order of auth methods is the same, but not only two of my keys are used, but all four of them. There is no error after two attempts. It is the same bookmark/server and I can switch from 8.3.2 (works) to 8.3.3 (too many attempts) and back at will. After all keys failed, password auth is tried and succeeds.

cyberduck-connection-8.3.2.log

[vzz3]

I have the same Problem "Too many authentication failures. Please contact your web hosting service provider for assistance." with version 8.4.2 on MacOS 11.6 (20G165). However, I need a key for the authentication and not a password. The correct key is selected in the connection settings and no password is in the password input field. After a downgrade to 8.3.2 it works as expected. Thanks to @wtw for posting the last working version numbers.