[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: X11 Forwarding


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
>     >     >
>     >
>     >
>     >
> 
> 
> 

Follow-Ups:
Re: X11 ForwardingDustin Oprea <myselfasunder@xxxxxxxxx>
References:
X11 ForwardingDustin Oprea <myselfasunder@xxxxxxxxx>
Re: X11 ForwardingAris Adamantiadis <aris@xxxxxxxxxxxx>
Re: X11 ForwardingDustin Oprea <myselfasunder@xxxxxxxxx>
Re: X11 ForwardingAris Adamantiadis <aris@xxxxxxxxxxxx>
Re: X11 ForwardingDustin Oprea <myselfasunder@xxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org