How to fix Connection closed in SSH

Test that regular SSH works before troubleshooting SFTP:

ssh -v user@host

If SSH connection succeeds but SFTP fails, the issue is likely SFTP-specific (missing subsystem). If SSH also fails, troubleshoot SSH connectivity first.

Use the -v flag with SFTP to see detailed diagnostic information:

sftp -v user@host

For even more detail:

sftp -vv user@host

Watch for error messages about subsystem requests or authentication failures. Verbose output often shows exactly where the connection closes and why.

On the remote server, check that the SFTP subsystem is properly configured in sshd_config:

grep -i subsystem /etc/ssh/sshd_config

You should see a line like:

Subsystem sftp /usr/lib/openssh/sftp-server

On Windows OpenSSH, check:

Get-Content 'C:\ProgramData\ssh\sshd_config' | Select-String -Pattern 'Subsystem'

Should show:

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

If the subsystem line is commented out or missing, uncomment it or add it.

Check that the SFTP server binary actually exists at the path specified in sshd_config:

Linux/Unix:

ls -la /usr/lib/openssh/sftp-server

or

ls -la /usr/libexec/sftp-server

Windows:

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

The binary must exist and be executable. If it's missing, you may need to reinstall OpenSSH or correct the path in sshd_config.

After modifying sshd_config, reload or restart the SSH service:

Linux/Unix:

sudo systemctl reload ssh
# or
sudo systemctl restart ssh

Windows (PowerShell as Admin):

Restart-Service -Name sshd -Force

A reload applies configuration without dropping existing connections. A restart is more thorough if reload doesn't work.

Examine the SSH daemon logs to see what happens when SFTP connection fails:

Linux/Unix:

sudo tail -f /var/log/auth.log
# or
sudo journalctl -u ssh -n 50
sudo journalctl -u sshd -n 50

Windows (PowerShell as Admin):

Get-EventLog -LogName System | Where-Object { $_.Source -like '*ssh*' } | Select-Object -Last 20

Look for errors mentioning "subsystem" or "sftp". Messages like "subsystem request for sftp failed" confirm the subsystem is missing or not found.

Some SFTP configurations require users to have a valid login shell. Check the user's shell:

grep ^username: /etc/passwd

The last field should be a valid shell (e.g., /bin/bash, /bin/sh). If it's /sbin/nologin or /bin/false, SFTP may fail.

You can also configure SFTP to work even with nologin shells by using chroot or ForceCommand in sshd_config:

Match User sftpuser
  ForceCommand internal-sftp
  ChrootDirectory /home/sftpuser
  PermitTTY no
  AllowAgentForwarding no
  AllowTcpForwarding no
EndMatch

Try connecting with a different SFTP client to isolate whether the issue is client-specific:

Command line:

sftp user@host

Alternative clients:
- FileZilla (GUI)
- WinSCP (Windows GUI)
- Cyberduck (GUI)
- lftp (command line)

lftp -u user sftp://host

If the issue persists across multiple clients, it's a server problem. If only one client fails, check client-specific settings.

If connections drop after inactivity, adjust timeout settings:

Client-side (~/.ssh/config):

Host *
  ServerAliveInterval 60
  ServerAliveCountMax 5

Or on the command line:

sftp -o ServerAliveInterval=60 user@host

Server-side (/etc/ssh/sshd_config):

ClientAliveInterval 300
ClientAliveCountMax 3

These settings keep the connection alive by sending periodic keepalive packets, preventing idle timeout.