How to fix subsystem request failed on channel 0 in SSH

SSHINTERMEDIATEMEDIUMUpdated May 28, 2026· 556 views

The SSH daemon failed to launch the requested subsystem (usually SFTP). Common causes: wrong subsystem path in sshd_config, a missing sftp-server binary, or chroot misconfiguration.

Quick fix

Fixes subsystem request failed on channel 0

C:\ProgramData\ssh\sshd_config
  1. Verify SSH daemon configuration
  2. Verify the subsystem binary exists
  3. Verify the subsystem path matches a chroot jail
  4. Remove duplicate Subsystem entries
ssh — error
C:\ProgramData\ssh\sshd_config
subsystem request failed on channel 0

What this error means

The SSH subsystem error means the server-side SSH daemon received your request to use a specific subsystem (typically SFTP for file transfers or internal-sftp for chroot), but failed to launch it. The SSH service intentionally doesn't reveal the exact failure reason to the client for security purposes, so the generic 'subsystem request failed on channel 0' message appears instead. The 'channel 0' designation refers to the SSH protocol's first communication channel for your session.

Typical symptoms

  • SCP or SFTP file transfers fail immediately with 'subsystem request failed on channel 0'
  • PowerShell remoting over SSH fails to establish a session
  • Connection closes after SSH authentication succeeds
  • Works with SSH shell access but fails with subsystem-based tools
  • Error message followed by 'scp: Connection closed' or similar

Common causes

  1. The subsystem binary path in sshd_config is incorrect or the file doesn't exist
  2. On Linux/Unix: sftp-server binary path is wrong (e.g., /usr/libexec/openssh/sftp-server doesn't exist on Debian/Ubuntu, which use /usr/lib/openssh/sftp-server)
  3. On Windows: sftp-server.exe is missing from C:\Windows\System32\OpenSSH\
  4. Using a fixed sftp-server path in a chroot environment where the binary isn't available inside the jail (internal-sftp is required)
  5. Duplicate 'Subsystem' entries in sshd_config prevent the daemon from starting
  6. SSH daemon doesn't have permission to execute the subsystem binary
  7. User account profile is missing or corrupted (especially on Windows)
  8. Firewall or antivirus software is blocking the sftp-server executable

How to fix "subsystem request failed on channel 0"

1Verify SSH daemon configuration

First, check your sshd_config file for syntax errors and confirm the Subsystem directive is present and uncommented.

On Windows:

bash
C:\ProgramData\ssh\sshd_config

On Linux/macOS:

bash
/etc/ssh/sshd_config

Look for the line:

bash
Subsystem sftp /usr/libexec/openssh/sftp-server

or on Windows:

bash
Subsystem sftp sftp-server.exe

To validate the configuration syntax:

bash
# Linux/macOS
sudo sshd -t

# Windows (PowerShell as admin)
& "C:\Windows\System32\OpenSSH\sshd.exe" -t
2Verify the subsystem binary exists

Confirm the sftp-server binary is present at the path specified in sshd_config. The path differs between distributions.

On Linux/macOS:

bash
# Red Hat / Fedora / macOS
ls -la /usr/libexec/openssh/sftp-server

# Debian / Ubuntu
ls -la /usr/lib/openssh/sftp-server

Update the Subsystem sftp line in sshd_config to match the path that actually exists.

On Windows (PowerShell as admin):

powershell
Test-Path C:\Windows\System32\OpenSSH\sftp-server.exe

If the binary is missing, reinstall or repair OpenSSH on your system.

3Verify the subsystem path matches a chroot jail

If you're using ChrootDirectory with SFTP, a fixed sftp-server path is one of the most common causes of this error: the external binary is looked up *inside* the chroot, where it (and its shared libraries) usually don't exist. Use the built-in internal-sftp instead, which runs in-process and needs no external binary.

In sshd_config:

bash
Match User sftpuser
    ChrootDirectory /var/sftp
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

Note: a Match block has no terminating keyword. It applies to every directive that follows until the next Match line or the end of the file, so place global directives *before* any Match blocks. Indentation is cosmetic.

Validate and reload after editing:

bash
sudo sshd -t && sudo systemctl reload sshd
4Remove duplicate Subsystem entries

Two Subsystem sftp lines (often left behind by a package upgrade or a hand-edited config) prevent sshd from starting at all, which surfaces to the client as a subsystem request failure.

On Linux/macOS:

bash
grep -n '^[[:space:]]*Subsystem' /etc/ssh/sshd_config

Keep exactly one Subsystem sftp ... line, delete the rest, and ensure there is no trailing whitespace after it. Then validate:

bash
sudo sshd -t
5Check permissions on the subsystem binary

Ensure the SSH daemon can execute the subsystem binary.

On Linux/macOS:

bash
# Check file exists and is executable
ls -la /usr/libexec/openssh/sftp-server

# If not executable, restore the default mode
sudo chmod 755 /usr/libexec/openssh/sftp-server

On SELinux systems, also confirm the file's security context (see Advanced notes).

6Restart the SSH daemon

After making any changes to sshd_config, restart the SSH daemon for changes to take effect.

On Linux/macOS:

bash
sudo systemctl restart sshd
# or, on systems without systemd
sudo service ssh restart

On Windows (PowerShell as admin):

powershell
Restart-Service -Name sshd -Force
7Test with verbose output

Use verbose SSH flags to see detailed client-side messages during the subsystem request.

bash
# SFTP verbose test
sftp -vvv username@hostname

# SCP verbose test
scp -vvv file.txt username@hostname:/tmp/

The client only sees the generic failure, so for the real reason check the server log while you reconnect:

bash
# On the server, in another terminal
sudo journalctl -u sshd -f
# or
sudo tail -f /var/log/auth.log

The server log reveals whether the subsystem path is wrong, permission was denied, or the binary is missing.

8Fix Windows user profile and antivirus issues

On Windows, a missing user profile or security software blocking sftp-server.exe can cause this error.

powershell
# Check if the user's profile directory exists
Test-Path C:\Users\username

# Verify the sshd service start type and status
Get-Service sshd | Select-Object StartType, Status

If the profile is missing, log in as that user once locally or via RDP to initialize it. To isolate whether the problem is user-specific, try connecting with a different local account.

If antivirus is suspected, add an exclusion for the OpenSSH directory rather than disabling protection broadly:

bash
C:\Windows\System32\OpenSSH\sftp-server.exe
9Reinstall OpenSSH as a last resort

If the above steps don't resolve the issue, reinstall the OpenSSH feature to restore the binaries and default config.

On Windows (PowerShell as admin):

powershell
# Reinstall the server capability
Remove-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

# Start and enable the service
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

On Linux (Ubuntu/Debian) — back up your config first, since reinstalling can reset it:

bash
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo apt install --reinstall openssh-server
sudo systemctl restart sshd

Advanced notes

On Linux systems with SELinux enabled, ensure the sftp-server binary has the correct SELinux context. Run ls -Z /usr/libexec/openssh/sftp-server and confirm it has a context like system_u:object_r:ssh_exec_t:s0. If not, restore the default with sudo restorecon -v /usr/libexec/openssh/sftp-server.

Remember that an sshd Match block has no closing keyword (there is no EndMatch). Directives after a Match line apply only when its conditions match, and continue until the next Match or end of file. Putting EndMatch in the file makes sshd -t fail with a bad configuration option and prevents the daemon from reloading.

For Teleport SSH proxy users, this error often means the agent needs restarting or re-registering with the cluster. Check agent logs with journalctl -u teleport for details.

Some managed SSH services (like AWS Systems Manager Session Manager) use proprietary subsystems. A 'subsystem request failed' error there indicates a different root cause and requires checking service-specific documentation.

Frequently asked questions

What does "subsystem request failed on channel 0" mean?
The SSH subsystem error means the server-side SSH daemon received your request to use a specific subsystem (typically SFTP for file transfers or internal-sftp for chroot), but failed to launch it. The SSH service intentionally doesn't reveal the exact failure reason to the client for security purposes, so the generic 'subsystem request failed on channel 0' message appears instead. The 'channel 0' designation refers to the SSH protocol's first communication channel for your session.
How do I fix "subsystem request failed on channel 0"?
The SSH daemon failed to launch the requested subsystem (usually SFTP). Common causes: wrong subsystem path in sshd_config, a missing sftp-server binary, or chroot misconfiguration.
What causes "subsystem request failed on channel 0"?
The subsystem binary path in sshd_config is incorrect or the file doesn't exist On Linux/Unix: sftp-server binary path is wrong (e.g., /usr/libexec/openssh/sftp-server doesn't exist on Debian/Ubuntu, which use /usr/lib/openssh/sftp-server) On Windows: sftp-server.exe is missing from C:\Windows\System32\OpenSSH\
Is the "subsystem request failed on channel 0" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading