Hide Forgot
+++ 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,ssh-rsa-cert-v00,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,ssh-rsa-cert-v00,ssh-rsa,ecdsa-sha2-nistp256-cert-v01,ecdsa-sha2-nistp384-cert-v01,ecdsa-sha2-nistp521-cert-v01,ssh-dss-cert-v01,ssh-dss-cert-v00,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,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib,zlib debug2: kex_parse_kexinit: none,zlib,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,ssh-rsa-cert-v00,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,ssh-rsa-cert-v00,ssh-rsa,ecdsa-sha2-nistp256-cert-v01,ecdsa-sha2-nistp384-cert-v01,ecdsa-sha2-nistp521-cert-v01,ssh-dss-cert-v01,ssh-dss-cert-v00,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,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm,hmac-sha1-etm,umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-ripemd160-etm,hmac-sha1-96-etm,hmac-md5-96-etm,hmac-md5,hmac-sha1,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib,zlib debug2: kex_parse_kexinit: none,zlib,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 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 ) ) ); }
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.