Bug 1053107
| Summary: | OpenSSH can no longer connect to Cisco routers/switches | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | M. Scherer <mscherer> |
| Component: | openssh | Assignee: | Petr Lautrbach <plautrba> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Hubert Kario <hkario> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | CC: | dtucker, fweimer, hkario, jeff, jjelen, ksrot, mattias.ellert, matti.kurkela, mgrepl, mscherer, plautrba, tmraz, zing |
| Target Milestone: | rc | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openssh-6.4p1-7.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1026430 | Environment: | |
| Last Closed: | 2014-06-13 12:08:04 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1026430 | ||
| Bug Blocks: | 1067625, 1067633 | ||
|
Description
M. Scherer
2014-01-14 17:01:43 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1026430#c6: Both described issues - number of algorithms/ciphers/MACs and size of DH groups - are on 3rd party sides and should be fixed there. There are described workaround configurations for openssh clients so I would just document these issues and workaround configurations in KNOW ISSUES section in ssh(1) and other documentation. (In reply to Till Maas from comment #4) > You might also want to check whether a 128 bit symmetrical cipher works, > since > http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.3p1-increase- > size-of-DF-groups.patch > makes OpenSSH in Fedora use large DH parameters that other software might > not yet support, see e.g. bug 1044586 > > THis shows, that a 7680 bit DH parameter is used: > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) Not only Fedora, it's the upstream change [1] which follows NIST Special Publication 800-57. [1] https://anongit.mindrot.org/openssh.git/commit/?id=df62d71e64d29d1054e7a53d1a801075ef70335f I'm removing the Regression keyword. I don't consider this as a regression, it's not a bug introduced in recent update, it's more a feature - better security, more available ciphers/KEXs and so (In reply to Petr Lautrbach from comment #5) > https://bugzilla.redhat.com/show_bug.cgi?id=1026430#c6: > > Both described issues - number of algorithms/ciphers/MACs and size of DH > groups - are on 3rd party sides and should be fixed there. There are > described workaround configurations for openssh clients so I would just > document these issues and workaround configurations in KNOW ISSUES section > in ssh(1) and other documentation. > > > (In reply to Till Maas from comment #4) > > THis shows, that a 7680 bit DH parameter is used: > > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) > > Not only Fedora, it's the upstream change [1] which follows NIST Special > Publication 800-57. Thing is, it does *not* follow NIST SP 800-57. See Section 5.6.1 (page 63) in part 1, revision 3. And also Table 2 on page 64. 3DES that uses 3 distinct keys (3TDEA) has only 112 bit security, not 168 bit security as the DH key selection function assumes. So using 7680 bit DH together with 3DES is *not* correct. According to NIST SP 800-57 3DES should be used with 2048 bit DH. As such I'm restoring the regression keyword because the new version uses 3DES with non approved and excessive DH parameters. You are right. All ciphers used in openssh has number of bits of security same as the key size, but 3des hasn't. It will need a special manipulation of 3des or extending of Cipher structure with the size of security column. However, I believe that the original report is not related to oversized DP group used with 3des as it was confirmed that a connection can be done [1] using shorter list of ciphers and kex algorithms like Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchan ge-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [1] http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-December/031913.html Posted questions to upstream: http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-February/032177.html This doesn't resolve the problem in FIPS, then the requested DH size is 7k: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent because the algorithm takes SHA-1 160 bit over 3DES 112 bit. This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. I have a proposed patch in the upstream bug: https://bugzilla.mindrot.org/show_bug.cgi?id=2209 to cap the group size when talking to buggy implementations but I am unable to test it because I do not have access to an affected system. (In reply to Darren Tucker from comment #24) > I have a proposed patch in the upstream bug: > https://bugzilla.mindrot.org/show_bug.cgi?id=2209 to cap the group size when > talking to buggy implementations but I am unable to test it because I do not > have access to an affected system. Thank you for the information! unfortunately we're unable to provide one, your best bet will be to modify openssh behaviour for a test - make it select the suggested value always and ignore min and max values and abort the connection if the suggested size is above 4096 bit that's what the affected servers behaviour looked like Thank you for pointing out to this change. We are using similar patch in Fedora: basically the patch provided in bz1026430. In RHEL 7 it is hardcoded in different way, unfortunately not for everyone's satisfaction. But since it is working and currently we don't have any handy reproducer around here we will leave it as it is for now. |