Re: last-call issues..

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

Tero Kivinen <kivinen%mail.niksula.cs.hut.fi@localhost> writes:

> Markus Friedl writes:
> > no. it's an issue of how your sftp-server implementation
> > and your sshd talk to each other. the can exchange as many
> > cookies as they like before speaking the sftp protocol.
> > the sftp _protocol_ does not need to be touched.
> 
> I don't really understand what you are saying above. The
> transport/connection layer client will talk to transport/connection
> layer server. The sftp-client will talk to sftp-server. The
> sftp-client/server will NOT talk to the transport/connection layer
> server nor client.

I think he's saying that if filtering is done at the server end,
clients need not know about it, and it's therefore not a protocol
issue at all.

I agree that using cookies are a real ugly hack for working around
random configuration errors. I can understand that you may want to do
that under some circumstances, but if so, please do on the server end,
in order to localize the ugliness.

> If we make it that way, then each subsystem implementation is tied to
> each connection layer implementation, i.e you cannot take SSH
> Communications Security's sftp-server and run it using lsh server,
> because the lsh does not know which kind of cookies the sftp-server is 
> going to use.

If you just use the first SSH_FXP_VERSION packet as the cookie, that's
no problem (except that lshd doesn't do any filtering).

A different problem is that the server needs to know how to recognize
the start of the real communication for each subsystem. That's a
little painful for those who implement filtering, but I think that is
the price you have to pay in order to keep the clients from knowing
about the ugliness. And it shouldn't be too difficult, you can have a
simple table like

  # Subsystem name  program                         cookie
  sftp              /usr/local/sbin/sftp-subsystem  00000033

and that's all the server needs to know.

/Niels