Discussion:
[rancid] As one door closes, another opens... ssh failing with (some) Cisco devices after OS upgrade?
Howard Jones
2015-05-15 16:38:38 UTC
Permalink
After a lot of fiddling around, I found that my previous RANCID system,
running on CentOS 5 was just not able to reliably deal with ExtremeXOS
switches, apparently due to an expect issue. So I've just finished
moving to a new (RANCID 3.2, CentOS 7) system. I'd forgotten how many
little patches I'd added over the last couple of years, so that was a
fun process! My Extreme switches are backing up correctly, though.

Anyway, now I find that I can't connect to a few Cisco ASRs with SSH
from that new box (works fine with putty). They just drop connection
with this slightly strange message in the logs:

May 15 16:57:30.399 BST: SSH2 1: Client DH key range mismatch with max
built-in DH key on server!
May 15 16:57:30.399 BST: %SSH-5-SSH2_SESSION: SSH2 Session request from
192.168.0.27 (tty = 1) using crypto cipher '', hmac '' Failed
May 15 16:57:30.399 BST: %SSH-5-SSH2_CLOSE: SSH2 Session from
192.168.0.27 (tty = 1) for user '' using crypto cipher '', hmac '' closed

On the Rancid side, I actually copied all the SSH keys (host and rancid
user) across from the old machine, to avoid any 'key changed' type
issues. Running with ssh -v, the last messages are:

debug1: kex: server->client aes128-cbc hmac-sha1 none
debug1: kex: client->server aes128-cbc hmac-sha1 none
debug1: kex: diffie-hellman-group-exchange-sha1 need=20 dh_need=20
debug1: kex: diffie-hellman-group-exchange-sha1 need=20 dh_need=20
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

This seems to be to do with a new lower key size restriction in newer
openssh version - does anyone know a way around it? Ideally without
regenerating the keys on the routers? In fact, I just tried regenerating
a 2048-bit key on one of the affected routers, and it makes no
difference anyway.

Thanks in advance,

Howard
Howard Jones
2015-05-16 10:08:08 UTC
Permalink
Post by Howard Jones
This seems to be to do with a new lower key size restriction in newer
openssh version - does anyone know a way around it? Ideally without
regenerating the keys on the routers? In fact, I just tried
regenerating a 2048-bit key on one of the affected routers, and it
makes no difference anyway.
I "resolved" my issue for now by installing a copy of openssh 4.9 in
/opt and using sshcmd for the affected devices - a selection of ASRs and
ISRs, but not all. I'd still be interested in what the real fix is
though! Evidently those specific devices don't meet some minimum
standard that the openssh folks enforce.

Cheers,

Howard
Alex DEKKER
2015-05-16 21:31:05 UTC
Permalink
Evidently those specific devices don't meet some minimum standard
that the openssh folks enforce.
There is an option you can pass to SSH ['-o
KexAlgorithms=diffie-hellman-group14-sha1'] to allow it to connect to
older versions of IOS. The error emitted by SSH isn't much help at all.

alexd
Randy Bush
2015-05-16 21:57:41 UTC
Permalink
Post by Alex DEKKER
There is an option you can pass to SSH ['-o
KexAlgorithms=diffie-hellman-group14-sha1'] to allow it to connect to
older versions of IOS. The error emitted by SSH isn't much help at all.
for really older images, e.g. those on a 2511, try

ssh -1 <hostname>

randy
John Heasley
2015-05-17 02:58:17 UTC
Permalink
Post by Randy Bush
Post by Alex DEKKER
There is an option you can pass to SSH ['-o
KexAlgorithms=diffie-hellman-group14-sha1'] to allow it to connect to
older versions of IOS. The error emitted by SSH isn't much help at all.
for really older images, e.g. those on a 2511, try
ssh -1 <hostname>
Just on my mobile, so cant double check ATM, but there is a 'sshcmd' in cloginrc(5). I beleieve it can be made to pass other options, eg {ssh\ -o\ ....}. One can also use Host directives in ~/.ssh/config for many if not all ssh client options. Write again if these options dont work.
Howard Jones
2015-05-17 10:05:38 UTC
Permalink
Post by Alex DEKKER
Evidently those specific devices don't meet some minimum standard
that the openssh folks enforce.
There is an option you can pass to SSH ['-o
KexAlgorithms=diffie-hellman-group14-sha1'] to allow it to connect to
older versions of IOS. The error emitted by SSH isn't much help at all.
Aha! That's the one. Thanks, Alex.

So for the archive, the complete fix is to create a shell script
(local/ssh-old-kex for me):

#!/bin/sh
ssh -o KexAlgorithms=diffie-hellman-group14-sha1 $*

Then for the affected devices, add this in .cloginrc

add sshcmd oldrouter /opt/rancid/local/ssh-old-kex
Nick Hilliard
2015-05-17 12:58:56 UTC
Permalink
Post by Alex DEKKER
Evidently those specific devices don't meet some minimum standard that
the openssh folks enforce.
There is an option you can pass to SSH ['-o
KexAlgorithms=diffie-hellman-group14-sha1'] to allow it to connect to older
versions of IOS. The error emitted by SSH isn't much help at all.
or on ios config:

ip ssh dh min size 4096

This doesn't work on all IOS images but if it works, it's a useful
workaround where upgrading is a problem.

Nick

Loading...