Novell is now a part of Micro Focus

My Favorites

Close

Please to see your favorites.

ssh and sftp client failures after updating openssh package

This document (7016904) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 12 Service Pack 1 (SLES 12 SP1)
SUSE Linux Enterprise Server 12 (SLES 12)
SUSE Linux Enterprise Server 11 Service Pack 4 (SLES 11 SP4)
SUSE Linux Enterprise Server 11 Service Pack 3 (SLES 11 SP3)

Situation

After updating the openssh package via public maintenance from Sept / October 2015, the ssh or sftp command-line clients may fail to connect to a third party SSHD server, giving the following error before a password prompt is displayed:
 
DH_GEX group out of range: 1536 !< 1024 !< 8192
Couldn't read packet: Connection reset by peer

or

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.
 
The 3rd party ssh server or client is usually not SLES, and is often not under the control of the user/organization experiencing the error.
 
On even newer versions of openssh, the range numbers might instead be:
 
2048 !< 1024 !< 8192

Resolution

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 to will 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:

-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

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:
 
KexDHMin=1024

 
Other options:
 
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.


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

Cause

A change was made to the openssh package, dealing with Diffie-Hellman Group Exchange.  Previously, keys of size 1024 - 8192 could be exchanged.  The minimum was raised to 1536 (and later to 2048) for added security and to avoid the "logjam" vulnerability.  However, if used with some 3rd party ssh implementations which only support 1024, failure will occur.  Ideally, the 3rd party ssh configuration or code should be updated to use larger key sizes.
 
(NOTE:  This key exchange does not refer to public/private key pairs.)

Additional Information

For information purposes, the history of changes connected with this issue are listed below:
 
SLES 12 SP1:
SP1's openssh initially expected a minimum above 1536.  With openssh package version 6.6p1-42, SUSE added the ability for the ssh/sftp client to configure the minimum back to 1024.  With 6.6p1-52, configuring the sshd server back to 1024 also was added.
 
SLES 12:
6.6p1-24.1 was the last version of openssh to default to a 1024 minimum.  6.6p1-29.1 raised the requirement to 1536.  With openssh package version 6.6p1-42, SUSE added the ability for the ssh/sftp client to configure the minimum back to 1024.  The ability to configuring the sshd server back to 1024 has not been released, as SLES 12 (SP0) is out of maintenance.
 
SLES 11 SP4:
6.6p1-4.7 was the last version of openssh to default to a 1024 minimum. 6.6p1-13.1 raised the requirement to 1536. With openssh package version 6.6p1-21.1, SUSE added the ability for the ssh/sftp client to configure the minimum back to 1024. With 6.6p1-28.1, configuring the sshd server back to 1024 also was added.
 
SLES 11 SP3:
6.2p2-0.13.1 was the last version of openssh to default to a 1024 minimum.  6.2p2-0.17.1 raised the requirement to 1536.  To get the new settings, both openssh and openssl must be updated, through a special packaget "openssh-openssl1".  This might not be available through normal update channels.  The download page can be found through the following steps:
 
1.  Go to the Patch Finder, at https://download.novell.com/patch/finder/
2.  Select Product:  SUSE Linux Enterprise Server
3.  Select Version:  SUSE Linux Enterprise Server 11 SP3
4.  After a few seconds the list of patches will update.  Find the latest "openssh-openssl1" entries.  There will be several from the same date.
5.  Click on the entries for openssh-openssl1 until you find the right archecture for your system (x86-64, ppc64, etc.)

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.