openssh-client 6.5 regression bug with certain servers

[tim nelson]

Previous working versions of SSH (6.2p2) work fine on certain host machines as follows:

penSSH_6.2p2 Ubuntu-6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to hostname [IPAddress] port 22.
debug1: Connection established.
debug1: identity file /home/nelsot08/.ssh/identity type -1
debug1: identity file /home/nelsot08/.ssh/identity-cert type -1
debug1: identity file /home/nelsot08/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/nelsot08/.ssh/id_rsa-cert type -1
debug1: identity file /home/nelsot08/.ssh/id_dsa type -1
debug1: identity file /home/nelsot08/.ssh/id_dsa-cert type -1
debug1: identity file /home/nelsot08/.ssh/id_ecdsa type -1
debug1: identity file /home/nelsot08/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version Cisco-1.25
debug1: no match: Cisco-1.25
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 24:75:76:a1:80:0e:6c:4e:a8:c4:a6:a9:d3:34:98:18
Warning: Permanently added 'hostname,IPAddress' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

But in 6.5p1 the following bug occurs:

OpenSSH_6.5, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to hostname [IPAddress] port 22.
debug1: Connection established.
debug1: identity file /home/nelsot08/.ssh/identity type -1
debug1: identity file /home/nelsot08/.ssh/identity-cert type -1
debug1: identity file /home/nelsot08/.ssh/id_rsa type 1
debug1: identity file /home/nelsot08/.ssh/id_rsa-cert type -1
debug1: identity file /home/nelsot08/.ssh/id_dsa type -1
debug1: identity file /home/nelsot08/.ssh/id_dsa-cert type -1
debug1: identity file /home/nelsot08/.ssh/id_ecdsa type -1
debug1: identity file /home/nelsot08/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/nelsot08/.ssh/id_ed25519 type -1
debug1: identity file /home/nelsot08/.ssh/id_ed25519-cert type -1
debug1: Remote protocol version 2.0, remote software version Cisco-1.25
debug1: no match: Cisco-1.25
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.5p1 Ubuntu-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by IPAddress

This is a regression and there are multiple references to this bug occurring previously:

http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

[Jeffrey (jeffrey-redhat-bugs)]

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: <email address hidden>,<email address hidden>,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: <email address hidden>,<email address hidden>,ssh-rsa,<email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,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: <email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,hmac-sha2-...

[Jeffrey (jeffrey-redhat-bugs)]

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

[Matti (matti-redhat-bugs)]

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.

[Michael (michael-redhat-bugs)]

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.

[Till (till-redhat-bugs)]

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)

[Florian (florian-redhat-bugs)]

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 ) ) );
                }

[Petr (petr-redhat-bugs)]

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

[Hubert (hubert-redhat-bugs)]

(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.

[Petr (petr-redhat-bugs)]

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

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[dcecchin (dcecchin-deactivatedaccount)]

I'm finding this with my cisco routers/switches. Everything else seems to work. Also this bug seems related https://bugzilla.redhat.com/show_bug.cgi?id=1026430

[dcecchin (dcecchin-deactivatedaccount)]

Also the work around suggested in that thread:

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>

allows me to connect.

[tim nelson (tim-l-nelson)]

That work around did not work for all the devices in my network sadly.

[tim nelson (tim-l-nelson)]

   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
   HostKeyAlgorithms ssh-rsa,ssh-dss
   KexAlgorithms diffie-hellman-group1-sha1
   MACs hmac-md5,hmac-sha1,<email address hidden>,hmac-ripemd160

In /etc/ssh/ssh_config resolve the issue. I would say this is not a bug.

[atimonin (atimonin)]

I also hit this connecting to Cisco, log from cisco:

SSH2 0: Invalid modulus length

For me

ssh -o KexAlgorithms=diffie-hellman-group14-sha1 x.x.x.x

works fine.

It affects not all Cisco, mainly old ones are not affected.

[andrew yourtchenko (ayourtch)]

I've filed the bug CSCuo76464 to get this fixed on the cisco side.

[Julian Alarcon (julian-alarcon)]

Bug was fixed https://tools.cisco.com/bugsearch/bug/CSCuo76464
(sorry, you need Cisco account). So, I think that this is not a bug, but a configuration incompatibility.
Simple explanation: openSSH require more security and external ssh server is not using this level of security.

[Julian Alarcon (julian-alarcon)]

Last Modified:
Jul 31,2014
Status:
Fixed
Severity:
3 Moderate
Product:
Cisco IOS
Support Cases:
2
Known Affected Releases:
(1)
n/a
Known Fixed Releases:
(6)
15.5(0.6)T
15.4(1)T1.3
15.3(3)S3.4
15.5(0.12)S
15.1(2)SY3.8
15.4(1)T2

[Peter (peter-redhat-bugs)]

Created attachment 956814
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.

[Petr (petr-redhat-bugs)]

Created attachment 964223
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.

[Fedora (fedora-redhat-bugs)]

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

[Fedora (fedora-redhat-bugs)]

openssh-6.4p1-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openssh-6.4p1-7.fc20

[Fedora (fedora-redhat-bugs)]

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).

[Fedora (fedora-redhat-bugs)]

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.

[Fedora (fedora-redhat-bugs)]

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.

[Brian Candler (b-candler)]

The workaround is fine, but if you want more detailed description about the underlying issues (there are more than one) see the Red Hat bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1026430

[Robie Basak (racb)]

Looks like there's a patch for openssh available the RH bug which detects broken server implementations and sends options that they can accept (by matching "Cisco-*" in the banner).

We probably don't want to have to maintain this patch in Ubuntu indefinitely though. But we could cherry-pick it if upstream commit the patch. Is there a bug filed with openssh upstream?

[Simon Déziel (sdeziel)]

This was fixed upstream according to the changelog.

http://www.openssh.com/txt/release-6.9:

 * ssh(1), sshd(8): cap DH-GEX group size at 4Kbits for Cisco
   implementations as some would fail when attempting to use group
   sizes >4K; bz#2209

HTH,
Simon

[Launchpad Janitor (janitor)]

This bug was fixed in the package openssh - 1:6.9p1-1

---------------
openssh (1:6.9p1-1) unstable; urgency=medium

  * New upstream release (http://www.openssh.com/txt/release-6.8):
    - sshd(8): UseDNS now defaults to 'no'. Configurations that match
      against the client host name (via sshd_config or authorized_keys) may
      need to re-enable it or convert to matching against addresses.
    - Add FingerprintHash option to ssh(1) and sshd(8), and equivalent
      command-line flags to the other tools to control algorithm used for
      key fingerprints. The default changes from MD5 to SHA256 and format
      from hex to base64.
      Fingerprints now have the hash algorithm prepended. An example of the
      new format: SHA256:mVPwvezndPv/ARoIadVY98vAC0g+P/5633yTC4d/wXE
      Please note that visual host keys will also be different.
    - ssh(1), sshd(8): Experimental host key rotation support. Add a
      protocol extension for a server to inform a client of all its
      available host keys after authentication has completed. The client
      may record the keys in known_hosts, allowing it to upgrade to better
      host key algorithms and a server to gracefully rotate its keys.
      The client side of this is controlled by a UpdateHostkeys config
      option (default off).
    - ssh(1): Add a ssh_config HostbasedKeyType option to control which host
      public key types are tried during host-based authentication.
    - ssh(1), sshd(8): Fix connection-killing host key mismatch errors when
      sshd offers multiple ECDSA keys of different lengths.
    - ssh(1): When host name canonicalisation is enabled, try to parse host
      names as addresses before looking them up for canonicalisation. Fixes
      bz#2074 and avoids needless DNS lookups in some cases.
    - ssh(1), ssh-keysign(8): Make ed25519 keys work for host based
      authentication.
    - sshd(8): SSH protocol v.1 workaround for the Meyer, et al,
      Bleichenbacher Side Channel Attack. Fake up a bignum key before RSA
      decryption.
    - sshd(8): Remember which public keys have been used for authentication
      and refuse to accept previously-used keys. This allows
      AuthenticationMethods=publickey,publickey to require that users
      authenticate using two _different_ public keys.
    - sshd(8): add sshd_config HostbasedAcceptedKeyTypes and
      PubkeyAcceptedKeyTypes options to allow sshd to control what public
      key types will be accepted (closes: #481133). Currently defaults to
      all.
    - sshd(8): Don't count partial authentication success as a failure
      against MaxAuthTries.
    - ssh(1): Add RevokedHostKeys option for the client to allow text-file
      or KRL-based revocation of host keys.
    - ssh-keygen(1), sshd(8): Permit KRLs that revoke certificates by serial
      number or key ID without scoping to a particular CA.
    - ssh(1): Add a "Match canonical" criteria that allows ssh_config Match
      blocks to trigger only in the second config pass.
    - ssh(1): Add a -G option to ssh that causes it to parse its
      configuration and dump the result to stdout, similar to "sshd -T".
    - ssh(1): Allow Match criteria to b...

[Prasad (prasad-redhat-bugs)]

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@192.168.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.

[Jakub (jakub-redhat-bugs)]

Hello Prasad,
Can you provide full verbose log from your attempt?

    ssh -vvv root@192.168.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.

[Prasad (prasad-redhat-bugs)]

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: <email address hidden>,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: <email address hidden>,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: <email address hidden>,rsa-sha2-512,rsa-sha2-256,ssh-rsa,<email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
debug2: ciphers ctos: <email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr,<email address hidden>,<email address hidden>,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: <email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr,<email address hidden>,<email address hidden>,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: <email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,<email address hidden>,hmac-sha2-256,hmac-sha2-512,hm...

[Jakub (jakub-redhat-bugs)]

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

[Prasad (prasad-redhat-bugs)]

I have tried this option. But I can not use it. Is there any way I can patch the openSSH_7.2p2.

[Prasad (prasad-redhat-bugs)]

@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