Discussion:
[rancid] Request to remove hardcoded SSH 3des cipher
Mark Felder
2016-08-16 20:47:23 UTC
Permalink
Hello,

RANCID broke on my FreeBSD test box running 11.0-PRERELEASE due to a
newer version of OpenSSH. The problem was due to a default SSH cipher
"3des" being hardcoded into the various RANCID modules. I fixed this in
FreeBSD ports/packages by patching RANCID to use the more specific
3des-cbc cipher instead, but this is still not ideal. SSH 2.0 can handle
auto-negotiation of ciphers so there's no reason to force connections to
be 3des by default. I believe this feature could be removed from RANCID
entirely. If needed you can control the ciphers on a per-device basis in
~/.ssh/config.

You should also keep in mind that modern versions of OpenSSH disable
SSHv1, CBC ciphers, and DSA keys. While this is unlikely to affect Linux
distros in the near future, it is still something that should be planned
for. I can't be sure if it's better for RANCID to stop supporting older
devices or to stop supporting newer versions of OpenSSH, but we've
nearly reached a crossroads where this decision needs to be made.


Thanks to all, RANCID has been an invaluable tool.
--
Mark Felder
ports-secteam member
***@FreeBSD.org
heasley
2016-08-16 22:19:23 UTC
Permalink
Post by Mark Felder
Hello,
RANCID broke on my FreeBSD test box running 11.0-PRERELEASE due to a
newer version of OpenSSH. The problem was due to a default SSH cipher
"3des" being hardcoded into the various RANCID modules. I fixed this in
FreeBSD ports/packages by patching RANCID to use the more specific
3des-cbc cipher instead, but this is still not ideal. SSH 2.0 can handle
auto-negotiation of ciphers so there's no reason to force connections to
be 3des by default. I believe this feature could be removed from RANCID
entirely. If needed you can control the ciphers on a per-device basis in
~/.ssh/config.
You should also keep in mind that modern versions of OpenSSH disable
SSHv1, CBC ciphers, and DSA keys. While this is unlikely to affect Linux
distros in the near future, it is still something that should be planned
for. I can't be sure if it's better for RANCID to stop supporting older
devices or to stop supporting newer versions of OpenSSH, but we've
nearly reached a crossroads where this decision needs to be made.
Please try ftp://ftp.shrubbery.net/pub/rancid/alpha/rancid-3.4.99.tar.gz
which will be 3.5 and should address this.
Mark Felder
2016-08-17 13:20:59 UTC
Permalink
Post by heasley
Please try ftp://ftp.shrubbery.net/pub/rancid/alpha/rancid-3.4.99.tar.gz
which will be 3.5 and should address this.
Thank you! I will do some testing.

A bit of feedback at first glance: In the FAQ you mention changing the
Post by heasley
Cipher 3des
Ciphers 3des-cbc
This should be
Post by heasley
Cipher +3des
Ciphers +3des-cbc
You want the + so it's adding to those already enabled, not making it
the only one available and downgrading the security of all connections.
This way if a firmware upgrade for the device adds new SSH capabilities
the new connections will auto-negotiate better security.
--
Mark Felder
ports-secteam member
***@FreeBSD.org
heasley
2016-08-17 14:11:59 UTC
Permalink
Post by Mark Felder
Post by heasley
Please try ftp://ftp.shrubbery.net/pub/rancid/alpha/rancid-3.4.99.tar.gz
which will be 3.5 and should address this.
Thank you! I will do some testing.
thanks!
Post by Mark Felder
A bit of feedback at first glance: In the FAQ you mention changing the
Post by heasley
Cipher 3des
Ciphers 3des-cbc
This should be
Post by heasley
Cipher +3des
Ciphers +3des-cbc
You want the + so it's adding to those already enabled, not making it
the only one available and downgrading the security of all connections.
This way if a firmware upgrade for the device adds new SSH capabilities
the new connections will auto-negotiate better security.
thanks!
Mark Felder
2016-08-19 16:46:16 UTC
Permalink
Post by heasley
Post by Mark Felder
Post by heasley
Please try ftp://ftp.shrubbery.net/pub/rancid/alpha/rancid-3.4.99.tar.gz
which will be 3.5 and should address this.
Thank you! I will do some testing.
thanks!
I've tried this version and clogin works but rancid-run doesn't seem to
do anything. Now it's emailing me telling me the devices have not been
contacted in 24 hours. Very strange.
--
Mark Felder
ports-secteam member
***@FreeBSD.org
Heasley
2016-08-19 18:57:28 UTC
Permalink
Post by Mark Felder
Post by heasley
Post by Mark Felder
Post by heasley
Please try ftp://ftp.shrubbery.net/pub/rancid/alpha/rancid-3.4.99.tar.gz
which will be 3.5 and should address this.
Thank you! I will do some testing.
thanks!
I've tried this version and clogin works but rancid-run doesn't seem to
do anything. Now it's emailing me telling me the devices have not been
contacted in 24 hours. Very strange.
What is in the group's loggile?
Post by Mark Felder
--
Mark Felder
ports-secteam member
Mark Felder
2016-08-24 13:46:16 UTC
Permalink
Post by heasley
Post by Mark Felder
Post by heasley
Please try ftp://ftp.shrubbery.net/pub/rancid/alpha/rancid-3.4.99.tar.gz
which will be 3.5 and should address this.
Thank you! I will do some testing.
thanks!
Post by Mark Felder
A bit of feedback at first glance: In the FAQ you mention changing the
Post by heasley
Cipher 3des
Ciphers 3des-cbc
This should be
Post by heasley
Cipher +3des
Ciphers +3des-cbc
You want the + so it's adding to those already enabled, not making it
the only one available and downgrading the security of all connections.
This way if a firmware upgrade for the device adds new SSH capabilities
the new connections will auto-negotiate better security.
thanks!
And hot on the tails of this discussion, an attack on 3DES:
https://www.openssl.org/blog/blog/2016/08/24/sweet32/

3DES will no longer be compiled into OpenSSL by default in 1.1.0.
--
Mark Felder
ports-secteam member
***@FreeBSD.org
Mark Felder
2016-08-16 22:27:04 UTC
Permalink
Post by Mark Felder
Hello,
RANCID broke on my FreeBSD test box running 11.0-PRERELEASE due to a
newer version of OpenSSH. The problem was due to a default SSH cipher
"3des" being hardcoded into the various RANCID modules. I fixed this in
FreeBSD ports/packages by patching RANCID to use the more specific
3des-cbc cipher instead, but this is still not ideal.
Right - because now the FreeBSD ports version of rancid is different
from everybody else's version of rancid. I'd suggest that changing
the
add cyphertype * {3des}
line in cloginrc.sample would have been a better change.
No, because users who upgrade to FreeBSD 11.0 end still up with a broken
RANCID install. I removed that line entirely from my .cloginrc because I
didn't want it there; at the time I assumed it would auto-negotiate.
Users who still have cyphertype in their .cloginrc are still going to
get quite the surprise and there's not much I can safely do about that.
Modifying the sample doesn't fix their config.
Post by Mark Felder
SSH 2.0 can handle
auto-negotiation of ciphers so there's no reason to force connections to
be 3des by default. I believe this feature could be removed from RANCID
entirely. If needed you can control the ciphers on a per-device basis in
~/.ssh/config.
or in ~/.cloginrc
In my opinion it doesn't belong there, sorry. Further, if you read the
Post by Mark Felder
-c cipher_spec
Selects the cipher specification for encrypting the session.
Protocol version 1 allows specification of a single cipher. The
supported values are “3des”, “blowfish”, and “des”.
I'm not using SSH protocol v1. How many users are using SSH v1 with
RANCID? This hardcoded value is just plain wrong, and again -- should be
left to auto-negotiation.
Post by Mark Felder
You should also keep in mind that modern versions of OpenSSH disable
SSHv1, CBC ciphers, and DSA keys. While this is unlikely to affect Linux
distros in the near future, it is still something that should be planned
for. I can't be sure if it's better for RANCID to stop supporting older
devices or to stop supporting newer versions of OpenSSH, but we've
nearly reached a crossroads where this decision needs to be made.
I disagree. Change the
add cyphertype * {3des}
line in ~/.cloginrc and add
KexAlgorithms +diffie-hellman-group1-sha1
in ~/.ssh/config and rancid works just fine. Without having to drop
support for anything.
How does it make sense to control some SSH options in ~/.cloginrc, but
others in ~/.ssh/config ? Also, you have to compile SSHv1 support back
in to OpenSSH now. It's not just a config option disabled by default.
The same will eventually happen for the CBC ciphers, but I don't know
the timeline there.

I still don't see how users are benefitting from RANCID controlling the
ssh ciphers. Can someone please show how this provides better
interoperability or security than letting the ssh auto-negotiate? If the
version of OpenSSH installed on the OS has something disabled you're
still going to have to edit the ~/.ssh/config regardless.
--
Mark Felder
ports-secteam member
***@FreeBSD.org
heasley
2016-08-17 06:05:27 UTC
Permalink
Post by Mark Felder
You should also keep in mind that modern versions of OpenSSH disable
SSHv1, CBC ciphers, and DSA keys. While this is unlikely to affect Linux
distros in the near future, it is still something that should be planned
for. I can't be sure if it's better for RANCID to stop supporting older
devices or to stop supporting newer versions of OpenSSH, but we've
nearly reached a crossroads where this decision needs to be made.
I disagree. Change the
add cyphertype * {3des}
line in ~/.cloginrc and add
KexAlgorithms +diffie-hellman-group1-sha1
in ~/.ssh/config and rancid works just fine. Without having to drop
support for anything.
There was a time that 3des was the only thing that many devices supported,
but they seem to be the minority now. testing against the devices that I
can access, i've found that removing -c, which only allows v1 ciphers but
also affects v2 in openssh, seems to work more often than not. And there
is the subtle but important nuance is that -c can break v2 negotiation,
which implies to me that -c simply should not be used any longer and instead
favor the -o varieties, which allow greater customization in your cloginrc.

so, it seems time to transition, more obvious with some recent EFTs. i'm
open to other approaches, but it still seems clear that change is necessary.
Try the alpha and feedback.
Loading...