SFTP stopped working in rev. 3.21.0

[Evandro]

I have some servers using SFTP to access them.
After new update to Rev. 3.21.0 it stopped working.
The problem occurs on Login that don't even have a chance to type Password, then Timeout occurs.

It was necessary to downgrade to previous released revision.

Thanks.

[Eric Ruth]

Same problem. Co-worker experienced it, so I tested an SFTP site before upgrading (success), upgraded, and tried again (failure).

[Tim Kosse]

Which SFTP server software (product and version) is the server running?

[Eric Ruth]

OpenSSH_6.2p2, OpenSSL 0.9.8j-fips 07 Jan 2009

[Eric Ruth]

Downgraded to 3.20.1, and I can connect to the sites, again.

[Tim Kosse]

OpenSSH_6.2p2, OpenSSL 0.9.8j-fips 07 Jan 2009

That server is quite outdated. Both OpenSSH 6.2 and OpenSSL 0.9.8j contain several security vulnerabilities. Please update.

There's a good chance that the problem you are seeing is caused by a bug in this old OpenSSH version.

Do you still experience this issue with a more modern server?

[Tim Kosse]

From duplicate #10962:

The server log reveals this: sshd[29972]: fatal: matching cipher is not supported: aes256-gcm@… [preauth]

[Tim Kosse]

It's a bug in OpenSSH that has been fixed ages ago in OpenSSH 6.3p1.

In the version of OpenSSH you are using, support for the aes256-gcm@… cipher has been disabled, yet OpenSSH still includes it in its default cipher list.

[horihel]

for completeness (and google):
The workaround for the server (if you can't update) is adding a "Ciphers" line to /etc/ssh/sshd_config with the defaults (see man page) and omit all ciphers with @ symbol in it.

if you don't have control over the server config then your only workaround is downgrading filezilla and/or ask the server operator to fix the server.

[Evandro]

Usually when software upgrade is done, it is recommended to be backward compatible software.

For the solution above, it is quite strange the recommendation to change the server, since this is under administrator properties and most of the cases it is impossible for clients to put a finger on it, even to reach the administrator for any chat.
Lets say who cares what software client we are using.

If the software client can not be backward compatible, it could die shortly due to "less" usage or specific servers revision.

It is sad such decision for client software with that high level to keep using older revision due to compatibility with legacy server as it is called so.

Anyway thanks for support.

[Tim Kosse]

FileZilla is fully compatible even with your old legacy server weren't it for a crippling bug in the server itself that breaks backwards compatibility.

Imagine you are asking your neighbor whether he speaks French, he reply's "Oui" only to then stare at you blankly if you henceforth speak to him in French.

There's really nothing I can do except to intentionally degrade performance for all users of FileZilla even if they are using a server proper. That would obviously be a bad idea.

[daumas]

FileZilla handles the "bug" in OpenSSH poorly. The user is shown "remote connection reset" and the initial impression is that there is a firewall issue.

I wish you would reconsider addressing this one of two ways.

1. Add a fallback to allow connections with a different cipher if the initial cipher negotiation fails. This will allow Filezilla to continue working without modifying the server. Newer OpenSSH versions connect to "bad" OpenSSH servers without any workarounds. So when I can connect with SFTP through OpenSSH but not with Filezilla... who is the winner?

2. Report a failure that the cipher negotiation failed and to upgrade the server or add a version check against OpenSSH 6.2 and older. However get ready for more reports. There are many SUSE Enterprise installations with this version and users that don't know how to upgrade.

[Tim Kosse]

The user is shown "remote connection reset"

That is what actually happens, the server just drops the connection like a hot potato.

Add a fallback to allow connections with a different cipher if the initial cipher negotiation fails.

Subject to fallback attacks. There is no multi-connection fallback protection in the SSH protocol. Just look at for example at RFC 7507 of the unrelated SSL/TLS protocol and the motivation behind this RFC.

Report a failure that the cipher negotiation failed

The cipher negotiation didn't fail, the server accepted the cipher.

[daumas]

I didn't mean fallback by adding a security vulnerability. Please don't be so quick to judge - or ignore other parts of my comment.

OpenSSH supports connections to its own "bad" 6.2 server in the latest version 7.3 client. I haven't taken the time to study the connection handshake to see what's going on, but the same method could be adopted into Filezilla.

[Tim Kosse]

I think it's far easier and also more productive (as it will also work with other clients) to convince your distribution to package a fixed version of OpenSSH that doesn't include unsupported ciphers in its key exchange message.

I had a look at the OpenSSH source when diagnosing this bug, writing a fix for this bug doesn't take more than 5 minutes.

[Tim Kosse]

After fetching the source code of OpenSSH 6.2p2, it just took me a mere 2 minutes to come up with this trivial patch:

diff -u openssh-6.2p2/myproposal.h openssh-6.2p2-fixed/myproposal.h
--- openssh-6.2p2/myproposal.h  2013-01-09 06:12:19.000000000 +0100
+++ openssh-6.2p2-fixed/myproposal.h    2016-10-06 00:25:46.400011683 +0200
@@ -73,7 +73,9 @@
 #define        KEX_DEFAULT_ENCRYPT \
        "aes128-ctr,aes192-ctr,aes256-ctr," \
        "arcfour256,arcfour128," \
+#ifdef OPENSSL_HAVE_EVPGCM
        "aes128-gcm@openssh.com,aes256-gcm@openssh.com," \
+#endif
        "aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc," \
        "aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se"
 #ifdef HAVE_EVP_SHA256

[deezer]

This is not a severe bug in OpenSSL and other things (like scp from the command line) still work despite how the server is configured. FileZilla is the only tool I know of that doesn't work.

I understand you reluctance to make a change, but I would suggest re-thinking this one.

[MarcusD]

I agree with deezer.
SSH by command line, SCP, WINSCP, even old Filezilla works normally.
SSH server version you called "OLD" is the default for SUSE Enterprise 11 SP3.
I believe that, for the most of the clients, it is not possible to ask the network administrators to upgrade the SSH server version just because "new Filezilla version" is not working.
You, Filezilla developers, have been done a great job so far.
But you must accept that workaround is not a good one. You can't enforce that, it is not reasonable.

[strada]

For SLES 11 SP3 mentioned above, it is now sufficient to just upgrade openssh to openssh-6.2p2-0.40.1 - which is available through the official update channel:

zypper ref
zypper up openssh