Re: SFTP v6?

[nisse%lysator.liu.se@localhost (Niels Möller)]

Joseph Galbraith <galb-list%vandyke.com@localhost> writes:

> Niels Möller wrote:

> > The sftp client asks the lower layer (ssh connection) for a session
> > channel, and asks it to start the sftp subsystem. And it sometimes
> > does that twice. But it's identical both times, no "private data"
> > involved.
> 
> But in order for kludge mode to work, the second time
> it starts the sftp subsystem, it has to pass down
> the server version it got from the first attempt.  (So
> that the second time around the client can send the
> version that will have the server pick the right version.)

I'd tend to include the sftp version negotiation in the sftp "layer".
The lower layer, connection, provides a way for the upper layer (sftp)
to open a channel and request a subsystem. But all data transmission
on the channel, including the sftp version exchange, is the upper
layer's (i.e. sftp's) job. The lower layer doesn't know *anything*
about the protocol used on the channel, not even the version used.

>From this point of view, I see no problem with the interface.

> >>4. When a version negotiation failure occurs, both sides
> >>    know why, because they both have the same information.

> I tried to change the version negotiation back when
> I first started editing sftp so that the server sent
> back it's version (V_S rather than V_U)... which
> at least gives the server something valid to send
> when version negation fails, but we had to back
> it out because of backwards compatibility.

One simple idea: In this failure case, server version 6, client
version 4 (say), is there any good reason the server can't send
version 6 in its SSH_FXP_VERSION, before disconnecting? That would
give the client at least some clue. It could reasonably interprete
this response as "This server doesn't seem to support versions below
6", and tell that to the user.

Regards,
/Niels