Bug 1353359
| Summary: | 5.3p1-117.el6 breaks gss-group1-sha1- key exchange algorithm for GSSAPIKeyExchange authentication | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | James Ralston <ralston> |
| Component: | openssh | Assignee: | Jakub Jelen <jjelen> |
| Status: | CLOSED ERRATA | QA Contact: | Stefan Dordevic <sdordevi> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.8 | CC: | nparmar, pvrabec, sdordevi, szidek |
| Target Milestone: | rc | Keywords: | Patch |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | openssh-5.3p1-119.el6 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-03-21 10:02:25 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: | |||
| Bug Blocks: | 1269194, 1343211 | ||
Thank you for the report and sorry for the confusion. The key exchange method
gss-group1-sha1-
was removed from default offer in Fedora intentionally (but you can always get it back), because of the Logjam threat (weakdh.org), based on the bug #1253060 (private). This method is using fixed 1024b group which is not future-proof.
1. The change of order was not intentional, if I remember well (not sure how this get through).
2. If I am right, we have got a test for this, which should verify general functionality of GSSAPI key exchange methods.
I will check that hopefully next week. But please, try to get in touch with your Red Hat support to evaluate and prioritize the issue properly.
Cross-filed as Red Hat Support Case 01664430. Thank you. I tried to reproduce your described behavior, but it happens only if I use MACs=hmac-sha2-512. It works fine with "default" hmac-md5, hmac-sha1 and even hmac-sha2-256 as MAC. The cause for this behavior is that the kex->we_need variable is set to 64 (the maximum of all the keys sizes from Cipher, MAC, and Cipher block size). This value after multiplying by 16 gets to 1024, which is the corner case we hit in this method (hard-coded size 1024). Backporting the upstream commit [1] relaxing the requirement solves the problem for me. Could you verify that with a test package that can Nilesh provide you? [1] https://anongit.mindrot.org/openssh.git/commit/?id=b8afbe2c Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2017-0641.html |
Description of problem: Up through and including 5.3p1-114.el6_7, the GSSAPIKexAlgorithms option was not implemented for ssh. The (hardcoded) default was: gss-gex-sha1-, gss-group1-sha1-, gss-group14-sha1- 5.3p1-117.el6 added the GSSAPIKexAlgorithms option, and additionally changed the default to: gss-group1-sha1-, gss-group14-sha1- gss-gex-sha1-, This change is puzzling, because the RHEL7 (6.6.1p1-25.el7_2) default is the same as 5.3p1-114.el6_7: gss-gex-sha1-, gss-group1-sha1-, gss-group14-sha1- And furthermore, the Fedora 23 default removes gss-group1-sha1- entirely: gss-gex-sha1-, gss-group14-sha1- That notwithstanding, we noticed this change because 5.3p1-117.el6 (and 5.3p1-118.1.el6_8) cannot successfully connect using GSSAPIKeyExchange authentication when gss-group1-sha1- is used. The exact error is: $ ssh -o PreferredAuthentications=gssapi-keyex host.example.org echo test debug1: kex: server->client aes256-ctr hmac-sha2-512 none debug2: mac_setup: found hmac-sha2-512 debug1: kex: client->server aes256-ctr hmac-sha2-512 none dh_gen_key: group too small: 1024 (2*need 1024) We tested 5.3p1-117.el6 (client) against these servers: 5.3p1-117.el6 6.6.1p1-25.el7_2 The error message is the same in both cases. Curiously, 6.6.1p1-25.el7_2 (client) can connect to 6.6.1p1-25.el7_2 (server) using gss-group1-sha1-, but if 6.6.1p1-25.el7_2 (client) connects to 5.3p1-117.el6 (server) using gss-group1-sha1-, then the server logs the same error message: fatal: dh_gen_key: group too small: 1024 (2*need 1024) …and closes the connection. (The client reports no error; the connection just silently closes.) I think the preceding demonstrates two things: 1. Changing the GSSAPIKexAlgorithms default in 5.3p1-117.el6 to prefer gss-group1-sha1- over gss-gex-sha1- is an error, and should be reverted: later versions of openssh either prefer gss-gex-sha1- to gss-group1-sha1-, or default to not using gss-group1-sha1- at all. This implies gss-group1-sha1- is deprecated, and should NOT be preferred. 2. Independent of point #1, the implementation of gss-group1-sha1- is clearly broken in 5.3p1-117.el6 (and 5.3p1-118.1.el6_8), for both the client and the server. We can effectively work around both issues by manually specifying the GSSAPIKexAlgorithms option in /etc/ssh/ssh_config on our RHEL6 hosts. But the broken gss-group1-sha1- implementation should be corrected. And per the RHEL7 and Fedora defaults, I would additionally argue that preferring gss-group1-sha1- over gss-gex-sha1- is an error. Version-Release number of selected component (if applicable): 5.3p1-117.el6