Opened 5 months ago

Closed 5 months ago

Last modified 4 months ago

#12218 closed Bug report (rejected)

No supported authentication methods available in 3.48, work fine with 3.47

Reported by: tzorattoa Owned by:
Priority: normal Component: FileZilla Client
Keywords: Cc: tzorattoa, Cedef
Component version: Operating system type: Windows
Operating system version: 10

Description (last modified by tzorattoa)

Hi, connecting to the same remote SFTP server (proftpd) it works fine with filezilla 3.47, and doesn't work with 3.48, with the exact same configuration.

Client logs :
Status: Waiting to retry...
Trace: CControlSocket::SendNextCommand()
Trace: CSftpConnectOpData::Send() in state 0
Status: Connecting to some-sftp.server.com...
Trace: Going to execute C:\Program Files (x86)\FileZilla FTP Client\fzsftp.exe
Response: fzSftp started, protocol_version=9
Trace: CSftpConnectOpData::ParseResponse() in state 0
Trace: CControlSocket::SendNextCommand()
Trace: CSftpConnectOpData::Send() in state 3
Command: open "someuser@…" 22
Trace: Looking up host "some-sftp.server.com" for SSH connection
Trace: Connecting to XX.XX.XX.XX port 22
Trace: We claim version: SSH-2.0-FileZilla_3.48.0
Trace: Remote version: SSH-2.0-SFTP SERVER
Trace: Using SSH protocol version 2
Trace: Doing Diffie-Hellman group exchange
Trace: Doing Diffie-Hellman key exchange using 4096-bit modulus and hash SHA-256 (unaccelerated) with a server-supplied group
Trace: Host key fingerprint is:
Trace: ssh-rsa 4096 dd:9b:bf:e7:a8:d1:41:8d:db:69:26:06:a1:dc:76:3a c7eFbbeLQB8Vd5gOrtj6GZzdoQ6aWGOtCxu5HoFd66E=
Trace: CSftpControlSocket::SetAsyncRequestReply
Command: Trust new Hostkey: Once
Trace: Initialised AES-256 SDCTR (AES-NI accelerated) outbound encryption
Trace: Initialised HMAC-SHA-256 (unaccelerated) outbound MAC algorithm
Trace: Initialised AES-256 SDCTR (AES-NI accelerated) inbound encryption
Trace: Initialised HMAC-SHA-256 (unaccelerated) inbound MAC algorithm
Status: Using username "someuser".
Command: Pass:
Trace: Sent password
Trace: Remote side sent disconnect message type 14 (no more auth methods available): "No other authentication mechanisms available"
Error: FATAL ERROR: Remote side sent disconnect message
Error: type 14 (no more auth methods available):
Error: "No other authentication mechanisms available"
Trace: CSftpControlSocket::OnTerminate without error
Trace: CControlSocket::DoClose(66)
Trace: CControlSocket::ResetOperation(66)
Trace: CSftpConnectOpData::Reset(66) in state 3
Error: Could not connect to server
Trace: CFileZillaEnginePrivate::ResetOperation(66)
Status: Waiting to retry...

Server logs:
2020-07-16 11:38:00,341 mod_sftp/1.0.0[9832]: error using DisplayLogin 'welcome.msg': No such file or directory
2020-07-16 11:38:00,342 mod_sftp/1.0.0[9832]: sent server version 'SSH-2.0-SFTP SERVER'
2020-07-16 11:38:00,342 mod_sftp/1.0.0[9832]: received client version 'SSH-2.0-FileZilla_3.48.0'
2020-07-16 11:38:00,342 mod_sftp/1.0.0[9832]: handling connection from SSH2 client 'FileZilla_3.48.0'
2020-07-16 11:38:00,363 mod_sftp/1.0.0[9832]: + Session key exchange: diffie-hellman-group-exchange-sha256
2020-07-16 11:38:00,363 mod_sftp/1.0.0[9832]: + Session server hostkey: ssh-rsa
2020-07-16 11:38:00,363 mod_sftp/1.0.0[9832]: + Session client-to-server encryption: aes256-ctr
2020-07-16 11:38:00,363 mod_sftp/1.0.0[9832]: + Session server-to-client encryption: aes256-ctr
2020-07-16 11:38:00,363 mod_sftp/1.0.0[9832]: + Session client-to-server MAC: hmac-sha2-256
2020-07-16 11:38:00,363 mod_sftp/1.0.0[9832]: + Session server-to-client MAC: hmac-sha2-256
2020-07-16 11:38:00,363 mod_sftp/1.0.0[9832]: + Session client-to-server compression: none
2020-07-16 11:38:00,363 mod_sftp/1.0.0[9832]: + Session server-to-client compression: none
2020-07-16 11:38:00,915 mod_sftp/1.0.0[9832]: sending acceptable userauth methods: password
2020-07-16 11:38:00,934 mod_sftp/1.0.0[9832]: client sent SSH_MSG_IGNORE message (13 bytes)
2020-07-16 11:38:00,934 mod_sftp/1.0.0[9832]: cipher algorithm 'USERAUTH_REQUEST someuser' or MAC algorithm 'none' unacceptable for password authentication, denying password authentication request
2020-07-16 11:38:00,934 mod_sftp/1.0.0[9832]: no more auth methods available, disconnecting
2020-07-16 11:38:00,934 mod_sftp/1.0.0[9832]: disconnecting YY.YY.YY.YY (No other authentication mechanisms available)

It works both with 3.47 and 3.48 connecting to a remote OpenSSH server instead of proftpd. I suppose there are some differences in the supported algorithms but the error messages are not crystal clear and I didn't found any related changes in the changelog for 3.48 on https://filezilla-project.org/versions.php.

As a workaround we now use another SFTP client.

Change History (6)

comment:1 by tzorattoa, 5 months ago

Description: modified (diff)

comment:2 by Cedef, 5 months ago

Cc: Cedef added

comment:3 by Tim Kosse, 5 months ago

Resolution: rejected
Status: newclosed

There is something wrong with the server software.

Session client-to-server encryption: aes256-ctr
Session server-to-client encryption: aes256-ctr
Session client-to-server MAC: hmac-sha2-256
Session server-to-client MAC: hmac-sha2-256

According to the server log, the session has been negotiated with aes256-ctr as cipher and hmac-sha2-256 as MAC algorithm.

"cipher algorithm 'USERAUTH_REQUEST someuser' or MAC algorithm 'none' unacceptable for password authentication, denying password authentication request"

Here the server claims there is no MAC algorithm and that the cipher algorithm is "USERAUTH_REQUEST someuser", contradicting what it moments ago wrote to the log.

Somehow the internal state of your server got corrupted. This probably is due to a buffer overflow or use-after-free vulnerability in your server. Contact your server vendor for further assistance and in the meantime, use a different server software.


comment:4 by tzorattoa, 5 months ago

Thanks for your answer, I will contact proftpd support.

But how do you explain that it works fine 100% of the time with filezilla 3.47 and never works with 3.48 ? The internal state corruption that you're talking about doesn't sound like something that would occur every single time I try to connect, does it ?

comment:5 by Tim Kosse, 4 months ago

This issue probably is sensitive to timing and grouping of packets. Different clients, not just between products, but also between different versions all have slightly different behavior even when operating fully within the specifications.

comment:6 by Cedef, 4 months ago

For information, I've also sent a bugreport to proftpd here:
https://github.com/proftpd/proftpd/issues/1060

Note: See TracTickets for help on using tickets.