Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#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 pkbarbiedoll, 7 years ago

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:

2017-08-09 16:26:54 7294 3 Status: Connecting to my.rhel74.server...
2017-08-09 16:26:54 7294 3 Response: fzSftp started
2017-08-09 16:26:54 7294 3 Command: keyfile "/home/user/.ssh/fz"
2017-08-09 16:26:54 7294 3 Command: open "user@…" 22
2017-08-09 16:26:54 7294 3 Error: Server unexpectedly closed network connection
2017-08-09 16:26:54 7294 3 Error: Could not connect to server
2017-08-09 16:26:54 7294 3 Status: Waiting to retry...
2017-08-09 16:26:59 7294 3 Status: Connecting to my.rhel74.server...
2017-08-09 16:26:59 7294 3 Response: fzSftp started
2017-08-09 16:26:59 7294 3 Command: keyfile "/home/user/.ssh/fz"
2017-08-09 16:26:59 7294 3 Command: open "user@…" 22
2017-08-09 16:27:00 7294 3 Error: Server unexpectedly closed network connection
2017-08-09 16:27:00 7294 3 Error: Could not connect to server

Checking the server's error log I find:

Aug 9 17:05:45 rhel74server sshd[5278]: FIPS mode initialized

Aug 9 17:05:45 rhel74server sshd[5278]: fatal: no matching mac found: client
hmac-sha1,hmac-sha1-96,hmac-md5 server hmac-sha2-512,hmac-sha2-256
[preauth]

Here is the server's ssh config:

# /etc/ssh/sshd_config
Protocol 2
KexAlgorithms diffie-hellman-group-exchange-sha256
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512,hmac-sha2-256

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.

comment:2 by pkbarbiedoll, 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 Tim Kosse, 7 years ago

Status: newmoreinfo

In ~/.putty/session/*, do you by chance have the BugHMAC2 or BuggyMac settings set to anything other than 0?

Last edited 7 years ago by Tim Kosse (previous) (diff)

comment:4 by pkbarbiedoll, 7 years ago

Status: moreinfonew

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:5 by pkbarbiedoll, 7 years ago

Each of the sshhostkeys lines begins in rsa2@ (not sure if helpful)

comment:6 by pkbarbiedoll, 7 years ago

Here are the mac's my local system uses:

user@linux-mint ~ $ nmap --script ssh2-enum-algos -sV -p 22 rhel74server

Starting Nmap 6.40 ( http://nmap.org ) at 2017-08-10 14:42 EDT
Nmap scan report for rhel74server (170.140.203.50)
Host is up (0.0026s latency).
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.4 (protocol 2.0)
| ssh2-enum-algos: 
|   kex_algorithms (1)
|       diffie-hellman-group-exchange-sha256
|   server_host_key_algorithms (3)
|       ssh-rsa
|       rsa-sha2-512
|       rsa-sha2-256
|   encryption_algorithms (3)
|       aes256-ctr
|       aes192-ctr
|       aes128-ctr
|   mac_algorithms (2)
|       hmac-sha2-512
|       hmac-sha2-256
|   compression_algorithms (2)
|       none
|_      zlib@openssh.com

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.38 seconds
user@linux-mint ~ $ 

Last edited 7 years ago by pkbarbiedoll (previous) (diff)

comment:7 by pkbarbiedoll, 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 Tim Kosse, 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 pkbarbiedoll, 7 years ago

Any known workaround? I cannot add back the insecure SHA-1 or MD5 Ciphers/MACs.

comment:10 by pkbarbiedoll, 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 Tim Kosse, 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 pkbarbiedoll, 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.

Last edited 7 years ago by pkbarbiedoll (previous) (diff)

comment:13 by Tim Kosse, 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 pkbarbiedoll, 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.

Last edited 7 years ago by pkbarbiedoll (previous) (diff)

comment:15 by Tim Kosse, 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 pkbarbiedoll, 7 years ago

#8520

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:19 by Tim Kosse, 7 years ago

Resolution: fixed
Status: newclosed

Should be fixed in FileZilla 3.27.1

comment:20 by pkbarbiedoll, 7 years ago

Confirmed fixed. Thanks.

Note: See TracTickets for help on using tickets.