#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
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: ↓ 8 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: ↓ 13 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.
comment:13 in reply to: ↑ 12 ; follow-up: ↓ 14 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.
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.
Hello,
Can this ticket be reviewed and any possible ETA provided, please?