If SFTP clients that used to connect fine suddenly fail after updating FileZilla Pro Enterprise Server — often with a log entry mentioning an identification string not terminated by CRLF — it’s because FZPES’s SFTP implementation became stricter about protocol compliance starting with version 1.12.0. A compatibility setting exists to relax that specific requirement for legacy or non-compliant clients.
Why this started happening
Starting with FZPES 1.12.0-rc2, SFTP support moved to fzssh, a newer SSH library. The SSH protocol specification requires that a client’s identification string be terminated with CRLF (\r\n). fzssh enforces this correctly; the SFTP implementation used before it was more lenient and accepted identification strings that weren’t properly terminated.
The practical effect: any SFTP client that doesn’t send a fully compliant, CRLF-terminated identification string — typically older or no-longer-maintained client software — can fail to connect after you update past this point, even if that same client connected without issue on your previous FZPES version.
Who this affects
- Anyone updating an existing FZPES installation from a version released before 1.12.0-rc2 (2025-11-14) to 1.12.0 or later, with legacy or unmaintained SFTP client software in the mix.
- Anyone connecting older or unmaintained SFTP clients — including scripts and automated integrations — to a fresh FZPES installation for the first time. This is particularly relevant if you’re migrating from the free FileZilla Server 0.9.x, which never supported SFTP at all: for that audience, FZPES’s SFTP is new functionality, so any strict, non-compliant client in your environment will hit this the first time it connects, not as a result of an update.
What customers actually hit
Reports on our customer forum point to a specific, recurring cause: many non-compliant clients are Java-based enterprise integrations — SAP and Oracle-adjacent connectors came up more than once — built on the jsch SSH library. Older versions of jsch had a bug that sent an improperly terminated identification string; it was fixed upstream years ago, but plenty of enterprise software still ships whatever version it originally bundled and doesn’t get updated on a fast cycle. Older Cisco network devices have shown the same non-compliant behavior for the same underlying reason: an outdated SSH stack that isn’t getting patched.
Before this override existed, customers with large enterprise partners on slow update cycles were weighing downgrading their FZPES installation just to keep a connection alive while they waited for the partner to fix their client. That’s exactly the situation this setting is meant to unblock.
How to fix it: the compatibility override
In the Administration Interface, open the server’s Behavior tab and enable Allow client identification string not terminated by CRLF. Full steps are covered in How to Manage Behavior Settings.
Use this with caution: it relaxes protocol compliance specifically for clients that don’t meet the SSH specification. Monitor your logs after enabling it, and treat it as a bridge rather than a permanent fix — encourage the affected clients to update to compliant software when that’s a realistic option for you.
Questions about a specific connection failure? Visit the customer forum or contact support.