Jan Pechanec's weblog

We admit that SunSSH versioning could have been more helpful during the last few years. However, there were a few good reasons for the fact that the version number hasn't changed much:

• SunSSH is not a separate product but part of several Solaris releases
• if you want to track what exactly your SunSSH binaries support or what fixes have been integrated the proper way is to read the manual pages and look up what Change Requests (CRs) were integrated into the particular release of OpenSolaris, or patch and update releases of Solaris 10 and Solaris 9
• SunSSH versions are used internally, they are not officially used as an indicator of what it actually supported, implemented, or fixed

On the other hand, there are rules behind SunSSH versioning which might be used as a short cut to quickly get some information about the SunSSH binaries. And there is no reason why not to let you know what are those.

Disclaimer: please note that the SunSSH versioning is for internal use only and while we don't plan to change current rules we can't guarantee it will not happen in the future. We provide this information in hope that it might be useful to you. If in doubt, please use official release notes and/or other official sources of information.

Purpose of the version of an SSH application

$ ssh -V
Sun_SSH_1.2, SSH protocols 1.5/2.0, OpenSSL 0x0090801f

The important part of the version output above is "Sun_SSH_1.2". As stated in RFC 4253, the Secure Shell (SSH) Transport Layer Protocol, the SSH application name plus its version is an important information for the peers to trigger compatibility extensions and to indicate the capabilities of an implementation. So, it's a way that helps to workaround various bugs of known SSH implementations. Together with the SSH protocol version number it forms something called a version string, defined in the same document. The version string are the first bytes sent when initiating a new SSH connection:

$ nc localhost 22
SSH-2.0-Sun_SSH_1.2

See compat.c file to better understand what I mean. There are regular expressions representing various versions of existing SSH implementations together with flags set when such an implementation is encountered. Those flags are later used in the code to workaround various issues in the peer's implementations of the SSH protocol.

So, for example, when we fixed a glitch in treating a special 0.0.0.0 address, tracked by 6619347 SunSSH is not fully compatible with RFC4254 with regard to port forwarding, and introduced a new compatibility flag SSH_OLD_FORWARD_ADDR according to a fix in OpenSSH, we bumped up SunSSH version to 1.2 so that old SunSSH clients could be treated in a backward compatible way. The version number bore no other information other than for those compatibility shims. Especially it didn't say much about supported features - for some time SunSSH in Nevada and S10 had the same 1.1 version while Nevada version supported many new features missing from S10.

Version as a feature indicator

With other SSH implementations that are released as a separate product the version serves much as a feature indicator, used to recognize what a particular version implements. As noted in the first paragraph we can hardly do that since the development model of SunSSH is different. Of course, if a security bug is found it's very easy, after the bug is fixed, to release a new version of that SSH application even if there was nothing else new than the security bug fix. In that case, the version number serves as an important security indicator as well.

Version as a security indicator

Up until recently we were changing the SunSSH version only if a problem in the SSH protocol implementation was fixed, following RFC 4253. However, we had a few discussions mostly during the last year where people complained that the version string doesn't give them any information about whether a particular security vulnerability was fixed there or not. As already noted we can hardly employ similar versioning as OpenSSH does since we don't release SunSSH as such but as part of Solaris systems. Also, when backporting fixes to S10 and S9 we backport individual CRs, not all features for one particular version.

The thing we can do and what we internally have decided to do, in addition to situations when we fix the protocol implementation, is to bump up a version every time a security vulnerability is fixed, too. That together with the information what security bug was fixed as part of the exact version should give some more information that can be quickly checked. It's not 100% straightforward though - see the list of current SunSSH versions (taken from the official SunSSH homepage):

• 1.0 - initial version which was based on OpenSSH 2.3 and integrated into Solaris 9
• 1.0.1 - backport of SSH_BUG_EXTEOF compatibility flag from OpenSSH (S9 only).
• 1.1 - our changes and fixes were reapplied and some new code added using OpenSSH 3.5p1 as a base version. This version was integrated into Solaris 10 from its beginning.
• 1.2 - SSH_OLD_FORWARD_ADDR compatibility flag resynced from OpenSSH and integrated into Nevada build 77.

Now imagine that we fix a security or a protocol bug in the latest SunSSH Nevada code and that the bug is in S10 and S9 as well, which have version 1.1 at this point. So, we could use 1.3 version number in Nevada. And now we have a problem - what version should it be in S10?

• it can't be 1.3 since that would mean that the code has a fix that bumped up the version in Nevada to 1.2 which is not true
• it can't be 1.2 since that already means something else

The only reasonable solution we seem to have is that we must add a new number level for S10 and S9. Well, it's not a big issue as long as it can be found what version is what. So, the way we decided to go would be to use 1.1.1 there. Note that if we later backported above mentioned 6619347 to S10 we would change 1.1.1 directly to 1.3.

12/2008: SunSSH 1.3

A new security vulnerability reported by UK researches in November 2008 and described in CPNI-957037 is the reason why I wrote this blog entry. For the first time we increased SunSSH version in OpenSolaris just because of a security vulnerability, to 1.3. The fix has been integrated into the OpenSolaris code base and the backport is under way, with patches expected, and the version in S10 and S9 will be 1.1.1.

Conclusion

This blog entry explains that we have revisited the way we internally use version numbers in SunSSH. From now on (but see the disclaimer), we bump up a version if:

1. a fix in SSH protocol implementation is integrated
2. a security vulnerability is fixed

Such fixes form a set of CRs and that alone determines a version number. No matter what version of Solaris system is that or what other features or bug fixes that particular SunSSH code has integrated, the same sets must lead to the same version number, and different sets must have a different one. That means that a security vulnerability X that triggers a SunSSH version in OpenSolaris to, say, 1.D, (the same fix for X in S10) may change the version in S10 to, say, 1.B.1 if a Nevada bug fix triggering 1.C wasn't backported to S10 yet. The missing fix with 1.C would be the reason we couldn't call S10's version a true 1.D. I don't want to get into details but this algorithm indicates that if fixes from S10 are not backported to S9 in order, or not all of them, we can have up to 4 numbers in the version number there.

Does it seem too complicated? It's not that bad and anyway, don't worry, all existing versions of SunSSH should be mentioned on the OpenSolaris SunSSH page.