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

SSHINTERMEDIATEHIGH

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

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

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

What this error means

Typical symptoms

Common causes

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

Advanced notes

Related errors

Official resources & further reading