SSH Key Exchange fails to Cisco devices

I upgraded my VM to use FreeBSD 10.1 and included with this was an upgrade to OpenSSH (OpenSSH_6.6.1p1). When you ssh to some Cisco devices using this version you cannot connect.

Debugging on the client side does not show much other than the connection is dropped.

OpenSSH_6.6.1p1, OpenSSL 1.0.1j-freebsd 15 Oct 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: ciphers ok: [aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc]
debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160]
debug2: ssh_connect: needpriv 0
debug1: Connecting to rtr01.lpr [10.202.70.151] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/xx/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/xx/.ssh/id_rsa type 1
debug1: identity file /home/xx/.ssh/id_rsa-cert type -1
debug1: identity file /home/xx/.ssh/id_dsa type -1
debug1: identity file /home/xx/.ssh/id_dsa-cert type -1
debug1: identity file /home/xx/.ssh/id_ecdsa type -1
debug1: identity file /home/xx/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/xx/.ssh/id_ed25519 type -1
debug1: identity file /home/xx/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
debug1: Remote protocol version 2.0, remote software version Cisco-1.25
debug1: no match: Cisco-1.25
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_load_hostkeys: loading entries for host "rtr01.lpr" from file "/home/xx/.ssh/known_hosts"
debug3: ssh_load_hostkeys: found key type RSA in file /home/xx/.ssh/known_hosts:11
debug3: ssh_load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
debug2: kex_parse_kexinit: aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup hmac-md5
debug1: kex: server->client aes256-cbc hmac-md5 none
debug2: mac_setup: setup hmac-md5
debug1: kex: client->server aes256-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by 10.202.70.151

Debugging on the server site (ie on the cisco device) shows

Nov 24 05:46:22.944: SSH1: starting SSH control process
Nov 24 05:46:22.948: SSH1: sent protocol version id SSH-2.0-Cisco-1.25
Nov 24 05:46:22.952: SSH1: protocol version id is - SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
Nov 24 05:46:22.960: SSH2 1: SSH2_MSG_KEXINIT sent
Nov 24 05:46:22.960: SSH2 1: SSH2_MSG_KEXINIT received
Nov 24 05:46:22.968: SSH2:kex: client->server enc:aes256-cbc mac:hmac-md5
Nov 24 05:46:22.972: SSH2:kex: server->client enc:aes256-cbc mac:hmac-md5
Nov 24 05:46:22.980: SSH2 1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Nov 24 05:46:22.980: SSH2 1: Range sent by client is - 1024 < 8192 < 8192
Nov 24 05:46:22.980: SSH2 1:  Client DH key range mismatch with max built-in DH key on server!
Nov 24 05:46:23.084: SSH1: Session disconnected - error 0x00

The Cisco device supports a maximum key length of 2048 where as the client is requesting a keylength of 8192. A debug from an older client shows that is request a smaller key:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 145/256
debug2: bits set: 505/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

This change seems to have been introduced in OpenSSH v6.6 and I can’t find a way to turn this off. Cisco has registered a bug CSCuo76464 for this.

The simplest workaround seems to be to reorganize the KexAlgorithms in /etc/ssh/ssh_config by adding the following line:

KexAlgorithms diffie-hellman-group14-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

 

 

 

 

 

 

 

 

Advertisements

One thought on “SSH Key Exchange fails to Cisco devices

  1. Thank you for this easy fix. Odd thing is this just started happening to me on a newer version of Ubuntu which had been working fine up until today. I always upgrade my Ubuntu to the latest version so I would have though I would have encountered this around 2014, not in 2016 especially since I was just SSH’ing into this ASA last week, granted that was via an SSH jump, but still.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s