Received Unexpected End-of-File from SFTP Server: Fix SFTP EOF Errors

Why the same SFTP EOF message can have different causes

OpenSSH's Subsystem directive maps a subsystem name such as sftp to a command. OpenSSH supports the external sftp-server program and the in-process internal-sftp server. The correct configuration depends on the server environment; there is no universal external binary path.

That distinction matters in current vendor cases. cPanel documents an EOF caused by a missing SFTP subsystem line, while Plesk documents an EOF where its environment required a different subsystem configuration. Plesk also documents access restrictions that can terminate an SFTP login. Treat those as examples of root causes—not interchangeable fixes.

Fix path #1 — SSH works but SFTP dies immediately

Inspect the configured SFTP subsystem without changing it first:

Look for a missing Subsystem sftp, an external target that is invalid for this environment, and user/group-specific Match, ForceCommand, ChrootDirectory or included configuration that changes behavior after authentication. Remember that grepping files shows configuration text; it does not by itself prove which directives are effective for this account/address context.

Where supported, use OpenSSH's effective-configuration output with the appropriate connection criteria (for example user/host/address values) to confirm the settings that actually apply. Keep the raw config and effective result together when Match or Include is involved.

Verify: If an external SFTP server is configured, prove that the target is usable in the context where it will execute. With chroot designs, a path existing in the host namespace alone may not establish that the required external program/runtime is available inside the jail. Do not copy a path from another distribution or panel merely because the error text matches.

Fix path #2 — choose the subsystem variant for this server

OpenSSH permits either an external sftp-server command or internal-sftp. For example, Debian currently packages an external path under /usr/lib/openssh/sftp-server, while cPanel's documented case uses /usr/libexec/openssh/sftp-server. Plesk has current cases where its supported resolution uses internal-sftp, and other Plesk chroot configurations where the external subsystem is required.

Verify: After deciding on a supported change, validate the entire sshd configuration before applying it. If validation fails, do not reload SSH.

Validate before reloading SSH

Keep the current administrative SSH session open while testing. Validate the configuration first:

If the command reports an error, correct that error before any reload. If it exits cleanly, use the service-management command appropriate to your distribution or hosting panel to reload sshd. Keep the existing administrative session open. From a separate connection, test both normal SSH administration (if expected for that account/context) and SFTP using the exact affected account/path before closing the known-good session.

Verify: The new connection reaches the expected authentication/session state, the affected account reaches an SFTP prompt, and the original operation no longer dies at the same stage. A successful reload alone is not proof that account-specific SFTP behavior is correct.

If the subsystem looks valid: check access, Match and chroot rules

A valid global Subsystem line does not prove a specific account can start SFTP. Inspect the effective Match, ForceCommand, chroot and panel-access state for the failing account/context. Compare with a known-good account only when both are expected to follow comparable policy; different groups or Match criteria can intentionally produce different effective configurations.

Do not remove ChrootDirectory or recursively loosen permissions as a diagnostic shortcut. Chroot ownership and writeability rules are security-sensitive.

Verify: Test the affected account and, if available, a known-good account. A per-user difference is useful evidence that the global SFTP service itself is not the only layer involved.

If SFTP starts and EOF happens later

If you reach an SFTP prompt or begin transferring files before the EOF, a missing global subsystem line is a poor fit for that symptom. Capture the client transcript and server-side SSH/SFTP logs at the timestamp of the disconnect. Also check the resource involved in the failing operation—path/permissions, storage, chroot contents, process termination, or another server-side event—rather than repeatedly rewriting the subsystem.

Verify: Reproduce one small operation and correlate its timestamp with server logs. The goal is to identify what ended the established session.

Still not fixed? Capture this evidence

References