Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1026430 - OpenSSH can no longer connect to Cisco routers/switches
Summary: OpenSSH can no longer connect to Cisco routers/switches
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Lautrbach
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1053107
TreeView+ depends on / blocked
 
Reported: 2013-11-04 15:55 UTC by Jeffrey C. Ollie
Modified: 2016-07-22 07:58 UTC (History)
15 users (show)

Fixed In Version: openssh-6.6.1p1-9.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1053107 (view as bug list)
Environment:
Last Closed: 2014-12-12 04:04:50 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
Patch to handle Cisco issue (2.47 KB, patch)
2014-11-12 17:18 UTC, Peter Bowen 		no flags Details | Diff
Patch to handle Cisco issue (1.77 KB, patch)
2014-12-03 17:00 UTC, Petr Lautrbach 		no flags Details | Diff
Show Obsolete (1) View All

Description Jeffrey C. Ollie 2013-11-04 15:55:05 UTC 
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.
Comment 1 Jeffrey C. Ollie 2013-11-07 16:58:40 UTC 
This also appears to be affecting an APC AP9631 UPS management card.
Comment 2 Matti Kurkela 2013-11-11 15:11:19 UTC 
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.
Comment 3 Michael Samuel 2013-11-20 02:42:13 UTC 
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.
Comment 4 Till Maas 2013-12-18 18:05:53 UTC 
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)
Comment 5 Florian Weimer 2014-01-14 16:36:05 UTC 
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 6 Petr Lautrbach 2014-01-21 12:38:12 UTC 
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
Comment 7 Hubert Kario 2014-01-21 13:33:05 UTC 
(In reply to Petr Lautrbach from comment #6)
> Not only Fedora, it's the upstream change which follows NIST Special
> Publication 800-57.

NIST SP 800-57 recommends use of 2048 bit DH with 3DES. openssh uses 7680 bit DH wit 3DES.
Comment 8 Petr Lautrbach 2014-01-23 17:43:41 UTC 
Please test following build [1] if it helps with connection to Cisco router using 3des-cbc. It's patched to use size of security of 3DES which is 112 bits for DH group estimation, so it send 2048 as a preferred value instead of 7168 which is based on 3des key size 192 bits.


[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6445485
Comment 9 Peter Bowen 2014-11-12 17:18:24 UTC 
Created attachment 956814 [details]
Patch to handle Cisco issue

We observed this behavior and tracked it down to two issues:
- Some Cisco ssh daemons only allow DH key sizes that are powers of two
- Some Cisco ssh daemons only allow DH key sizes that are 4096 bits or less

We observed both behaviors on various IOS versions.   The attached patch adds a new compatibility flag to track the max DH size bug and changes the key size choice algorithm to only offer key sizes that are powers of two.

The cryptlib implementation of SSH only supports key sizes that are powers of two, so the change to the key choices is conditioned on the Cisco SSH daemon banner, as using 3072 and 7680 bits has been seen to cause connection failures on other servers as well.
Comment 11 Petr Lautrbach 2014-12-03 17:00:30 UTC 
Created attachment 964223 [details]
Patch to handle Cisco issue

Thanks for the patch, Peter. 

I had to fix some syntax errors and typos and I've also changed it slightly however the idea looks good to me and the new patch seems to work as expected.

I'll push it in the next update to Rawhide, f21 and f20.
Comment 12 Fedora Update System 2014-12-04 09:40:57 UTC 
openssh-6.6.1p1-9.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/openssh-6.6.1p1-9.fc21
Comment 13 Fedora Update System 2014-12-04 14:05:18 UTC 
openssh-6.4p1-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openssh-6.4p1-7.fc20
Comment 14 Fedora Update System 2014-12-05 00:47:53 UTC 
Package openssh-6.6.1p1-9.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openssh-6.6.1p1-9.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-16315/openssh-6.6.1p1-9.fc21
then log in and leave karma (feedback).
Comment 15 Fedora Update System 2014-12-12 04:04:50 UTC 
openssh-6.4p1-7.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Fedora Update System 2014-12-20 08:42:42 UTC 
openssh-6.6.1p1-9.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 17 Prasad 2016-07-19 07:42:03 UTC 
Found the similar issue while login to alcatel router in LAB after upgrading to openSSH_7.2p2. It gives me below error,

ssh_dispatch_run_fatal: Connection to 192.168.19.11 port 22: DH GEX group out of range


when I tried below command it works,

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  root.19.11

the patch mentioned in above comment#11 is failing as there are many changes in respective files.

Please help me to patch the openSSH_7.2p2 with this solution.
Comment 18 Jakub Jelen 2016-07-19 08:07:56 UTC 
Hello Prasad,
Can you provide full verbose log from your attempt?

    ssh -vvv root.19.11

We had a workaround for Cisco (but it was dropped a year ago), but your router looks like Alcatel. Even if the patch would apply, it would not probably make a difference.
Comment 19 Prasad 2016-07-19 08:46:08 UTC 
Thank you Jakub for the reply. Looking forward to get help/pointers on this issue.

Below is the output,
OpenSSH_7.2p2, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "192.168.19.11" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.19.11 [192.168.19.11] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat OpenSSH_3.* compat 0x01000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.19.11:22 as 'qwerty'
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /root/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from 192.168.19.11
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ssh-rsa-cert-v01,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01,ecdsa-sha2-nistp384-cert-v01,ecdsa-sha2-nistp521-cert-v01,ssh-ed25519-cert-v01,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-sha1-etm,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-sha1-etm,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib,zlib
debug2: compression stoc: none,zlib,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss
debug2: ciphers ctos: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc.se
debug2: ciphers stoc: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc.se
debug2: MACs ctos: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: diffie-hellman-group-exchange-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug3: send packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent
debug3: receive packet: type 31
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
ssh_dispatch_run_fatal: Connection to 192.168.19.11 port 22: DH GEX group out of range
Comment 20 Jakub Jelen 2016-07-19 09:03:21 UTC 
> debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1
> debug1: match: OpenSSH_3.5p1 pat OpenSSH_3.* compat 0x01000000

This is not the Cisco software, but just very old version of OpenSSH, already with some workarounds so unrelated to this bug.

As it is OpenSSH, you should be able to obtain similar log from the server (LogLevel DEBUG3).

Clearly we talk here about  diffie-hellman-group-exchange-sha1  key exchange method, which probably in the case of the router does not support sizes > 2048 (1024 is considered soon-to-be-broken and already deprecated by upstream).

I guess your best bet would be to modify your ~/.ssh/config

    Host 192.168.19.11
      KexAlgorithms diffie-hellman-group1-sha1

The minimal DH group size is not configurable at this moment.
Comment 21 Prasad 2016-07-19 11:00:40 UTC 
I have tried this option. But I can not use it. Is there any way I can patch the openSSH_7.2p2.
Comment 22 Prasad 2016-07-22 07:58:11 UTC 
@Jakub/Petr,


I did following change in openssh-7.2p2. And it started working for me.

localhost openssh-7.2p2# diff ../../production/openssh-7.2p2/kexgexc.c kexgexc.c
70a71,81
> 
> 	if ((datafellows & SSH_OLD_FORWARD_ADDR) ||
> 	    (datafellows & (SSH_BUG_DHGEX_LARGE|SSH_BUG_HOSTKEYS)))
>         {
> 
>             debug("=========Getting closer to solution by one step!!!! It is either openSSH3.* (Alcatel) or Cisco-1*!!!=============");
>             kex->min = 1024;
>             kex->max = 8192;
>             kex->nbits = 1024;
>         }		
> 

I hope it should be fine.

Thank You,
Prasad
Note You need to log in before you can comment on or make changes to this bug.