OpenSSH 6.7 will bring socket forwarding and more

The next stable release of OpenSSH, version 6.7, is slated to arrive soon. In addition to the usual bevy of fixes and updates, this release will introduce several new features, and it will be the first release to showcase the project's efforts to refactor the OpenSSH codebase.

Damien Miller put out a call for testing on August 18, asking users to give the "portable" version (that is, the releases not intended for OpenBSD) of the latest OpenSSH snapshots a spin on a variety of platforms. As is usually the case, the new release features several changes to the suite of available ciphers and algorithms (including some removals as well as adjustments to the default settings). But there are also several brand-new additions to OpenSSH functionality that will debut with the upcoming release.

Features

Among the new features is support for Unix domain socket forwarding. This feature allows a Unix domain socket on the local machine to be forward to a remote TCP port, or a remote TCP port to be forwarded to a local Unix domain socket—using the same syntax that OpenSSH supports for forwarding to TCP ports. For example, a remote PostgreSQL database instance could be connected over a secure SSH channel to a Unix domain socket on the local machine with ssh -L/tmp/foo.sock:mydatabase.net:5432 someserver. It is also possible to connect two local Unix domain sockets over an SSH connection.

Several years ago, this functionality was available in a patch set by William Ahern. The last update to Ahern's code, however, was made in 2012 for OpenSSH 6.1. The new feature is a reimplementation of the same work.

A related feature was added to support the Unix domain-socket forwarding. The escape sequence %C can be used in both the LocalCommand and ControlPath arguments of a configuration file. It expands to a unique identifier derived from the SHA-1 hash of (local host, remote user, hostname, port). The other escape sequences (such as %h for remote hostname and %u for local username) are often used with the expectation that, when expanded, they will comprise a unique identifier. However, the addition of Unix domain sockets meant that some possible use cases were bumping up against system pathname maximum lengths (UNIX_PATH_MAX); the hash value of %C is a workaround, providing a fixed-length (40-character) identifier, although it certainly may prove useful in other circumstances as well.

The new release will also expand OpenSSH's support for looking up SSH key fingerprints through DNS. OpenSSH's support for the DNS SSH Fingerprint Publishing (originally described in RFC 4255) included Elliptic Curve DSA (ECDSA) keys (described in the RFC 6594 extension). Version 6.7 will also support keys generated with Ed25519. The Ed25519 keys are not yet described in an official IETF RFC (although there is a draft under development). As the name probably makes clear, the new key type is derived from Daniel J. Bernstein's highly optimized Curve25519, which has been the basis of so much recent cryptography work.

Fixes

Several smaller but still noteworthy changes in 6.7 include the ability to resume interrupted uploads in SFTP connections, a configuration parameter administrators can set to disable the execution of per-user ~/.ssh/rc configuration files, and more informative failure messages (logging user, source address, and port for authentication failures). There are also several bugfixes that may be of interest to some users, such as the fix for a bug that would mistakenly rewrite localhost IP addresses in port-forwarding requests.

Undoubtedly of more general interest, though, are the fixes that target unsafe algorithms and options. Three such fixes are mentioned explicitly in Miller's call-for-testing email. First, RC4 and Cipher-block chaining (CBC) mode have both been removed from the default set of available ciphers and message-authentication code algorithms in sshd. They are now considered unsafe; users who need them for backward-compatibility purposes can re-enable them with sshd_config.

Second, support for TCP wrappers (and the libwrap library) is being removed. Miller noted on the development list in April that the same functionality was already available through sshd_config's Match keyword—and, more importantly, using Match is both more flexible and (because it removes an external dependency) safer for the project in the long run. During the April discussion, it was suggested that patching libwrap support back into OpenSSH 6.7 should be doable without too much trouble, in case there are users who feel they cannot transition to a non-libwrap setup.

Finally, OpenSSH 6.5 and 6.6 both suffered from a bug that would occasionally cause connection failures when using the curve25519-sha256@libssh.org key-exchange method. As a result, version 6.7 disables that key-exchange method when it connects to either of the affected older releases. Unlike the other two backward-incompatible fixes, however, there is no workaround in place for OpenSSH 6.7—though why one would want to reintroduce a bug that intermittently caused connection failures is difficult to imagine.

(Re) Factoring

In addition to the new features and bugfixes, version 6.7 will mark the first release to come from the OpenSSH project's effort to refactor the codebase—with the eventual goal of separating out the core functionality from the client and server code, thus making an OpenSSH library available for use by other applications. The 6.7 release will not be usable in such a "libopenssh" manner; however, it is a first step along the path. The wire-parsing, key-handling, and key-revocation list code has been refactored in time for the new release. The API those components use, though, is far from stable and should not be targeted by other applications.

The eventual goal of the refactoring work is to spare outside applications from having to fork a separate process in order to use OpenSSH functionality. That would make OpenSSH a viable alternative to some existing libraries like libssh. And there are a lot of potential uses for such a library—everything from rsync to SSHFS can make use of SSH tunneling, and OpenSSH is the de facto option for many users. Furthermore, the idea itself is quite old within OpenSSH; the first bug report to request it was opened in 2002.

The project has not set any sort of timeline for when a library version might debut. At the moment, the refactoring process is still going on, although there are unit tests and fuzz tests in the codebase, so interested users can do some experimentation.

Neither is there a release date set yet for OpenSSH 6.7 itself, of course. It will be released when ready. But when it does arrive, the availability of SSH-tunneled Unix domain sockets (along with the rest of the new feature set) will likely establish it as a release many will want to make use of, library or not.