It is recommend to read the "Cause" section of this document before deciding on a course of action. In some cases, the ideal solution may be to change the 3rd party side.

Various options to address this are:

1. For cases where a SLES ssh client connecting to a 3rd party ssh server are encountering this error, updates and configuration options will allow a return to the previous behavior.

On SLES 12 or SLES 12 SP1:

Verify that the openssh package is 6.6p1-42 or higher.

On SLES 11 SP4:

Verify that the openssh package is 6.6p1-21.1 or higher.

With those versions, the ssh/sftp client will accept a command-line option to lower the kex size back to 1024:

-o KexDHMin=1024

At this size, 3rd party ssh servers who do not support higher kex sizes should accept the session. However, at that size, the session may be less secure.

Alternatively, instead of putting this option on the ssh or sftp client command line, it can be put in the client configuration file, /etc/ssh/ssh_config, as:

KexDHMin=1024

For a command-line *client* to be told to use that, it is usually done with a -o parameter, i.e.

-o KexAlgorithms=diffie-hellman-group14-sha1

(This setting, without the -o, could alternatively be put in /etc/ssh/ssh_config)

For a Linux sshd (server daemon), it would be set in /etc/ssh/sshd_config, as:

KexAlgorithms=diffie-hellman-group14-sha1

#Note: this will cause sshd server to support fewer Kex Algorithms than it does by default.