Daniel Stenberg wrote:
> Is it really necessary to do it that way just to get X11 forwarding
> to work?

--8<-- rfc4251.txt, Page 24
Implementers of the X11 forwarding protocol SHOULD implement the
magic cookie access-checking spoofing mechanism, as described in
[SSH-CONNECT], as an additional mechanism to prevent unauthorized use
of the proxy.
-->8--

--8<-- rfc4254.txt 6.3. X11 Forwarding, Page 10-11
6.3.  X11 Forwarding

6.3.1.  Requesting X11 Forwarding

   X11 forwarding may be requested for a session by sending a
   SSH_MSG_CHANNEL_REQUEST message.

      byte      SSH_MSG_CHANNEL_REQUEST
      uint32    recipient channel
      string    "x11-req"
      boolean   want reply
      boolean   single connection
      string    x11 authentication protocol
      string    x11 authentication cookie
      uint32    x11 screen number

   It is RECOMMENDED that the 'x11 authentication cookie' that is sent
   be a fake, random cookie, and that the cookie be checked and replaced
   by the real cookie when a connection request is received.

   X11 connection forwarding should stop when the session channel is
   closed.  However, already opened forwardings should not be
   automatically closed when the session channel is closed.

   If 'single connection' is TRUE, only a single connection should be
   forwarded.  No more connections will be forwarded after the first, or
   after the session channel has been closed.

   The 'x11 authentication protocol' is the name of the X11
   authentication method used, e.g., "MIT-MAGIC-COOKIE-1".

   The 'x11 authentication cookie' MUST be hexadecimal encoded.

   The X Protocol is documented in [SCHEIFLER].

6.3.2.  X11 Channels

   X11 channels are opened with a channel open request.  The resulting
   channels are independent of the session, and closing the session
   channel does not close the forwarded X11 channels.

      byte      SSH_MSG_CHANNEL_OPEN
      string    "x11"
      uint32    sender channel
      uint32    initial window size
      uint32    maximum packet size
      string    originator address (e.g., "192.168.7.38")
      uint32    originator port

   The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION
   or SSH_MSG_CHANNEL_OPEN_FAILURE.

   Implementations MUST reject any X11 channel open requests if they
   have not requested X11 forwarding.
-->8--


> Or perhaps the question should rather be put: what should we do to
> libssh2 to make this a lot less complicated?

It's similar to forwarded TCP ports. If libssh2 should take care of
everything it has to manage these connections coming and going. I
think just one forwarded connection of each type would be fine to
begin with.

Or libssh2 can push this task to the application, and only do minimum
SSH protocol. But that doesn't feel quite as warm and fuzzy.


//Peter

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
libssh2-devel mailing list
libssh2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel

Reply via email to