Bug 1053107

Summary: OpenSSH can no longer connect to Cisco routers/switches
Product: Red Hat Enterprise Linux 7 Reporter: M. Scherer <mscherer>
Component: opensshAssignee: Petr Lautrbach <plautrba>
Status: CLOSED CURRENTRELEASE QA Contact: Hubert Kario <hkario>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: dtucker, fweimer, hkario, jeff, jjelen, ksrot, mattias.ellert, matti.kurkela, mgrepl, mscherer, plautrba, tmraz, zing
Target Milestone: rcKeywords: 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:
Bug Depends On: 1026430    
Bug Blocks: 1067625, 1067633    

Description M. Scherer 2014-01-14 17:01:43 UTC
+++ This bug was initially created as a clone of Bug #1026430 +++

Description of problem:
OpenSSH can no longer connect to Cisco routers/switches using the default settings of KexAlgorithms.  If you remove diffie-hellman-group-exchange-sha1 from the list of algorithms you can connect just fine.

Version-Release number of selected component (if applicable):
openssh-6.3p1-5.fc20.x86_64

How reproducible:
Always

Steps to Reproduce:
1. slogin -vvv 10.6.0.14


Actual results:
$ slogin -vvv 10.6.0.14
OpenSSH_6.3, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/jcollie/.ssh/config
debug1: /home/jcollie/.ssh/config line 38: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 3: Applying options for *
debug3: cipher ok: aes256-ctr [aes256-ctr,3des-cbc]
debug3: cipher ok: 3des-cbc [aes256-ctr,3des-cbc]
debug3: ciphers ok: [aes256-ctr,3des-cbc]
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.6.0.14 [10.6.0.14] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/jcollie/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/jcollie/.ssh/id_rsa type 1
debug1: identity file /home/jcollie/.ssh/id_rsa-cert type -1
debug1: identity file /home/jcollie/.ssh/id_dsa type -1
debug1: identity file /home/jcollie/.ssh/id_dsa-cert type -1
debug1: identity file /home/jcollie/.ssh/id_ecdsa type -1
debug1: identity file /home/jcollie/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.3
debug1: Remote protocol version 1.99, remote software version Cisco-1.25
debug1: no match: Cisco-1.25
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "10.6.0.14" from file "/home/jcollie/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/jcollie/.ssh/known_hosts:807
debug2: key_type_from_name: unknown key type '1024'
debug3: key_read: missing keytype
debug3: load_hostkeys: found key type RSA1 in file /home/jcollie/.ssh/known_hosts:808
debug3: load_hostkeys: loaded 2 keys
debug3: load_hostkeys: loading entries for host "10.6.0.14" from file "/etc/ssh/ssh_known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes256-ctr,3des-cbc
debug2: kex_parse_kexinit: aes256-ctr,3des-cbc
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client 3des-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server 3des-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by 10.6.0.14

Expected results:
$ slogin -vvv -o KexAlgorithms=diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 10.6.0.14 
OpenSSH_6.3, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/jcollie/.ssh/config
debug1: /home/jcollie/.ssh/config line 38: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 3: Applying options for *
debug3: cipher ok: aes256-ctr [aes256-ctr,3des-cbc]
debug3: cipher ok: 3des-cbc [aes256-ctr,3des-cbc]
debug3: ciphers ok: [aes256-ctr,3des-cbc]
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.6.0.14 [10.6.0.14] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/jcollie/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/jcollie/.ssh/id_rsa type 1
debug1: identity file /home/jcollie/.ssh/id_rsa-cert type -1
debug1: identity file /home/jcollie/.ssh/id_dsa type -1
debug1: identity file /home/jcollie/.ssh/id_dsa-cert type -1
debug1: identity file /home/jcollie/.ssh/id_ecdsa type -1
debug1: identity file /home/jcollie/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.3
debug1: Remote protocol version 1.99, remote software version Cisco-1.25
debug1: no match: Cisco-1.25
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "10.6.0.14" from file "/home/jcollie/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/jcollie/.ssh/known_hosts:807
debug2: key_type_from_name: unknown key type '1024'
debug3: key_read: missing keytype
debug3: load_hostkeys: found key type RSA1 in file /home/jcollie/.ssh/known_hosts:808
debug3: load_hostkeys: loaded 2 keys
debug3: load_hostkeys: loading entries for host "10.6.0.14" from file "/etc/ssh/ssh_known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes256-ctr,3des-cbc
debug2: kex_parse_kexinit: aes256-ctr,3des-cbc
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client 3des-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server 3des-cbc hmac-md5 none
debug2: dh_gen_key: priv key bits set: 172/384
debug2: bits set: 999/2048
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA f4:f8:74:13:aa:b0:a7:bb:3f:69:ab:33:fb:1f:8f:68
debug3: load_hostkeys: loading entries for host "10.6.0.14" from file "/home/jcollie/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/jcollie/.ssh/known_hosts:807
debug2: key_type_from_name: unknown key type '1024'
debug3: key_read: missing keytype
debug3: load_hostkeys: found key type RSA1 in file /home/jcollie/.ssh/known_hosts:808
debug3: load_hostkeys: loaded 2 keys
debug3: load_hostkeys: loading entries for host "10.6.0.14" from file "/etc/ssh/ssh_known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: Host '10.6.0.14' is known and matches the RSA host key.
debug1: Found key in /home/jcollie/.ssh/known_hosts:807
debug2: bits set: 1062/2048
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/jcollie/.ssh/id_rsa (0x7ffd0b15e130),
debug2: key: /home/jcollie/.ssh/id_dsa ((nil)),
debug2: key: /home/jcollie/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,keyboard-interactive,password
debug3: start over, passed a different list publickey,keyboard-interactive,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/jcollie/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug2: input_userauth_pk_ok: fp 5b:15:0c:73:33:78:a0:c1:a6:b7:e4:bd:e4:b5:b9:90
debug3: sign_and_send_pubkey: RSA 5b:15:0c:73:33:78:a0:c1:a6:b7:e4:bd:e4:b5:b9:90
debug1: Authentication succeeded (publickey).
Authenticated to 10.6.0.14 ([10.6.0.14]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug1: Requesting authentication agent forwarding.
debug2: channel 0: request auth-agent-req@openssh.com confirm 0
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env XDG_VTNR
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env HOSTNAME
debug3: Ignored env IMSETTINGS_INTEGRATE_DESKTOP
debug3: Ignored env GPG_AGENT_INFO
debug3: Ignored env VTE_VERSION
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env XDG_MENU_PREFIX
debug3: Ignored env HISTSIZE
debug3: Ignored env XDG_SESSION_COOKIE
debug3: Ignored env GJS_DEBUG_OUTPUT
debug3: Ignored env WINDOWID
debug3: Ignored env GNOME_KEYRING_CONTROL
debug3: Ignored env QTDIR
debug3: Ignored env QTINC
debug3: Ignored env GJS_DEBUG_TOPICS
debug3: Ignored env IMSETTINGS_MODULE
debug3: Ignored env QT_GRAPHICSSYSTEM_CHECKED
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env USERNAME
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env PATH
debug3: Ignored env MAIL
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env QT_IM_MODULE
debug3: Ignored env PWD
debug1: Sending env XMODIFIERS = @im=none
debug2: channel 0: request env confirm 0
debug1: Sending env EDITOR = emacs
debug2: channel 0: request env confirm 0
debug3: Ignored env GNOME_KEYRING_PID
debug1: Sending env LANG = en_US.utf8
debug2: channel 0: request env confirm 0
debug3: Ignored env KDE_IS_PRELINKED
debug3: Ignored env GDM_LANG
debug3: Ignored env KDEDIRS
debug3: Ignored env GDMSESSION
debug3: Ignored env SSH_ASKPASS
debug3: Ignored env HISTCONTROL
debug3: Ignored env XDG_SEAT
debug3: Ignored env HOME
debug3: Ignored env SHLVL
debug3: Ignored env GNOME_DESKTOP_SESSION_ID
debug3: Ignored env LOGNAME
debug3: Ignored env QTLIB
debug3: Ignored env CVS_RSH
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env LESSOPEN
debug3: Ignored env WINDOWPATH
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env DISPLAY
debug3: Ignored env QT_PLUGIN_PATH
debug3: Ignored env COLORTERM
debug3: Ignored env XAUTHORITY
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 8192 rmax 4096
debug2: channel_input_status_confirm: type 100 id 0
X11 forwarding request failed on channel 0
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

cisco-switch#

Additional info:
Has some similarities to #1024004 but new package did not fix the problem.

--- Additional comment from Jeffrey C. Ollie on 2013-11-07 11:58:40 EST ---

This also appears to be affecting an APC AP9631 UPS management card.

--- Additional comment from Matti Kurkela on 2013-11-11 10:11:19 EST ---

A similar issue was found in HP iLO2 server management processors and OpenSSH 6.2 and later: it was caused by a buffer in the server side not being big enough to accept all the negotiable options offered by a modern SSH client. 

Apparently the SSH protocol specification does not explicitly say how much option data the server should be prepared to receive, and the authors of some embedded SSH server implementations may have made some assumptions that are now proving to be incorrect.

As a workaround, use options with the ssh command to minimize the number of algorithms/ciphers/MACs, like this command suggested with old HP iLO2s:

ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc -o MACs=hmac-md5,hmac-sha1 <destination>

The actual fix in the case of iLO2 was the implementation of a larger buffer in the iLO2 SSH server code. This was implemented in iLO2 firmware version 2.20.

--- Additional comment from Michael Samuel on 2013-11-19 21:42:13 EST ---

With Cisco routers, only KexAlgorithms makes a difference - no need to reduce the MACs or Ciphers supported.

You probably want -o KexAlgorithms=diffie-hellman-group14-sha1 in your Host setting for your Cisco routers - using group1 is deprecated - these are probably breakable in a human timeframe.

--- Additional comment from Till Maas on 2013-12-18 13:05:53 EST ---

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)

--- Additional comment from Florian Weimer on 2014-01-14 11:36:05 EST ---

The SSH server code in Peter Gutmann's cryptlib ignores the minimum value in the SSH2_MSG_KEX_DH_GEX_REQUEST message and unconditionally uses the requested value.  Group sizes are limited to CRYPT_MAX_PKCSIZE aka 4096 bits:

        status = length = \
                readHSPacketSSH2( sessionInfoPtr, SSH_MSG_KEXDH_GEX_REQUEST_OLD,
                                                  ID_SIZE + UINT32_SIZE );
        if( cryptStatusError( status ) )
                return( status );
        sMemConnect( &stream, sessionInfoPtr->receiveBuffer, length );
        streamBookmarkSet( &stream, keyexInfoLength );
        if( sessionInfoPtr->sessionSSH->packetType == SSH_MSG_KEXDH_GEX_REQUEST_NEW )
                {
                /* It's a { min_length, length, max_length } sequence, save a copy
                   and get the length value */
                readUint32( &stream );
                keySize = readUint32( &stream );
                status = readUint32( &stream );
                }
        else
                {
                /* It's a straight length, save a copy and get the length value */
                status = keySize = readUint32( &stream );
                }
        if( !cryptStatusError( status ) )
                status = streamBookmarkComplete( &stream, &keyexInfoPtr,
                                                                                 &keyexInfoLength, keyexInfoLength );
        sMemDisconnect( &stream );
        if( cryptStatusError( status ) )
                {
                retExt( status,
                                ( status, SESSION_ERRINFO,
                                  "Invalid ephemeral DH key data request packet" ) );
                }
        ANALYSER_HINT( keyexInfoPtr != NULL );
        if( keySize < bytesToBits( MIN_PKCSIZE ) || \
                keySize > bytesToBits( CRYPT_MAX_PKCSIZE ) )
                {
                retExt( CRYPT_ERROR_BADDATA,
                                ( CRYPT_ERROR_BADDATA, SESSION_ERRINFO,
                                  "Client requested invalid ephemeral DH key size %d bits, "
                                  "should be %d...%d", keySize,
                                  bytesToBits( MIN_PKCSIZE ),
                                  bytesToBits( CRYPT_MAX_PKCSIZE ) ) );
                }

Comment 5 Petr Lautrbach 2014-01-21 12:44:35 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

Comment 6 Hubert Kario 2014-01-21 13:11:25 UTC
(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.

Comment 7 Petr Lautrbach 2014-01-21 14:55:41 UTC
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.

Comment 8 Petr Lautrbach 2014-01-21 15:07:19 UTC
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

Comment 16 Hubert Kario 2014-02-04 16:03:01 UTC
Posted questions to upstream:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-February/032177.html

Comment 17 Hubert Kario 2014-02-12 18:20:10 UTC
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.

Comment 22 Ludek Smid 2014-06-13 12:08:04 UTC
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.

Comment 24 Darren Tucker 2015-05-22 04:22:09 UTC
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.

Comment 25 Hubert Kario 2015-05-22 10:19:05 UTC
(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

Comment 26 Jakub Jelen 2015-05-25 14:14:59 UTC
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.