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.
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
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
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.
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
It can come in handy to add and decipher the required keys on demand while connecting to a remote server. For that, the option
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 connection socket can now be specified in
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
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:
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
Match Host legacy.example.org MACs +hmac-md5
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.
Not when the system is in FIPS140-2 certified mode. ↩
Red Hat Enterprise Linux
Source From: fedoraplanet.org.
Original article title: Red Hat Security: What is new in OpenSSH 7.4 (in RHEL 7.4)?.
This full article can be read at: Red Hat Security: What is new in OpenSSH 7.4 (in RHEL 7.4)?.