What is new in OpenSSH 7.x?

OpenSSH 7.0 came up with a lot of improvement and several new features, but more importantly it came up with several deprecated functionalities around cryptography. This came as a long wait from the community but may have impact on your environment if you were using these removed functionalities.

Below an extract of what can be found in the OpenSSH 7.0 release notes:

Future deprecation notice

=========================

We plan on retiring more legacy cryptography in the next release

including:

 * Refusing all RSA keys smaller than 1024 bits (the current minimum

   is 768 bits)

 * Several ciphers will be disabled by default: blowfish-cbc,

   cast128-cbc, all arcfour variants and the rijndael-cbc aliases

   for AES.

 * MD5-based HMAC algorithms will be disabled by default.

This list reflects our current intentions, but please check the final

release notes for OpenSSH 7.1 when it is released.

And below an extract of the OpenSSH 7.1 release notes:

Future deprecation notice

=========================

We plan on retiring more legacy cryptography in the next release

including:

 * Refusing all RSA keys smaller than 1024 bits (the current minimum

   is 768 bits)

 * Several ciphers will be disabled by default: blowfish-cbc,

   cast128-cbc, all arcfour variants and the rijndael-cbc aliases

   for AES.

 * MD5-based HMAC algorithms will be disabled by default.

This list reflects our current intentions, but please check the final

release notes for OpenSSH 7.2 when it is released.

Finally, find below an extract of the OpenSSH 7.2 release notes:

Future deprecation notice

=========================

We plan on retiring more legacy cryptography in a near-future

release, specifically:

 * Refusing all RSA keys smaller than 1024 bits (the current minimum

   is 768 bits)

This list reflects our current intentions, but please check the final

release notes for future releases.

Potentially-incompatible changes

================================

This release disables a number of legacy cryptographic algorithms

by default in ssh:

 * Several ciphers blowfish-cbc, cast128-cbc, all arcfour variants

   and the rijndael-cbc aliases for AES.

 * MD5-based and truncated HMAC algorithms.

These algorithms are already disabled by default in sshd.

To get more details, find the link to the official release notes of OpenSSH 7.x:

https://www.openssh.com/txt/release-7.0

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

https://www.openssh.com/txt/release-7.2

The most direct impact on your environment is the possibility to see SSH Key authentication stop working due to RSA private keys too short.

Another issues with SSH Key authentication is that if the SSH client is trying to negotiate a secret key with a deprecated algorithm, then the SSH Server will drop the connection as both client and server can’t agree on the Tunnel encryption key (Key Exchange handshake).

What is the relation with Centrify-OpenSSH?

Centrify-OpenSSH is built using OpenSSH community sources and modified to guarantee Single-Sign On authentication using Kerberos (Microsoft implementation), but also to add Centrify Server Suite features support by allowing backend communication with the Agent (e.g. SSH rights, Multi-Factor Authentication).

The version of OpenSSH shipped with Centrify Server Suite is described in the KB-7535. An extract of this KB below:

Why should you care?

So you may notice that since Centrify Server Suite 2016, the version of Centrify-OpenSSH is built from either OpenSSH 7.1 or OpenSSH 7.2, but you may not see what is the issue here?

Well, it’s not exactly an issue…

After all, OpenSSH is recognised as much more secure than the precedent versions and upgrading to one of those versions is recommended. Also some OS Vendors like Redhat or SuSE already implemented it as default in their platforms.

However, the indirect issue is that you may not be ready to implement OpenSSH in your environment, because you have SSH Keys generated with old encryption algorithm (like DSA) or not long enough (OpenSSH 7.2 require 1024 bits long keys).

Also if you are not deploying Centrify-OpenSSH on every system (e.g. due to some system that require to keep a stock version), then you may have issue to initiate connection to OpenSSH Servers running Centrify-OpenSSH built with version 7.2p2 as they will most likely not agree on the Key Exchange.

How to avoid authentication issues?

Well, there is several ways to address this, and the best way maybe different from a situation to another.

If you have DSA SSH Keys or RSA SSH Keys shorter than 1024 bits. Then you can decide to,

• Generate new pairs of secure keys using RSA and 1024 bits long keys at minimum

• Modify the sshd_config file to allow usage of old algorithm and short keys by adding the line below to /etc/centrifydc/sshd/sshd_config

PubkeyAcceptedKeyTypes=+ssh-dss

If obviously the first choice should be preferred, it could be needed to temporarily reconfigure SSH Server the time to change all your keys.

If you have Key Exchange issues making the SSH Server dropping the connection, then there is again two options. You could decide to,

• Safely ignore this and simply deploy Centrify-OpenSSH on every server. Doing so will guarantee that both SSH Client and SSH Server are using the same algorithm as they would be all deployed with the same version.

• Modify the sshd_config file to allow usage of old algorithm for Key Exchange by adding the line below to /etc/centrifydc/sshd/sshd_config

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1

Again, it is best to get for first choice, but there will be maybe case where you can’t deploy a new version OpenSSH.

An alternative to add deprecated algorithm support to SSH Server is to specify the algorithm to use on the command line, as described on the linked page below:

https://www.openssh.com/legacy.html