Couldn't read packet: Connection reset by peer
DH_GEX_REQUEST, bad parameters: 1536 !< 1024 !< 8192 [preauth]
Alternatively, 3rd party clients may fail to connect to a SLES sshd server, and the sshd log may show the same range error.
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 SUSE ssh/sftp client is connecting to a 3rd party SSH server, updates and configuration options have been added which allow a return to the previous behavior.
For SLES 12 or SLES 12 SP1, update to openssh 6.6p1-42 or higher.
On SLES 11 SP4, update to openssh 6.6p1-21.1 or higher.
On SLES 11 SP3, update to openssh-openssl16.6p1-15.1 or higher. (See Additional Info section below.)
With those versions, the ssh/sftp client will accept a command-line option to lower the kex size back to 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:
However, putting it in the ssh_config file is not recommended, as it lowers the minimum for all the client's sessions, not just one. The only benefit of putting it in the file is to relieve the user of having to remember and type the option on the command line.
2. For cases where a 3rd party ssh client is connecting to a SLES sshd server daemon, the same configurable setting (but for /etc/ssh/sshd_config) has been released, in a later version.
For SLES 12 SP1, update to openssh 6.6p1-52 or higher.
For SLES 11 SP4, update to openssh 6.6p1-28.1 or higher.
For SLES 11 SP3, update to openssh-openssl1 6.6p1-15.1 or higher. (See Additional Info section below.)
After these updates, it is possible to configurd /etc/ssh/sshd_config with:
3. Check the ssh client or server on the 3rd party device, and see if there are configuration settings or software updates availble which would raise the key exchange size used there to 2048 or higher.
4. ssh can be told to use a certain key exchange algorithm to avoid this issue. Use "diffie-hellman-group14-sha1".
For a command-line *client* to be told to use that, it is usually done with a -o parameter, i.e.
(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:
#Note: this will cause sshd server to support fewer Kex Algorithms than it does by default.