How to fix Unable to negotiate with hostname port 22: no matching key exchange method found. in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026· 246 views

This error occurs when your SSH client and server cannot agree on a compatible key exchange algorithm. Older servers may only support deprecated algorithms that modern SSH clients disable by default for security.

Quick fix

Fixes Unable to negotiate with hostname port 22: no matching key exchange method found.

ssh -vvv user@server 2>&1 | grep -A 5 "kex algorithm"
  1. Check what algorithms the server supports
  2. Query your SSH client's available algorithms
  3. Connect using a temporary command-line override
  4. Make the fix permanent in your SSH config
ssh — error
ssh -vvv user@server 2>&1 | grep -A 5 "kex algorithm"
Unable to negotiate with hostname port 22: no matching key exchange method found.

What this error means

When SSH negotiates a connection, both the client and server exchange lists of supported cryptographic algorithms. This includes key exchange methods (KEX), host key types, ciphers, and MAC algorithms. For a successful connection, there must be at least one mutually-supported choice for each parameter. If the client and server are unable to agree on a mutual set of key exchange methods, the connection fails with "no matching key exchange method found." This commonly occurs when connecting to legacy systems (older network equipment, servers running very old SSH implementations) that only support weak algorithms like diffie-hellman-group1-sha1.

Typical symptoms

  • SSH command fails immediately without prompting for a password
  • Connection drops with the KEX negotiation error message
  • Error message shows the server's available algorithms (e.g., 'Their offer: diffie-hellman-group1-sha1')
  • Can ping the server but cannot SSH into it
  • Works from some machines but not others (likely due to different OpenSSH versions)

Common causes

  1. Server only supports deprecated key exchange algorithms that your SSH client has disabled
  2. Version mismatch between client and server SSH implementations
  3. Outdated server (often legacy network equipment, routers, switches) with weak cryptography
  4. Client OpenSSH recently upgraded and removed support for insecure KEX methods
  5. Connecting to a legacy system that hasn't been updated in many years

How to fix "Unable to negotiate with hostname port 22: no matching key exchange method found."

1Check what algorithms the server supports

First, identify which key exchange algorithms the server is offering. Run SSH with verbose mode to see the negotiation:

bash
ssh -vvv user@server 2>&1 | grep -A 5 "kex algorithm"

Look for the line "Their offer:" which shows the server's available algorithms. Note the exact algorithm name (e.g., diffie-hellman-group1-sha1).

2Query your SSH client's available algorithms

Check what algorithms your local SSH installation supports:

bash
ssh -Q kex    # Key Exchange Algorithms
ssh -Q key    # Public key types
ssh -Q cipher # Ciphers
ssh -Q mac    # MAC types

Compare the server's offers with your client's supported list to find a common algorithm.

3Connect using a temporary command-line override

Once you've identified a compatible algorithm from the server's offer, connect with that algorithm explicitly:

bash
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@server

Note the + prefix — this appends the deprecated algorithm to the default list rather than replacing them entirely.

If you get a second error about "no matching host key type found," also add:

bash
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-rsa user@server
4Make the fix permanent in your SSH config

For hosts you connect to regularly, add a permanent entry to ~/.ssh/config:

bash
Host oldserver
    Hostname 192.168.1.100
    KexAlgorithms +diffie-hellman-group1-sha1
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedKeyTypes +ssh-rsa

Replace oldserver with a label for the host, 192.168.1.100 with the actual IP/hostname. The + prefix means these algorithms are added to the default list.

For global defaults that apply to all hosts (not recommended), edit /etc/ssh/ssh_config (system-wide) with the same lines.

5Upgrade the remote server

The best long-term solution is to update the server's SSH implementation. If you control the server, upgrade OpenSSH:

On Linux/Unix:

bash
# For apt (Debian/Ubuntu)
sudo apt update && sudo apt upgrade openssh-server

# For yum (RHEL/CentOS)
sudo yum update openssh-server

For network equipment (switches, routers, firewalls), check the vendor's security patches and firmware updates.

After upgrading, test the connection without the -oKexAlgorithms override.

Advanced notes

Security Considerations: Enabling deprecated algorithms like diffie-hellman-group1-sha1 weakens security. DH group 1 only uses 768-bit keys, which modern cryptanalysis can break. Use these algorithms only as a temporary workaround for legacy systems you're actively trying to upgrade.

Why Modern OpenSSH Disables These: Newer versions of OpenSSH (7.0+) removed support for weak algorithms by default to prevent downgrade attacks. Even though your client may support them internally, you must explicitly re-enable them, which is an intentional friction point to discourage their use.

For Server Administrators: If you manage a server, edit /etc/ssh/sshd_config to add algorithms only if necessary. Restart with sudo systemctl restart sshd. The same security cautions apply — upgrade when possible.

SSH Protocol Details: SSH negotiation happens during the initial handshake before authentication. Both sides must have at least one algorithm in common for each category. The client always proposes first, and the server picks the first match from its preferred list.

Frequently asked questions

What does "Unable to negotiate with hostname port 22: no matching key exchange me" mean?
When SSH negotiates a connection, both the client and server exchange lists of supported cryptographic algorithms. This includes key exchange methods (KEX), host key types, ciphers, and MAC algorithms. For a successful connection, there must be at least one mutually-supported choice for each parameter.
How do I fix "Unable to negotiate with hostname port 22: no matching key exchange me"?
This error occurs when your SSH client and server cannot agree on a compatible key exchange algorithm. Older servers may only support deprecated algorithms that modern SSH clients disable by default for security.
What causes "Unable to negotiate with hostname port 22: no matching key exchange me"?
Server only supports deprecated key exchange algorithms that your SSH client has disabled Version mismatch between client and server SSH implementations Outdated server (often legacy network equipment, routers, switches) with weak cryptography
Is the "Unable to negotiate with hostname port 22: no matching key exchange me" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading