cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
36861
Views
64
Helpful
10
Replies

CISCO IOS does not support OpenSSH 6.4

loganaden
Level 1
Level 1

CISCO IOS does not support the latest OpenSSH 6.4p1 client.

Please find attached the debug log:

1 Accepted Solution

Accepted Solutions

In /etc/ssh/ssh_config write:

Host *
        GSSAPIAuthentication yes
#       KexAlgorithms=diffie-hellman-group14-sha1
        KexAlgorithms=curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

It works for me.

View solution in original post

10 Replies 10

ilobdell
Level 1
Level 1

You're not the only one Loganaden:

*Feb 20 17:49:57 UTC: SSH1: starting SSH control process

*Feb 20 17:49:57 UTC: SSH1: sent protocol version id SSH-2.0-Cisco-1.25

*Feb 20 17:49:57 UTC: SSH1: protocol version id is - SSH-2.0-OpenSSH_6.4

*Feb 20 17:49:57 UTC: SSH2 1: SSH2_MSG_KEXINIT sent

*Feb 20 17:49:57 UTC: SSH2 1: SSH2_MSG_KEXINIT received

*Feb 20 17:49:57 UTC: SSH2:kex: client->server enc:aes256-cbc mac:hmac-md5

*Feb 20 17:49:57 UTC: SSH2:kex: server->client enc:aes256-cbc mac:hmac-md5

*Feb 20 17:49:58 UTC: SSH2 1: SSH2_MSG_KEX_DH_GEX_REQUEST received

*Feb 20 17:49:58 UTC: SSH2 1: Range sent by client is - 1024 < 8192 < 8192

*Feb 20 17:49:58 UTC: SSH2 1:  Client DH key range mismatch with max built-in DH key on server!

*Feb 20 17:56:35 UTC: SSH1: starting SSH control process

*Feb 20 17:56:35 UTC: SSH1: sent protocol version id SSH-2.0-Cisco-1.25

*Feb 20 17:56:35 UTC: SSH1: protocol version id is - SSH-2.0-OpenSSH_6.4

*Feb 20 17:56:35 UTC: SSH2 1: SSH2_MSG_KEXINIT sent

*Feb 20 17:56:35 UTC: SSH2 1: SSH2_MSG_KEXINIT received

*Feb 20 17:56:35 UTC: SSH2:kex: client->server enc:aes128-cbc mac:hmac-md5

*Feb 20 17:56:35 UTC: SSH2:kex: server->client enc:aes128-cbc mac:hmac-md5

*Feb 20 17:56:36 UTC: SSH2 1: SSH2_MSG_KEX_DH_GEX_REQUEST received

*Feb 20 17:56:36 UTC: SSH2 1: Range sent by client is - 1024 < 3072 < 8192

*Feb 20 17:56:36 UTC: SSH2 1:  Invalid modulus length

*Feb 20 17:56:36 UTC: SSH1: Session disconnected - error 0x00

In /etc/ssh/ssh_config write:

Host *
        GSSAPIAuthentication yes
#       KexAlgorithms=diffie-hellman-group14-sha1
        KexAlgorithms=curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

It works for me.

this worked for me too... thank you

Phillip Remaker
Cisco Employee
Cisco Employee
Try setting

ip ssh dh min size 4096

to force the SSH server to pick a higher and supported size.

Or set OpenSSH to use one of the supported sizes:

IOS SSH supports group2 (1024 bits), group14 (2048 bits) and group16 (4096)

It seems that when  you are runing 15.0.1.M4 (on a 2911) the default aes128-cbc fails but when running on 15.1.4.M5 it works.  but, aes256-cbc fails on both.  I still believe that this is more likely an OpenSSH issue as when using putty / securecrt it works fine and negotiates with aes256-cbc just fine.

You might do better to ask in one of the security forums since this forum is really about understanding existing, documented bugs (with identifiying numbers) as opposed to identifying potential new bugs.

This change on the IOS side worked for me. Experienced this issue Running Ubuntu14.04 LTS and its default openssh client.

 

Ciphers
Specifies the ciphers allowed for protocol version 2 in order of preference. Multiple ciphers must be comma-separated. The supported ciphers are ''3des-cbc'', ''aes128-cbc'', ''aes192-cbc'', ''aes256-cbc'', ''aes128-ctr'', ''aes192-ctr'', ''aes256-ctr'', ''arcfour128'', ''arcfour256'', ''arcfour'', ''blowfish-cbc'', and ''cast128-cbc''.

The default is:

aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
aes256-cbc,arcfour

Use:

 

ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc -o MACs=hmac-md5,hmac-sha1 <username@destinationdevice>

Phillip Remaker
Cisco Employee
Cisco Employee

There is a bug open on this: CSCuo76464

From the release note:

SSH clients configured for stronger ciphers may fail to connect to the router, resulting in a syslog message "%SSH-3-DH_RANGE_FAIL: Client DH key range mismatch with maximum configured DH key on server".

The most "reliable" (across the variety of the client proposed key lengths) temporary workaround is to use weaker ciphers for the connection - of course this nullifies the security improvements made in the newer clients. In some cases changing the DH length configuration on the router may make it work, however this works only with the client-requested keylength below 4096. The newer clients request keys longer than that (768), and configuring the length of e.g. 4096 on the router will result in an inability to connect at all - neither with the default SSH configuration, nor with the weaker ciphers. Therefore that workaround needs to be verified by performing ssh in verbose mode, and checking that the client does not send the key request above 4096.

-----

Technically, IOS is violating the "SHOULD" provision of RFC4419:

"The server should return the smallest group it knows that is larger than the size the client requested.  If the server does not know a group that is larger than the client request, then it SHOULD return the largest group it knows.  In all cases, the size of the returned group SHOULD be at least 1024 bits."

IOS only supports key lengths up to 4096, currently.

This bug (function restriction) seems to be still open in IOS XE 16.6.2 on the new Catalyst 9300 platform.