How to fix banner exchange: Connection to hostname port 22: Software caused connection abort in SSH

First, gather detailed connection information by running SSH with maximum verbosity:

ssh -vvv user@hostname

This will show exactly where in the banner exchange the connection is terminated. Look for lines like:
- debug1: Local version string: OpenSSH_... - your client sent its version
- debug1: Remote protocol version ... - server sent its version back
- If you see the first line but not the second, the server isn't responding

Save the full output—it will help diagnose the exact cause.

From a Linux/macOS terminal, confirm the SSH port is actually listening:

# From your local machine, check if port 22 is open
nc -zv hostname 22
# or
telnet hostname 22

If this times out or is refused, the server isn't accepting connections. On the remote server, verify SSH is running:

sudo systemctl status ssh    # Debian/Ubuntu
sudo systemctl status sshd   # RHEL/CentOS
ps aux | grep sshd

If SSH isn't running, start it:

sudo systemctl start ssh     # Debian/Ubuntu
sudo systemctl start sshd    # RHEL/CentOS

The most common cause of "software caused connection abort" is your local firewall terminating the connection. Try disabling it temporarily:

Windows (as Administrator):

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled $false

Then attempt the connection. If it works, re-enable and add an SSH exception:

netsh advfirewall firewall add rule name="SSH" dir=out action=allow protocol=TCP remoteport=22
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled $true

Linux (UFW):

sudo ufw disable
# Test connection
ssh user@hostname
sudo ufw enable
# Add SSH rule
sudo ufw allow 22/tcp

Linux (firewalld):

sudo firewall-cmd --permanent --add-port=22/tcp
sudo firewall-cmd --reload

If firewall isn't the issue, third-party antivirus or security software may be intercepting SSH traffic. Temporarily disable (not just exit—fully disable) any of:
- Norton, McAfee, Kaspersky, ESET, Avast
- Third-party VPN clients
- Network monitoring tools
- Corporate proxy software

After disabling, retry the SSH connection. If it works, add SSH to the exception/whitelist list for that software.

Recommendation: On development machines, use only the built-in firewall and antivirus (Windows Defender, macOS Security, Linux ufw/firewalld).

If your network has high latency or the server is slow during startup, increase the timeout:

ssh -o ConnectTimeout=60 user@hostname

This gives the banner exchange 60 seconds instead of the default 30. To make this permanent, add to ~/.ssh/config:

Host hostname
  ConnectTimeout 60

If you have server access, restart SSH and check for configuration issues:

# Check for syntax errors
sudo sshd -t

# If errors appear, fix them in /etc/ssh/sshd_config
# Common issues:
# - MaxStartups too low (default 10:30:100 may be too restrictive)
# - UseDNS yes causing long reverse lookups

# Restart SSH
sudo systemctl restart ssh

# Check if port is listening
netstat -tuln | grep :22
# or
ss -tuln | grep :22

If you see DNS-related delays in logs, add to /etc/ssh/sshd_config:

UseDNS no

Review the SSH server logs for errors during connection attempts:

# Recent connections and errors
tail -50 /var/log/auth.log        # Debian/Ubuntu
tail -50 /var/log/secure          # RHEL/CentOS
journalctl -u sshd -n 50          # systemd journal

# Look for patterns indicating why connection was dropped

Common issues in logs:
- Received disconnect from X.X.X.X port YYYYY [SSH2_MSG_DISCONNECT] - Server terminated the connection
- Connection closed by authenticating user before authentication - Banner exchange issue
- Timeout before authentication - Connection timeout during handshake