Re: X11 Forwarding

[Dustin Oprea <myselfasunder@xxxxxxxxx>]

Thanks for that clarification, Aris.

Should that change end up in MASTER, imminently?

Dustin
On Sep 13, 2013 2:37 AM, "Aris Adamantiadis" <aris@xxxxxxxxxxxx> wrote:

> Hi Dustin,
>
> The decision fits in the server. If you do not issue an x11 request, the
> server will not bind a local port/unix socket for X11 and the env
> variable DISPLAY will not be set.
> Technically this callback could be executed even if you do not request
> x11, but in that case it would be perfectly acceptable to deny it
> (return NULL). I guess that answers your question.
> If the callback is not defined, the request will be queued in a
> ssh_message queue, which is parsed by a few other synchronous calls. Do
> not use that if you can.
>
> However I see now that it may not work if you compile libssh without
> WITH_SERVER. I'll fix this for 0.6
>
> Kr,
>
> Aris
>
> Le 13/09/13 08:11, Dustin Oprea a écrit :
> > Where does that decision fit into the library? It only appears to be
> > referenced from this one function, which is not specific to X11, and it
> > looks like it only matters if the callback is defined, regardless of
> > whether request_x11 has previously been called.
> >
> > static int *ssh_execute_client_request*(ssh_session session, ssh_message
> > msg)
> > {
> >     ssh_channel channel = NULL;
> >     int rc = SSH_AGAIN;
> >
> > *    if (msg->type == SSH_REQUEST_CHANNEL_OPEN*
> > *        && msg->channel_request_open.type == SSH_CHANNEL_X11*
> > *        && ssh_callbacks_exists(session->common.callbacks,
> > channel_open_request_x11_function)) {*
> >         channel =
> > *session->common.callbacks->channel_open_request_x11_function* (session,
> >                 msg->channel_request_open.originator,
> >                 msg->channel_request_open.originator_port,
> >                 session->common.callbacks->userdata);
> >
> >
> >
> > Dustin
> >
> >
> >
> > On Fri, Sep 13, 2013 at 1:46 AM, Aris Adamantiadis <aris@xxxxxxxxxxxx
> > <mailto:aris@xxxxxxxxxxxx>> wrote:
> >
> >     Hi,
> >
> >     request_x11 is still required because that's how you tell the server
> you
> >     wish to use X11.
> >     The callback you implement should return a new ssh channel from
> >     ssh_channel_new. This in order to keep object ownership
> (ssh_channel) to
> >     the application.
> >
> >     Kr,
> >
> >     Aris
> >     Le 13/09/13 06:02, Dustin Oprea a écrit :
> >     > Does that mean that the request_x11() and/or accept_x11() no
> >     longer need
> >     > to be called?
> >     >
> >     > What am I doing inside the callback.. Just do ssh_channel_new(),
> >     or do I
> >     > do an accept_x11() and return the ssh_channel from that?
> >     >
> >     > I always appreciate your help, Aris.
> >     >
> >     >
> >     > On Thu, Sep 12, 2013 at 1:36 PM, Aris Adamantiadis
> >     <aris@xxxxxxxxxxxx <mailto:aris@xxxxxxxxxxxx>
> >     > <mailto:aris@xxxxxxxxxxxx <mailto:aris@xxxxxxxxxxxx>>> wrote:
> >     >
> >     >     Hi Dustin,
> >     >
> >     >     ssh_channel_accept_x11() is called shortly after request_x11
> >     when you
> >     >     know that you're going to receive an X11 socket. However since
> >     0.6rc
> >     >     there's a session-defined callback to handle new X11
> connections:
> >     >
> >     >     /**
> >     >      * @brief Handles an SSH new channel open X11 request. This
> >     happens when
> >     >     the server
> >     >      * sends back an X11 connection attempt. This is a client-side
> API
> >     >      * @param session current session handler
> >     >      * @param userdata Userdata to be passed to the callback
> function.
> >     >      * @returns a valid ssh_channel handle if the request is to be
> >     allowed
> >     >      * @returns NULL if the request should not be allowed
> >     >      * @warning The channel pointer returned by this callback must
> >     be closed
> >     >     by the application.
> >     >      */
> >     >     typedef ssh_channel (*ssh_channel_open_request_x11_callback)
> >     >     (ssh_session session,
> >     >           const char * originator_address, int originator_port,
> void
> >     >     *userdata);
> >     >
> >     >     struct ssh_callbacks_struct {
> >     >     /* ... */
> >     >       /** This function will be called when an incoming X11
> request is
> >     >     received.
> >     >        */
> >     >       ssh_channel_open_request_x11_callback
> >     >     channel_open_request_x11_function;
> >     >     };
> >     >
> >     >     I tested this in an application for a client but unfortunately
> >     don't
> >     >     have any example around. However it's pretty simple if you
> >     look at the
> >     >     other callback-based examples (like proxy.c or samplesshd-cb.c)
> >     >
> >     >     Kr,
> >     >
> >     >     Aris
> >     >
> >     >     Le 12/09/13 12:58, Dustin Oprea a écrit :
> >     >     > Does someone have experience with X11 forwarding? I'm
> >     current fixing
> >     >     > another anomaly, but I wanted to get my thoughts straight on
> >     this.
> >     >     This
> >     >     > is the theoretical process as it makes sense to me:
> >     >     >
> >     >     > 1) ssh_channel_accept_x11(). Is this done between reads on
> >     the client,
> >     >     > on a separate thread,.. or where?
> >     >     > 2) At this point, we should have a X11 channel, returned
> >     from the
> >     >     accept
> >     >     > call.
> >     >     > 3) ssh_channel_request_pty()
> >     >     > 4) ssh_channel_change_pty_size()
> >     >     > 5) ssh_channel_request_x11()
> >     >     > 6) ssh_channel_request_shell()
> >     >     >
> >     >     > What now? Loop over communication on the shell channel -as
> well
> >     >     as- the
> >     >     > X11 channel?
> >     >     >
> >     >     > Are there any unnecessary steps, above (like the pty_size()
> >     call)?
> >     >     >
> >     >     >
> >     >     > Thanks. This is just about the only principal function that
> >     isn't
> >     >     > clearly covered by the tutorials.
> >     >     >
> >     >     > Dustin
> >     >     >
> >     >
> >     >
> >     >
> >
> >
> >
>
>