Re: X forwarding

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Tue, Apr 20, 2004 at 06:22:00AM -0400, der Mouse wrote:
> >> To request X forwarding, the client sends
> 
> >>      byte      SSH_MSG_CHANNEL_REQUEST
> >>      uint32    recipient channel
> >>      string    "fixed-x11-req%rodents.montreal.qc.ca@localhost"
> >>      boolean   want reply
> >>      uint32    token
> >>      uint32    x11 screen number
> 
> > If all the server has to do is repeat the token then what difference
> > does it make?
> 
> It allows the (ssh) client to tell which forwarding request a given
> forwarded X connection corresponds to (and, in particular, allows
> determining which session it goes with - this is cruicial for making X
> forwarding work with connection sharing).

I thought the related channel ID ought to suffice.  

Damien points out a way in which multiple displays could be accessed
from a session channel, and later so do you, so ok, I'll grant the need
for some additional request matching beyond related channel ID.

> >> Upon getting a forwarded X connetion and its passing whatever
> >> security checks, the server generates
> 
> >>      byte      SSH_MSG_CHANNEL_OPEN
> >>      string    "fixed-x11%rodents.montreal.qc.ca@localhost"
> >>      uint32    sender channel
> >>      uint32    initial window size
> >>      uint32    maximum packet size
> >>      uint32    token from the corresponding CHANNEL_REQUEST
> >>      byte[6]   first six bytes of the client X setup packet (the byte
> >>                 order and version numbers)
> > What good does this byte[6] field do?
> 
> It's just the place I chose to put that data.  I'm not fanatical about
> putting it there; if it would make you feel better you could put it at
> the beginning of the channel data, perhaps even with four zero bytes
> and two arbitrary bytes appended so the channel data stream is valid X
> protocol in isolation (I can't really see why this would matter, but I
> infer some such desire from your stating that the (ssh) client will see
> them in the channel data stream despite my trying to clearly state that
> that data blob is _not_ present in the channel data stream).
[...]

You seem to have changed your mind since writing this, so I'll leave it
at this: the protocol is cleaner if this field is removed.

> >>      string    connection method ([...]).
> >>      connection-method-specific data
> >>      for method "tcp":
> >>          string    originator address (e.g. "192.168.7.38")
> >>          uint32    originator port
> > What sorts of decisions do you expect a client to make based on this
> > information (which, after all, the client has to trust the server to
> > be honest about)?
> 
> None in particular.  Why do you assume that making decisions based on
> that information is the only reason to pass it?  I have no trouble
> imagining the (ssh) client maintaining some kind of user-interface
> display of forwarded X connections, in which case displaying where the
> connection is from could be good.

Ok.  I agree that it could be useful to have this info, but if it's
meant to be displayed and not interpreted by software, then we don't
need to worry about structuring the different transports'
address/instance data types and instead can just get away with a
free-form string.

> > What about multiply-forwarded display?  How could the server know?
> > Does it matter?
> 
> I sure hope it doesn't matter, because I don't think it can know, at
> least not for the TCP case.

Right.

> > BTW, the terms "client" and "server" are very confusing here.
> 
> Yes.  I've been trying to indicate which is which when I think
> confusion is likely, though I've doubtless missed some cases.

You've been doing ok, but other readers probably could use that
clarification.

> >>      string    "cancel-x11-req%rodents.montreal.qc.ca@localhost"
> >> [...wildcarding...]
> 
> > Can there be more than one X11 display forwarded per-session channel?
> 
> The (ssh) client certainly can send more than one X forwarding request
> for a session.  What happens if it does is a good question, especially
> for OSes like most Unices that communicate X display information to X
> clients via something which (like $DISPLAY) can't handle more than one
> display - I suspect it would have to be left up to the implementation.
> (My own implementation, as it stands now, rejects all but the first; I
> may, when I implement cancels, allow a forwarding request whenever
> there are no uncancelled forwarding requests on that session.)

Ok.

There is a caveat here that has to be mentioned in any I-D text about
this: for many SSHv2 servers the x11 fwd channel request has to arrive
prior to starting the session, so clients SHOULD strive to ensure this.

Nico
--