#11357 closed Bug report (fixed)
FileZilla 3.27.0.1 unable to connect to RHEL 7.4. Able to connect with other SFTP clients including command line
| Reported by: | pkbarbiedoll | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | FileZilla Client |
| Keywords: | Cc: | ||
| Component version: | 3.27.0.1 | Operating system type: | Linux |
| Operating system version: | RHEL 7.4 |
Description
My web server was recently updated from RHEL 7.3 to 7.4. After this regular server OS update I am unable to log in with Filezilla 3.27.0.1.
I use passwordless login to connect over SSH and this was working fine (in FileZilla) until the server OS update last night. None of the server SSH config files were modified as part of the OS update (based on file creation/modified dates).
I am able to connect to the server via the command line sftp client. I'm also able to connect with at least two other SFTP guis (Caja and gFTP).
Change History (20)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Note that our servers run in FIPS mode, so MD5 (and now with 7.4, SHA-1) Ciphers are not available. The same sshd config (right above) worked fine with Filzilla until the RHEL update yesterday.
comment:3 by , 7 years ago
| Status: | new → moreinfo |
|---|
In ~/.putty/session/*, do you by chance have the BugHMAC2 or BuggyMac settings set to anything other than 0?
comment:4 by , 7 years ago
| Status: | moreinfo → new |
|---|
user@linux-mint-18-laptop ~ $ ll ~/.putty/session/*
ls: cannot access /home/user/.putty/session/*: No such file or directory
user@linux-mint-18-laptop ~ $ ll ~/.putty/
total 20
drwx------ 2 user user 4096 May 22 11:16 .
drwxr-xr-x 69 user user 4096 Aug 9 16:12 ..
-rw------- 1 user user 600 Aug 9 17:05 randomseed
-rw-r--r-- 1 user user 7599 May 22 11:16 sshhostkeys
user@linux-mint-18-laptop ~ $
comment:6 by , 7 years ago
Here are the mac's my local system uses:
user@linux-mint-18-laptop ~ $ ssh -Q mac hmac-sha1 hmac-sha1-96 hmac-sha2-256 hmac-sha2-512 hmac-md5 hmac-md5-96 hmac-ripemd160 hmac-ripemd160@openssh.com umac-64@openssh.com umac-128@openssh.com hmac-sha1-etm@openssh.com hmac-sha1-96-etm@openssh.com hmac-sha2-256-etm@openssh.com hmac-sha2-512-etm@openssh.com hmac-md5-etm@openssh.com hmac-md5-96-etm@openssh.com hmac-ripemd160-etm@openssh.com umac-64-etm@openssh.com umac-128-etm@openssh.com
The server MACs in use are hmac-sha2-512 and hmac-sha2-256, which matches what the client OS has.
Filezilla appears to ignore what my client OS has configured and is sending the following MACs to the server:
fatal: no matching mac found: client hmac-sha1, hmac-sha1-96, hmac-md5
comment:7 by , 7 years ago
The server MACs in use are hmac-sha2-512 and hmac-sha2-256, which matches what the client OS is using.
Filezilla appears to ignore what my client OS has configured and is sending the following MACs to the server:
# on rhel74server # tail /var/log/secure fatal: no matching mac found: client hmac-sha1, hmac-sha1-96, hmac-md5
comment:8 by , 7 years ago
It's a bug in OpenSSH, it improperly parses the client version in the initial client hello, applying some compatibility fixups for antique PuTTY versions.
The fixup consists of removing algorithms from the Key Exchange Init packet sent by the client.
comment:9 by , 7 years ago
Any known workaround? I cannot add back the insecure SHA-1 or MD5 Ciphers/MACs.
comment:10 by , 7 years ago
Also,
1) Do you have a url for the OpenSSL bug report?
2) Why is FileZilla using an antique version of Putty/PSFTP/fzsftp?
Thanks. I am hopeful this can be addressed without being asked to introduce security vulnerabilities to our web servers in downgrading to affected Ciphers/MACs.
comment:11 by , 7 years ago
No workaround.
Two solutions:
- Change and recompile OpenSSH to lobotomize its compatibility foo
- Change and recompile FZ to use a different version string the SSH client hello.
comment:12 by , 7 years ago
Change and recompile FZ to use a different version string the SSH client hello.
Are you aware of anyone who was successful in this? Is there a ticket or guide? My google fu fails me: "Recompile filezilla to use a different version string the SSH client hello." isn't returning anything useful.
It's the least desirable option since I would then have to apply the same fix to each new release, but I am stuck right now. Nobody else's SFTP client has expandable tree directories on both source and directory. I have to click up through folders on gFTP and a couple others I looked at, which is slow and not desirable at all.
comment:13 by , 7 years ago
Why is FileZilla using an antique version of Putty/PSFTP/fzsftp?
It isn't. However OpenSSH thinks so as it misparses the client version.
comment:14 by , 7 years ago
Could you please link up to the OpenSSL bug report, and/or a url in how to fix the version string in FileZilla via compiling?
As you might imagine, searching for search words above turns up everything but what I am looking for.
comment:15 by , 7 years ago
Are you aware of anyone who was successful in this?
Yes. Me. I have committed a fix to the repository in #8520
Is there a ticket or guide?
This ticket for the bug, compilation instructions are in the wiki: https://wiki.filezilla-project.org/Client_Compile
Could you please link up to the OpenSSL bug report
There is none yet.
comment:16 by , 7 years ago
This points to a ticket titled "remove a directory". Could you please check that ticket number and repost?
wiki
Thanks, will investigate.
OpenSSL bug report
There is none yet
Are you thinking of submitting one? I'm not sure I have enough information in this ticket to proceed with a bug report of my own.
comment:18 by , 7 years ago
Wrong syntax. Try this: https://svn.filezilla-project.org/filezilla?revision=8520&view=revision
comment:19 by , 7 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Should be fixed in FileZilla 3.27.1
After updating several of my web servers last night we are now unable to connect to them with FileZilla SFTP client. Here's the FileZilla log:
Checking the server's error log I find:
Here is the server's ssh config:
We are required to run those Ciphers and MACs, so changing or adding any is problematic. The above config worked OK until the server OS was updated from RHEL 7.3 to 7.4 a day ago.