Joseph Galbraith wrote:
> If the client supports non-contigous version, for example, > versions 2,3, and 6, then the INIT/VERSION negotiation > is insufficient. In order to gaurentee a successful > connection, the MUST send the highest version for which > it supports all previos version (because the server > might pick the version the client sends or any > previous version.) > > However, in order to work around this limit in the > deployed protocol implementations, after the > INIT/VERSION exchange is complete, if the version > negotiated is at least 3, the version where extensions was > introduced, the client MAY send the following extension > to attempt to negotiate a higher version:
[snip]
I believe this mechanism maintains backwards compatibility and gives us the version exchange we now wish we'd had originally :-)
I think it is good. Mostly because it serves as a statement that an implementation does not have to support all versions.
I am not sure it will be of any practical benefit in our case, though. While there might be a performance penalty opening and closing and reopening a SFTP sub system if the SFTP server is implemented as a separate executable, this is typically not a concern if the SSH server and the SFTP server run in the same process.
Our server implementation does not launch the SFTP server as a separate process, but either compiles it into the SSH server or uses dynamic loading (dll or so depending on platform). This means that there is only a marginal difference between the two approaches (open-close-reopen vs. open-extended renegotiation) w.r.t. both performance and code size on both the client side and the server side.
My only concern is that server owners who run SSH server software that launches SFTP as a separate executable might not be thrilled about getting a lot of clients that execute the SFTP application twice instead of once in order to get the right protocol version. As I said, it is not a big thing, but bad design choices tend to sum up in the end...