Articles

Fix SSH Exchange Identification Connection Closed Error (2026)

April 6, 2026 4 min read

The Exchange identification step in SSH is failing because the client and server can’t agree on which cryptographic algorithms (like key exchange methods, ciphers, and MACs) they both support. This breakdown happens before any actual authentication or data transfer, leaving you with a Connection closed error.

Here’s what’s likely happening and how to fix it:

1. Mismatched KexAlgorithms: The client and server don’t have any common key exchange algorithms. This is the most frequent culprit.

  • Diagnosis: On the client, run ssh -vvv user@host. Look for a line like debug2: kex_parse_kexinit: no common kex algorithm.
  • Fix: Edit the server’s sshd_config (usually /etc/ssh/sshd_config). Find or add the KexAlgorithms line. Ensure it includes algorithms known to be supported by both your client and server. A good starting point for compatibility might be:
    KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    Restart the SSH service: sudo systemctl restart sshd.
  • Why it works: This explicitly tells the server which key exchange methods it can use, forcing it to negotiate one from this list that the client also supports.

2. Mismatched Ciphers: Similar to KexAlgorithms, the client and server don’t share any common encryption algorithms for the actual data stream.

  • Diagnosis: ssh -vvv user@host. Look for debug2: kex_parse_kexinit: no common cipher.
  • Fix: In sshd_config, edit or add the Ciphers line. Include widely supported ciphers:
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc
    Restart sshd.
  • Why it works: This ensures the server offers encryption algorithms that the client understands, allowing the connection to proceed securely.

3. Mismatched MACs (Message Authentication Codes): The client and server can’t agree on algorithms to verify the integrity of data packets.

  • Diagnosis: ssh -vvv user@host. Look for debug2: kex_parse_kexinit: no common mac.
  • Fix: In sshd_config, edit or add the MACs line:
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
    Restart sshd.
  • Why it works: This provides a common method for both ends to ensure data hasn’t been tampered with during transit.

4. Outdated SSH Client or Server: An older version of SSH on either end might not support newer, more secure algorithms that the other end is trying to use.

  • Diagnosis: Check the SSH versions: ssh -V on the client, and sshd -V or ssh -V on the server. Compare these to current stable releases.
  • Fix: Update your SSH client and server software to the latest stable versions. For example, on Debian/Ubuntu: sudo apt update && sudo apt upgrade openssh-client openssh-server. On CentOS/RHEL: sudo yum update openssh-clients openssh-server.
  • Why it works: Newer versions inherently support a broader and more secure range of cryptographic primitives, increasing the chances of a successful negotiation.

5. Firewall or Network Interruption Blocking SSH Traffic: Less common for this specific error, but a firewall might be interfering with the initial handshake packets, causing them to be dropped and the connection to close prematurely.

  • Diagnosis: Use tcpdump on the client or server to capture traffic on port 22. sudo tcpdump -i eth0 port 22 -nn (replace eth0 with your interface). Look for SYN packets going out but no SYN-ACK coming back, or unexpected RST packets.
  • Fix: Ensure port 22 (or your custom SSH port) is open in any firewalls (e.g., sudo ufw allow ssh or sudo firewall-cmd --permanent --add-service=ssh && sudo firewall-cmd --reload). Check cloud provider security groups or network ACLs.
  • Why it works: This guarantees that the initial SSH negotiation packets can actually reach their destination and receive responses.

6. UsePrivilegeSeparation Setting: In rare cases, a misconfiguration related to privilege separation in sshd_config can cause issues during the early stages of the connection.

  • Diagnosis: Check sshd_config for UsePrivilegeSeparation.
  • Fix: Try setting UsePrivilegeSeparation yes in sshd_config. If it was already yes and causing issues, try UsePrivilegeSeparation no temporarily to diagnose, but yes is the recommended secure setting. Restart sshd.
  • Why it works: Privilege separation drops root privileges early in the process. If the mechanism for this is broken or incompatible with the system setup, it can halt the connection before it even starts negotiating.

7. Client-Side ssh_config Overrides: Your local ~/.ssh/config file might have settings that conflict with the server’s capabilities.

  • Diagnosis: Run ssh -vvv -F /dev/null user@host to bypass your local config. If this works, your ~/.ssh/config is the problem.
  • Fix: Examine your ~/.ssh/config for explicit KexAlgorithms, Ciphers, or MACs directives that might be too restrictive or outdated. Remove or adjust them to allow negotiation.
  • Why it works: This removes any client-specific, potentially problematic, algorithm preferences, allowing the client to discover what the server supports.

Once you’ve resolved the Exchange identification error, you’ll likely encounter the next step in the SSH process, which is usually authentication (Authentication that can take another 1000 words).

More Deep Dives in Ssh

Want structured learning?

Take the full Ssh course →