Fails to authenticate where keyboard-interactive mechanism is not supported

[cyberduck]

760e97c created the issue

Server is ProFTPd where keyboard-interactive method is not allowed.
Authentication works fine from lftp, filezilla, etc, but from CyberDuck :) Obviously happens both under OSX and Windows

Debug logs from server side (the part that matters here):

2019-05-27 12:54:14,815 [14] <ssh2:10>: auth requested for user 'test', service 'ssh-connection', using method 'keyboard-interactive'
2019-05-27 12:54:14,816 [14] <ssh2:9>: offering authentication methods: password
2019-05-27 12:54:14,817 [14] <ssh2:10>: auth method 'keyboard-interactive' not enabled
2019-05-27 12:54:14,817 [14] <ssh2:19>: waiting for max of 600 secs while polling socket 1 for writing using select(2)
2019-05-27 12:54:14,818 [14] <ssh2:3>: sent SSH_MSG_USER_AUTH_FAILURE (51) packet (64 bytes)
2019-05-27 12:54:15,914 [14] <ssh2:9>: disconnecting (Application error) [at auth.c:1053]

From client side:

May 27 14:48:32 MacBook-Pro Cyberduck[63051]: [Thread-38] DEBUG net.schmizz.concurrent.Promise - Setting <<authenticated>> to `null`
May 27 14:48:32 MacBook-Pro Cyberduck[63051]: [Thread-38] DEBUG net.schmizz.sshj.userauth.UserAuthImpl - Trying `keyboard-interactive` auth...
May 27 14:48:32 MacBook-Pro Cyberduck[63051]: [Thread-38] DEBUG net.schmizz.concurrent.Promise - Awaiting <<authenticated>>
May 27 14:48:33 MacBook-Pro Cyberduck[63051]: [reader] DEBUG net.schmizz.concurrent.Promise - Setting <<authenticated>> to `false`
May 27 14:48:33 MacBook-Pro Cyberduck[63051]: [Thread-38] DEBUG net.schmizz.sshj.userauth.UserAuthImpl - `keyboard-interactive` auth failed
May 27 14:48:33 MacBook-Pro Cyberduck[63051]: [Thread-38] WARN  ch.cyberduck.core.sftp.SFTPSession - Login failed with credentials Credentials{user='test', token='', identity=null} and authentication method ch.cyberduck.core.sftp.auth.SFTPChallengeResponseAuthentication@5ccef2b0
May 27 14:48:33 MacBook-Pro Cyberduck[63051]: [Thread-38] DEBUG ch.cyberduck.core.sftp.SFTPSession - Attempt authentication with credentials Credentials{user='test', token='', identity=null} and authentication method ch.cyberduck.core.sftp.auth.SFTPPasswordAuthentication@346c08a4
May 27 14:48:33 MacBook-Pro Cyberduck[63051]: [Thread-38] DEBUG ch.cyberduck.core.sftp.auth.SFTPPasswordAuthentication - Login using password authentication with credentials Credentials{user='test', token='', identity=null}
May 27 14:48:33 MacBook-Pro Cyberduck[63051]: [Thread-38] DEBUG net.schmizz.concurrent.Promise - Setting <<authenticated>> to `null`
May 27 14:48:33 MacBook-Pro Cyberduck[63051]: [Thread-38] DEBUG net.schmizz.sshj.userauth.UserAuthImpl - Trying `password` auth...
May 27 14:48:33 MacBook-Pro Cyberduck[63051]: [Thread-38] DEBUG net.schmizz.sshj.userauth.method.AuthPassword - Requesting password for [AccountResource] test@192.168.99.105
May 27 14:48:33 MacBook-Pro Cyberduck[63051]: [Thread-38] DEBUG net.schmizz.concurrent.Promise - Awaiting <<authenticated>>
May 27 14:48:34 MacBook-Pro Cyberduck[63051]: [reader] INFO  net.schmizz.sshj.transport.TransportImpl - Received SSH_MSG_DISCONNECT (reason=BY_APPLICATION, msg=Application error)
May 27 14:48:34 MacBook-Pro Cyberduck[63051]: [reader] ERROR net.schmizz.sshj.transport.TransportImpl - Dying because - Application error
	
	net.schmizz.sshj.transport.TransportException: [BY_APPLICATION] Application error
		at net.schmizz.sshj.transport.TransportImpl.gotDisconnect(TransportImpl.java:548)
		at net.schmizz.sshj.transport.TransportImpl.handle(TransportImpl.java:508)
		at net.schmizz.sshj.transport.Decoder.decodeMte(Decoder.java:159)
		at net.schmizz.sshj.transport.Decoder.decode(Decoder.java:79)
		at net.schmizz.sshj.transport.Decoder.received(Decoder.java:231)
		at net.schmizz.sshj.transport.Reader.run(Reader.java:59)

It'd be nice to try password method first

[cyberduck]

4c832c2 commented

Hello,

Can this ticket be reviewed and any possible ETA provided, please?

[cyberduck]

@dkocher commented

Ticket retargeted after milestone closed

[cyberduck]

4c832c2 commented

Hello,

Please let us know whether you any any updates on this ticket?

[cyberduck]

@dkocher commented

Can you provide a temporary test account on the server?

[cyberduck]

4c832c2 commented

Hello,

Thank you for your reply!

Yes, we can provide you with FTP test account login credentials. Please provide us with the email address where we may send the login credentials securely.

Looking forward to your reply!

[cyberduck]

@dkocher commented

Replying to [comment:7 CSHost]:

Hello,

Thank you for your reply!

Yes, we can provide you with FTP test account login credentials. Please provide us with the email address where we may send the login credentials securely.

Looking forward to your reply!

Please write to [support@cyberduck.io].

[cyberduck]

4c832c2 commented

Hello,

Just wanted to let you know that we have sent the login details to your email account on August 14. It has the same subject as this ticket does.

Looking forward to your reply.

[cyberduck]

@dkocher commented

The server is closing the transport channel after the auth with keyboard-interactive method fails. Thus we abort continuing trying to authenticate with different methods.

[cyberduck]

@dkocher commented

This is also reported by the server with disconnecting (Application error) [at auth.c:1053].

[cyberduck]

760e97c commented

Hi, original poster here. Well, I think it's because the client blindly tries with keyboard-interactive without asking the supported methods from the server.

https://www.ietf.org/rfc/rfc4252.txt Section 4.

The server drives the authentication by telling the client which
authentication methods can be used to continue the exchange at any
given time. The client has the freedom to try the methods listed by
the server in any order. This gives the server complete control over
the authentication process if desired, but also gives enough
flexibility for the client to use the methods it supports or that are
most convenient for the user, when multiple methods are offered by
the server.

[cyberduck]

@dkocher commented

Replying to [comment:12 Seayou]:

We receive the list of allowed authentication methods that can continue only after the first USERAUTH_FAILURE failure.

[cyberduck]

@dkocher commented

Replying to [comment:13 dkocher]:

Replying to [comment:12 Seayou]:

We receive the list of allowed authentication methods that can continue only after the first USERAUTH_FAILURE failure.

I see there is a method to properly handle this
The "none" method is reserved, and MUST NOT be listed as supported. However, it MAY be sent by the client. The server MUST always reject this request, unless the client is to be granted access without any authentication, in which case, the server MUST accept this request. The main purpose of sending this request is to get the list of supported methods from the server.

[cyberduck]

@dkocher commented

In 5131067.