Cyberduck Mountain Duck CLI

#10714 closed defect (fixed)

Fails to authenticate where keyboard-interactive mechanism is not supported

Reported by: Seayou Owned by: dkocher
Priority: normal Milestone: 7.1
Component: sftp Version: 6.9.4
Severity: normal Keywords:
Cc: Architecture: Intel
Platform: macOS 10.12

Description

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

Change History (17)

comment:1 Changed on Jun 16, 2019 at 11:09:28 PM by CSHost

Hello,

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

comment:2 Changed on Jul 10, 2019 at 10:00:20 PM by dkocher

  • Milestone set to 7.0.2
  • Owner set to dkocher
  • Status changed from new to assigned

comment:3 Changed on Jul 10, 2019 at 10:07:00 PM by dkocher

  • Summary changed from SFTP client fails to authenticate where keyboard-interactive mechanism is not supported to Fails to authenticate where keyboard-interactive mechanism is not supported

comment:4 Changed on Jul 24, 2019 at 8:28:59 PM by dkocher

  • Milestone changed from 7.0.2 to 7.1

Ticket retargeted after milestone closed

comment:5 Changed on Aug 7, 2019 at 9:03:48 AM by CSHost

Hello,

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

comment:6 Changed on Aug 13, 2019 at 8:57:14 AM by dkocher

Can you provide a temporary test account on the server?

comment:7 follow-up: Changed on Aug 13, 2019 at 10:05:52 AM by 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!

comment:8 in reply to: ↑ 7 Changed on Aug 13, 2019 at 11:57:10 AM by dkocher

Replying to 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@…].

comment:9 Changed on Aug 15, 2019 at 7:00:20 AM by CSHost

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.

comment:10 Changed on Aug 15, 2019 at 2:27:02 PM by dkocher

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.

comment:11 Changed on Aug 15, 2019 at 3:03:00 PM by dkocher

  • Resolution set to thirdparty
  • Status changed from assigned to closed

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

comment:12 follow-up: Changed on Aug 15, 2019 at 9:50:10 PM by Seayou

  • Resolution thirdparty deleted
  • Status changed from closed to reopened

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.

Last edited on Aug 15, 2019 at 9:51:11 PM by Seayou (previous) (diff)

comment:13 in reply to: ↑ 12 ; follow-up: Changed on Aug 18, 2019 at 6:07:42 PM by dkocher

Replying to Seayou:

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

comment:14 in reply to: ↑ 13 Changed on Aug 18, 2019 at 6:08:53 PM by dkocher

Replying to dkocher:

Replying to 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.

Last edited on Aug 18, 2019 at 6:09:47 PM by dkocher (previous) (diff)

comment:15 Changed on Aug 20, 2019 at 7:46:32 AM by dkocher

  • Status changed from reopened to new

comment:16 Changed on Aug 20, 2019 at 7:46:36 AM by dkocher

  • Status changed from new to assigned

comment:17 Changed on Aug 20, 2019 at 10:02:15 AM by dkocher

  • Resolution set to fixed
  • Status changed from assigned to closed

In r47542.

Note: See TracTickets for help on using tickets.
swiss made software