How to fix subsystem request failed on channel 0 in SSH

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

On Windows:

C:\ProgramData\ssh\sshd_config

On Linux/macOS:

/etc/ssh/sshd_config

Look for the line:

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

or on Windows:

Subsystem sftp sftp-server.exe

To validate the configuration syntax:

# Linux/macOS
sudo sshd -t

# Windows (PowerShell as admin)
& "C:\Windows\System32\OpenSSH\sshd.exe" -t

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

On Linux/macOS:

# 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):

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

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

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:

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:

sudo sshd -t && sudo systemctl reload sshd

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:

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:

sudo sshd -t

Ensure the SSH daemon can execute the subsystem binary.

On Linux/macOS:

# 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).

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

On Linux/macOS:

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

On Windows (PowerShell as admin):

Restart-Service -Name sshd -Force

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

# 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:

# 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.

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

# 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:

C:\Windows\System32\OpenSSH\sftp-server.exe

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):

# 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:

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