11 April,19 at 11:50 AM
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:
Server Suite |
CentrifyDC Version |
Centrify-OpenSSH base version |
2013 |
5.1.0 |
6.0p1 |
2013.3 |
5.1.2 |
6.2p2 |
2015.1 |
5.2.3 |
6.7p1 |
2016 |
5.3.0 |
7.1p1 |
2016.1 |
5.3.1 |
7.2p2 |
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,
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,
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