What is new in OpenSSH 7.4 (in RHEL 7.4)?

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

Red Hat Enterprise Linux 7 (RHEL 7) so far has been providing iterations of OpenSSH 6.6.1p1, first released in 2014. While we've kept it updated against vulnerabilities, many things have changed both in security requirements and features provided by the latest OpenSSH. Therefore, OpenSSH has now been updated to the recently released OpenSSH 7.4p1, which brings many new features and security enhancements. For the complete set of changes and bugfixes, please refer to the upstream release notes.

New features

This OpenSSH client and server rebase brings on many new and useful features. The most prominent ones are described below.

Host Key Rotation

Setting up a new system accessed by SSH, or generating new server host keys which satisfy new security requirements, was a complicated task in the past. New keys had to be distributed to all users and swapped in the server configuration atomically, otherwise users would see scary warnings about possible MITM attack. This update addresses that problem by presenting all the host keys to connecting clients, allowing for a smooth transition between old and new keys.

This functionality is controlled by the client configuration option UpdateHostKeys. When the value is set to yes or ask, the client will request all the public keys present on the server (with OpenSSH 6.8 and newer) and store them in the known_hosts file. These keys are transferred using the encrypted channel and the client verifies the signatures from the server, therefore this operation does not require explicit user verification, assuming the previously used host key is already trusted.

$ ssh -o UpdateHostKeys=ask localhost
Learned new hostkey: RSA SHA256:5oa3j5qave0Tz2ScovK084zqtgsGy0PeZfL8qc7NMtk
Learned new hostkey: ED25519 SHA256:iZG0mDh0JZaPrQ+weGEEyjfN+qL9EDRxrffhqzoAFdo
Accept updated hostkeys? (yes/no): yes
Last login: Wed May  3 16:29:38 2017 from ::1

New SHA256 Fingerprint Format

As can be seen in the previous paragraph, OpenSSH moved away from MD5-based fingerprints to SHA256 ones. The new hash is longer and therefore it is represented in base64 format instead of the colon-separated hexadecimal pairs. The fingerprint format can be specified using the FingerprintHash configuration option in ssh_config, or with -E switch to ssh-keygen. In most places both hashes are shown by default (SHA256 and MD5) for backward compatibility:

$ ssh example.org
The authenticity of host 'example.org (192.168.0.7)' can't be established.
ECDSA key fingerprint is SHA256:kmtPlIwHZ4B68g6/eRbDTgC2GD0QnmrjjA0MjOB3/HY.
ECDSA key fingerprint is MD5:57:01:87:16:7a:a8:24:60:db:9e:05:3f:a0:78:aa:69.
Are you sure you want to continue connecting (yes/no)? yes

Other tools require an explicit command line option to provide the old fingerprint format:

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
256 SHA256:kmtPlIwHZ4B68g6/eRbDTgC2GD0QnmrjjA0MjOB3/HY no comment (ECDSA)
$ ssh-keygen -l -E md5 -f /etc/ssh/ssh_host_rsa_key.pub
256 MD5:57:01:87:16:7a:a8:24:60:db:9e:05:3f:a0:78:aa:69 no comment (ECDSA)

Simplified connection using intermediate hosts

There is a new configuration option ProxyJump, and command line switch -J, which significantly simplifies the configuration and connection to servers in private networks behind a jump box.

In the past, there was only the ProxyCommand option, which covered many use cases though it was complex to use. It required a configuration as follows:

Host proxy2
  ProxyCommand ssh -W %h:%p -p 2222 user@proxy
Host example.com
  ProxyCommand ssh -W %h:%p user2@proxy2

The new ProxyJump configuration syntax is simpler, and makes it very easy to write even longer chains of connections. For example:

Host example.com
  ProxyJump user@proxy:2222,user2@proxy2

The same as above can also be simply specified ad-hoc on the command-line:

$ ssh -J user@proxy:2222,user2@proxy2 example.com

UNIX domain socket forwarding

Previously, OpenSSH allowed only TCP ports to be forwarded in SSH channels. Many applications today are using UNIX domain sockets instead, so OpenSSH implemented support for them. You can forward a remote socket to a local one, the other way round, or even UNIX domain socket to TCP socket, and it is not more complicated than standard TCP forwarding. Just replace hostname:port values with paths to UNIX domain sockets.

For example, the remote MariaDB socket can be forwarded to the local machine and allow secure connection to this database:

$ ssh -L /tmp/mysql.sock:/var/lib/mysql/mysql.sock -fNT mysql.example.com
$ mysql -S /tmp/mysql.sock

New default cipher ChaCha20-Poly1305

Although the ChaCha20-Poly1305 cipher was available in the older OpenSSH versions, it is now prioritized over other ciphers since it is considered mature enough with reasonable performance. It is a cipher of the Authenticated Encryption with Associated Data (AEAD) form which combines the MAC algorithm (Poly1305) with the cipher, similar to AES-GCM. The cipher is automatically used when connecting to RHEL7 servers1, but the connection to other servers will still use other supported ciphers.

Improvement in ssh-agent connection

So far, identity management in ssh-agent (e.g. adding of the SSH keys in ssh-agent) is handled by the ssh-add tool. This must be used prior to connecting to a remote server using ssh.

It can come in handy to add and decipher the required keys on demand while connecting to a remote server. For that, the option AddKeysToAgent in ssh_config will either add all the used keys automatically or prompt to add new keys that are being used. In combination with the -t switch in ssh-agent, specifying a key's lifetime, it is a simple and secure alternative to storing your keys in ssh-agent indefinitely.

Furthermore, the ssh-agent connection socket can now be specified in ssh_config using IdentityAgent, which removes quite a lot of the struggle starting the ssh-agent properly and passing the environment variables to existing processes. For example, the following snippet in ~/.bashrc will start the agent, and added keys will have a default lifetime of 10 hours:

SOCK=/tmp/username/ssh-agent.sock
SOCK_DIR=`dirname $SOCK`
[ -d "$SOCK_DIR" ] || mkdir -m700 $SOCK_DIR
[ -f "$SOCK" ] || eval `ssh-agent -a "$SOCK" -t 10h`

The corresponding configuration in ~/.ssh/config will contain the following lines:

IdentityAgent /tmp/username/ssh-agent.sock
AddKeysToAgent yes

Security-related changes

Over the years, there were many changes upstream regarding security. With this update we are trying to preserve backward compatibility, while removing (potentially) broken algorithms or options that were still available in the current OpenSSH available in Red Hat Enterprise Linux 7.

Not using SHA-1 for signatures by default

The original SSH protocol in RFC 4253 only defines RSA authentication signatures using the SHA-1 hash algorithm. As SHA-1 is no longer considered safe, the protocol has been extended in draft-ietf-curdle-rsa-sha2 to allow SHA-2 algorithms along with RSA signatures. This extension is negotiated automatically when connecting to servers running OpenSSH 7.2 and newer. It can be verified that the new hash algorithm is used from the debug log as follows:

debug2: KEX algorithms: [...],ext-info-c
[...]
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
[...]
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279

SSH-1 server removed

The obsolete SSH-1 server code was removed from OpenSSH. The complete announcement can be found in this knowledgebase article.

As with previous RHEL 7 releases, connections from clients to existing SSH-1 servers are still possible, and require the use of -1 switch or the use the following configuration:

Host legacy.example.com
  Protocol 2,1

Seccomp filter for privilege separation sandbox

The OpenSSH server in RHEL is now built with seccomp filter sandbox, which is enabled by default. In previous versions, the rlimit method was used to limit resources available for a network-facing process. The seccomp filter allows only a very limited list of system calls from this process, reducing the impact of a compromise. That sandbox can be turned off in /etc/ssh/sshd_config by setting:

UsePrivilegeSeparation yes

Removed support for pre-authentication compression

Historically, compression in network protocols was recommended in order to increase encryption performance and reduce the amount of data available to an adversary.

Given statistical attacks and the fact that compression in combination with encryption increases code complexity and attack surface, enabling compression with encryption today is mostly seen as a security liability, underlined by issues such as CVE-2016-10012.

The compression option was disabled in OpenSSH server for more than 10 years, and on this release, it is completely removed.

Deprecation of insecure algorithms

Following up with Deprecation of Insecure Algorithms in RHEL 6.9, legacy algorithms that potentially pose a more serious threats to deployments are being disabled. That, in RHEL 7.4, affects the RC4 ciphers, as well as MD5, RIPE-MD160, and truncated SHA-1 MACs on both client and server side. The ciphers Blowfish, Cast128, and 3DES were removed from the default set of algorithms accepted by the client but are still supported in the server.

If these algorithms are still needed for interoperability with legacy servers or clients, they can be enabled on a per-host basis as described in the upstream documentation. The following example describes how to enable 3des-cbc cipher in a client:

Host legacy.example.org
  Ciphers +3des-cbc

Another example, enabling hmac-md5 in a server for legacy.example.org client:

Match Host legacy.example.org
  MACs +hmac-md5

Conclusion

The new OpenSSH in RHEL 7.4 comes with many bug fixes and features that might affect your everyday work and that are worth using. Engineering has worked very hard to maintain the backward compatibility with previous versions while improving the security defaults at the same time. If you feel any regressions have been missed please contact Red Hat Support.