When connecting to legacy network devices like switches and routers, you might encounter this puzzling scenario:

$ ssh admin@oldswitch.example.com
Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1

Yet when checking supported algorithms, it appears to be available:

$ ssh -Q kex | grep diffie-hellman-group14-sha1
diffie-hellman-group14-sha1

Modern OpenSSH clients prioritize security over backward compatibility. Even when an algorithm is technically available (listed in -Q kex), it might be disabled by default in the client's configuration.

Check your system's default KexAlgorithms:

$ ssh -G localhost | grep -i kexalgorithms
kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256

For one-time connections:

ssh -oKexAlgorithms=diffie-hellman-group14-sha1 admin@oldswitch.example.com

For frequent access to legacy devices, update your ~/.ssh/config:

Host legacy-*
    KexAlgorithms +diffie-hellman-group14-sha1
    HostkeyAlgorithms +ssh-rsa
    Ciphers +aes128-cbc
    MACs +hmac-sha1

Host oldswitch.example.com
    HostName 192.168.1.1
    User admin
    Include legacy-*

To modify defaults for all users on a system:

# /etc/ssh/ssh_config or /etc/ssh/ssh_config.d/50-legacy.conf
Host *
    KexAlgorithms curve25519-sha256,diffie-hellman-group14-sha1
    HostKeyAlgorithms ssh-ed25519,ssh-rsa

While enabling older algorithms makes connections work, understand the risks:

• SHA-1 has known cryptographic weaknesses
• These algorithms may be removed in future OpenSSH versions
• Consider upgrading network device firmware if possible

The best practice is to scope legacy algorithm usage only to necessary devices rather than enabling them globally.

---

When dealing with legacy network equipment like Cisco switches, you might encounter this puzzling SSH behavior:

$ ssh remotehost
Unable to negotiate with 1.2.3.4 port 22: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1

First, let's check what key exchange (KEX) methods your OpenSSH client actually supports:

$ ssh -Q kex | grep diffie-hellman
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256

Modern OpenSSH versions (7.0+) disable weak algorithms by default, even if they're technically available. The client and server go through this negotiation process:

1. Client sends its supported KEX methods (filtered by security policy)
2. Server responds with its supported methods
3. If no overlap, connection fails

Option 1: Temporary Workaround

ssh -oKexAlgorithms=diffie-hellman-group14-sha1 user@remotehost

Option 2: Permanent Configuration

Add to ~/.ssh/config:

Host legacy-switch
    HostName remotehost
    User admin
    KexAlgorithms +diffie-hellman-group14-sha1
    Ciphers +aes128-cbc
    MACs +hmac-sha1

While these solutions work, be aware that SHA-1 and other legacy algorithms have known vulnerabilities. For production environments:

• Upgrade network equipment firmware
• Consider using jump hosts with modern SSH
• Isolate legacy devices in separate network segments

For deeper investigation, use verbose mode:

ssh -vvv -oKexAlgorithms=diffie-hellman-group14-sha1 user@remotehost

Look for these key lines in output:

debug1: kex: algorithm: diffie-hellman-group14-sha1
debug1: kex: host key algorithm: (none)
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none