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