Subsystem Request Failed on Channel 0: Diagnose SFTP Before Editing SSH
“subsystem request failed on channel 0” means the SSH connection reached a subsystem request but the requested service did not start successfully. Prove which client/protocol requested it, then trace the server from global Subsystem definition through the affected account's Match/ForceCommand/chroot context. With modern OpenSSH scp, remember that SFTP is the default transfer protocol.
subsystem request failed on channel 0, often followed by a closed connection.Plain SSH may connect or authenticate, but SFTP—or an SCP transfer using SFTP—does not start.You administer the SSH server and want to identify the failing subsystem before changing server configuration.sftp user@server failsReproduce verbosely, then inspect the server's effective SFTP Subsystem configuration.scp failsModern OpenSSH SCP uses SFTP by default. Prove whether this is an SFTP-subsystem compatibility/configuration failure before changing SSH.Reproduce with verbose output. For SFTP:
sftp -vvv user@serverFor SCP, use verbose mode on the same transfer:
scp -v file.txt user@server:/path/Verify: Capture the lines immediately before the failure and confirm whether the client requested the SFTP subsystem. Do not infer the server-side cause from the channel number alone.
Why SFTP—and modern SCP—can produce this error
OpenSSH's Subsystem directive configures an external command or an internal service that is executed when a subsystem is requested. For SFTP, OpenSSH supports both an external sftp-server program and the in-process internal-sftp server.
OpenSSH changed scp to use SFTP for transfers by default in OpenSSH 9.0. The -O option selects the legacy SCP protocol. That means an scp command can expose a broken or unavailable SFTP subsystem even though the user never typed sftp.
Fix path #1 — inspect the effective SFTP subsystem before editing it
Inspect the server configuration and included files:
grep -RniE '^[[:space:]]*(Include|Subsystem|Match|ForceCommand|ChrootDirectory)[[:space:]]' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/nullLook for a missing/commented SFTP subsystem, an invalid external target, and account-specific rules that change what happens after authentication. Grepping files shows candidate directives, not necessarily the effective behavior for a particular user/address when Include and Match criteria are involved. Where supported, inspect OpenSSH's effective configuration using the appropriate connection criteria and correlate it with the server log for the failing request.
Verify: If configuration uses an external sftp-server, prove the target is usable in the execution context that applies to this account. In a chroot design, host-side path existence alone may not prove the external program/runtime is available inside the jail. If it uses internal-sftp, do not invent an external path just because another guide uses one.
Fix path #2 — separate missing configuration from execution or account failures
If no valid SFTP subsystem is configured and SFTP is intended to be available, restore the configuration supported by your OS, distribution, or hosting platform. If a valid directive already exists, stop treating the error as proof that the line is missing: inspect server logs around the request and check applicable Match, ForceCommand, chroot, account, and platform-specific restrictions.
sftp-server paths vary by platform, while internal-sftp has different operational characteristics and is commonly useful with chroot configurations. Change only what your server evidence supports.Verify: The configured SFTP implementation is available on this host and the affected account reaches it without a more specific server-side error.
If only SCP fails: use legacy SCP as a diagnostic clue, not the default fix
On OpenSSH versions where SCP uses SFTP by default, a successful legacy-protocol test can help isolate the problem:
scp -O file.txt user@server:/path/If normal scp fails at the SFTP subsystem request while scp -O works, the useful conclusion is narrow: the legacy SCP path can complete while the default SFTP-based transfer path cannot. It does not identify the SFTP root cause, prove legacy SCP is safer/better, or guarantee -O will be permitted by another account/server policy.
Verify: Compare verbose output from normal SCP and the diagnostic legacy-protocol test. Repair the intended SFTP service when modern SCP/SFTP support is required, then retest normal scp without -O.
Validate sshd before reload
If you edited SSH configuration, keep your current administrative session open and validate the complete configuration first:
sudo sshd -tIf validation reports an error, do not reload. If it exits cleanly, use the supported reload mechanism for your OS/control panel while keeping the known-good administrative session open. Test the exact affected account/protocol in a separate fresh connection before closing that session.
Verify: The exact affected account now starts the intended SFTP/default-SCP path, and the original subsystem-request error is gone. If the server returns a new concrete chroot, permission, authentication or file-operation error, stop diagnosing subsystem startup and follow that newer failure class.
What not to do first
sftp-server path into every server.Do not switch blindly between external sftp-server and internal-sftp.Do not add duplicate Subsystem sftp directives without inspecting the effective configuration.Do not remove Match, ForceCommand, or ChrootDirectory merely to make a transfer start.Do not treat scp -O as proof that legacy SCP should become the permanent workaround.Do not reload sshd after an edit until sshd -t succeeds, and do not close your only working admin session before a new connection is verified.Do not call grep output the effective account behavior when Match/Include criteria can alter the post-authentication path.Do not treat host-side existence of an external sftp-server as proof it is usable inside an applicable chroot/runtime context.Do not interpret successful scp -O as proof that legacy SCP should replace SFTP permanently.Do not keep diagnosing subsystem startup after the connection progresses and produces a more specific chroot, permission, authentication or file-operation error.Still failing? Capture this evidence
sftp -vvv or scp -v, with secrets and sensitive host details redactedclient and server OpenSSH versionsserver OS/distribution or hosting/control-panel environmentthe effective Subsystem, Match, ForceCommand and ChrootDirectory configuration for the accountwhether an external configured sftp-server path existsserver-side SSH/SFTP log entries at the same timestampthe result of sshd -tfor SCP-only failures, whether a controlled scp -O test changes the resulteffective sshd settings for the affected user/host/address context when Match/Include criteria applywhether an external subsystem target is actually usable inside the applicable chroot/runtime contextwhether normal SCP succeeds without -O after SFTP repairthe first different server/client error if subsystem startup begins succeedingReferences
Still stuck? Ask the community
Share the redacted exact command, verbose failure boundary, OpenSSH versions and relevant Subsystem/Match configuration.
Loading community discussion…