How to fix Couldn't read packet: Connection reset by peer in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 331 views

This error occurs when an SFTP connection is abruptly terminated by the server during transfer. Common causes include chroot directory permission issues, IP blocking from failed attempts, network timeouts, firewall restrictions, or key exchange algorithm mismatches.

Quick fix

Fixes Couldn't read packet: Connection reset by peer

sftp -vvv user@hostname
  1. Enable verbose debugging to gather detailed connection information
  2. Verify basic network connectivity and firewall rules
  3. Check for IP blocking or fail2ban rules (if server-side access available)
  4. Fix chroot directory permissions (if using SFTP with chroot jail)
ssh — error
sftp -vvv user@hostname
Couldn't read packet: Connection reset by peer

What this error means

The "Couldn't read packet: Connection reset by peer" error indicates that the SFTP client was unable to read incoming data because the remote SSH server forcefully closed the TCP connection. Unlike a graceful disconnect, "reset by peer" means the server terminated the connection immediately without proper shutdown handshaking. This typically happens during the SFTP session phase—after SSH authentication succeeds but during file operations or subsystem initialization. The error message comes from the SFTP client layer, which sits on top of SSH, and signals that the underlying SSH connection was severed unexpectedly. The "peer" in this context is the remote SSH server, and "reset" means it sent a TCP RST packet, abruptly ending the connection. This is distinct from timeouts (no response) or other errors.

Typical symptoms

  • SFTP commands work initially but fail mid-session
  • File transfers start successfully but disconnect after a few seconds or minutes
  • Connection works once, then fails on subsequent attempts from the same IP
  • Error appears immediately after initial connection or during authentication
  • Different SFTP clients all fail with the same error from the same host
  • Server-side logs show connection termination but client never receives the data

Common causes

  1. Chroot directory has incorrect ownership or permissions (home directory must be owned by root, subdirectories by the SFTP user)
  2. Server IP blocklist or fail2ban has banned your client IP after multiple failed login attempts
  3. Firewall (UFW, iptables, firewalld) or cloud security group blocking SSH traffic on port 22 or preventing stateful connection handling
  4. Network timeout or unstable connection causing packets to be dropped by intermediate routers or firewalls
  5. Incompatible key exchange, cipher, or MAC algorithm between client and server versions
  6. Maximum concurrent connections limit reached on the SFTP server
  7. Server overload causing it to forcefully drop new connections to preserve resources
  8. SSH service crash or restart during the SFTP session

How to fix "Couldn't read packet: Connection reset by peer"

1Enable verbose debugging to gather detailed connection information

Run the SFTP client with maximum verbosity to see exactly where the connection fails. This helps identify whether the issue is during authentication, subsystem initialization, or data transfer.

bash
sftp -vvv user@hostname

Look for the last successful message before the "Couldn't read packet" error. Common failure points:
- During SSH banner exchange (network/firewall issue)
- During key exchange (algorithm mismatch)
- After SSH2_MSG_CHANNEL_OPEN_CONFIRMATION (chroot/permissions issue)
- During SFTP SSH2_FXP_INIT (server subsystem problem)

Save the output to review for the next steps:

bash
sftp -vvv user@hostname 2>&1 | tee sftp-debug.log
2Verify basic network connectivity and firewall rules

Before troubleshooting SSH configuration, confirm that the network path is open.

bash
# Test if port 22 is reachable
nc -zv hostname 22

# Or using timeout to avoid hanging
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/hostname/22'

If the connection is refused, check:
- SSH daemon is running on the server: sudo systemctl status ssh or service sshd status
- Firewall allows incoming port 22: sudo ufw status or sudo iptables -L -n
- Cloud security group or network ACL allows SSH (AWS, GCP, Azure, etc.)
- No intrusion prevention system (IDS) blocking the traffic

On the server, check SSH logs for clues:

bash
sudo tail -f /var/log/auth.log      # Linux
sudo log stream --predicate 'process == "sshd"'  # macOS
3Check for IP blocking or fail2ban rules (if server-side access available)

If you have access to the server, verify your IP is not blocked by fail2ban or other blocklists.

bash
# Check fail2ban status and banned IPs
sudo fail2ban-client status
sudo fail2ban-client status sshd

# See all banned IPs across all jails
sudo fail2ban-client banned

If your IP is banned, unban it:

bash
sudo fail2ban-client set sshd unbanip <YOUR_IP>

Also check TCP wrappers allow your IP:

bash
cat /etc/hosts.allow
cat /etc/hosts.deny

If your IP appears in hosts.deny, remove it or add it to hosts.allow with a more specific rule:

bash
sshd: <YOUR_IP>
4Fix chroot directory permissions (if using SFTP with chroot jail)

If the SFTP server uses chroot (restricts users to a home directory), the directory structure must have specific ownership for the connection to work.

Verify the structure:

bash
# Example: /home/sftpuser as home, /home/sftpuser/incoming as writable directory
ls -ld /home/sftpuser
ls -ld /home/sftpuser/incoming

Expected permissions:

bash
drwx------ root      root      /home/sftpuser        # Root owns, mode 700
drwx------ sftpuser  sftpuser  /home/sftpuser/incoming  # User owns, mode 700

Fix if incorrect:

bash
sudo chown root:root /home/sftpuser
sudo chmod 700 /home/sftpuser
sudo chown sftpuser:sftpuser /home/sftpuser/incoming
sudo chmod 700 /home/sftpuser/incoming

Check the SFTP subsystem configuration in SSH daemon config:

bash
grep -i sftp /etc/ssh/sshd_config

It should look similar to:

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

Or with chroot:

bash
Match User sftpuser
    ChrootDirectory /home/sftpuser
    AllowTcpForwarding no
    X11Forwarding no
    PermitTTY no
    Subsystem sftp internal-sftp

After changes, reload the SSH service:

bash
sudo systemctl reload ssh
5Resolve key exchange algorithm mismatches

If the client and server have incompatible cryptographic algorithms, the connection fails during key exchange.

List available algorithms on the server:

bash
ssh -Q kex
ssh -Q cipher
ssh -Q mac

Try connecting with an explicit algorithm if you know a compatible one:

bash
sftp -o KexAlgorithms=diffie-hellman-group14-sha256 user@hostname
sftp -o Ciphers=aes128-ctr user@hostname

For older servers with legacy algorithms, enable them client-side:

bash
sftp -o KexAlgorithms=diffie-hellman-group1-sha1 user@hostname

Or add to ~/.ssh/config for persistent connections:

bash
Host problematic-server
    User sftpuser
    KexAlgorithms diffie-hellman-group14-sha1
    Ciphers aes128-cbc
    HostKeyAlgorithms ssh-rsa

Note: Older algorithms have security weaknesses. Update the server if possible instead of relying on legacy settings.

6Increase timeout values and server connection limits

Network latency or server overload can cause timeouts. Increase the timeout:

bash
sftp -o ConnectTimeout=30 -o ServerAliveInterval=60 user@hostname

Or add to ~/.ssh/config:

bash
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 5
    ConnectTimeout 30

On the server, increase connection limits in /etc/ssh/sshd_config:

bash
# Increase max concurrent unauthenticated connections
MaxStartups 100:30:200

# Increase max sessions per connection
MaxSessions 10

# Increase max auth tries
MaxAuthTries 10

# Adjust keepalive
ClientAliveInterval 60
ClientAliveCountMax 5

Reload the SSH service:

bash
sudo systemctl reload ssh
7Verify the SFTP subsystem is properly configured on the server

The SFTP subsystem must be correctly configured in the SSH daemon. Check if it's enabled and accessible:

bash
grep -i "Subsystem sftp" /etc/ssh/sshd_config

You should see one of:

bash
Subsystem sftp /usr/lib/openssh/sftp-server         # Standard path
Subsystem sftp internal-sftp                        # Built-in (more secure)

Verify the binary exists and is executable:

bash
which sftp-server
# Or check common paths
ls -l /usr/lib/openssh/sftp-server
ls -l /usr/libexec/sftp-server

If the subsystem is missing, install OpenSSH server:

bash
sudo apt-get install openssh-server   # Debian/Ubuntu
sudo yum install openssh-server        # RHEL/CentOS

If still not found, check the correct path for your system and update sshd_config.

Also ensure the SSH service is restarted after any sshd_config changes:

bash
sudo systemctl restart ssh
8Check server resources and system logs for errors

Server-side resource exhaustion can cause abrupt disconnections. Check:

bash
# CPU and memory usage
top -bn1 | head -20

# Disk space
df -h

# SSH daemon status
sudo systemctl status ssh
sudo systemctl status sshd

# System logs for errors or crashes
sudo journalctl -u ssh -n 50
sudo journalctl -u sshd -n 50
sudo tail -100 /var/log/auth.log

If disk is full:

bash
sudo du -sh /* | sort -rh | head -10  # Find large directories
df -h  # Confirm free space

Clean up space and restart SSH:

bash
# Remove old logs (be careful with this)
sudo journalctl --vacuum=time:7d

sudo systemctl restart ssh

Advanced notes

Rootless Docker and SFTP: If running SSH in a rootless Docker container, ensure file permissions are correctly mapped. The container's SSH daemon must have proper access to the home directory and any chroot target.

SELinux Contexts: On SELinux-enabled systems (RHEL, CentOS), incorrect SELinux contexts can block SFTP even with correct file permissions. Check: ls -Z /home/sftpuser and verify contexts are appropriate for SSH (typically user_home_dir_t or similar).

Distro Differences: The path to sftp-server varies by distribution:
- Debian/Ubuntu: /usr/lib/openssh/sftp-server
- RHEL/CentOS: /usr/libexec/sftp-server
- Alpine: /usr/lib/ssh/sftp-server

Using `internal-sftp` (Recommended): Modern SSH daemons support internal-sftp in sshd_config, which is faster and more secure than running the external binary. Use it with chroot for better isolation:

bash
Match User sftpuser
    ChrootDirectory /home/sftpuser
    ForceCommand internal-sftp

Connection Pooling: If your application makes many concurrent SFTP connections, consider implementing connection pooling to reduce handshake overhead and lower the risk of hitting server limits.

Proxy/Jump Hosts: If connecting through an SSH jump host, the intermediate host must also support SSH protocol 2 and have a working SFTP subsystem. Test direct connectivity first before debugging through a proxy.

Frequently asked questions

What does "Couldn't read packet: Connection reset by peer" mean?
The "Couldn't read packet: Connection reset by peer" error indicates that the SFTP client was unable to read incoming data because the remote SSH server forcefully closed the TCP connection. Unlike a graceful disconnect, "reset by peer" means the server terminated the connection immediately without proper shutdown handshaking. This typically happens during the SFTP session phase—after SSH authentication succeeds but during file operations or subsystem initialization.
How do I fix "Couldn't read packet: Connection reset by peer"?
This error occurs when an SFTP connection is abruptly terminated by the server during transfer. Common causes include chroot directory permission issues, IP blocking from failed attempts, network timeouts, firewall restrictions, or key exchange algorithm mismatches.
What causes "Couldn't read packet: Connection reset by peer"?
Chroot directory has incorrect ownership or permissions (home directory must be owned by root, subdirectories by the SFTP user) Server IP blocklist or fail2ban has banned your client IP after multiple failed login attempts Firewall (UFW, iptables, firewalld) or cloud security group blocking SSH traffic on port 22 or preventing stateful connection handling
Is the "Couldn't read packet: Connection reset by peer" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading