Re: Remote connections to X apps

[dsavage@peaknet.net]

Robert,

See my inserted responses:

> On 07/18/2007 02:12 PM, dsavage@peaknet.net wrote:
>> Note that ssh's -X and -Y command line options allow X11 forwarding (see
>> 'man ssh'). I've started Cygwin's X server on the PC here at work and
>> leave it running in background ready to display any X session sent to
>> it.
>
> If you have Cygwin's X server running, verify that it's working.  That
> is, open an xterm on the local machine.  Once that xterm is open, type
> the following and post the output:
>
> ( set -x ; echo -- $DISPLAY -- )
>
> It should look something like this:
>
> + echo -- :0.0 --
> -- :0.0 --

This part appears to be working fine:
   $ DISPLAY=:0.0 ; export DISPLAY
   + DISPLAY=:0.0
   + export DISPLAY
   $

> If it does, connect to the remote machine with this ssh command:
>
> ssh -v -X -Y -l <user> <ip_address>
>
> Look for the line that contains "... Requesting X11 forwarding ..." and
> post it.

No joy. Here's the complete connection output:
   $ ssh -v -Y -l <user> <ip_address>
   OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
   debug1: Reading configuration data /etc/ssh_config
   debug1: Connecting to <ip_address> [<ip_address>] port 22.
   debug1: Connection established.
   debug1: identity file /home/<winuser>/.ssh/identity type -1
   debug1: identity file /home/<winuser>/.ssh/id_rsa type -1
   debug1: identity file /home/<winuser/.ssh/id_dsa type -1
   debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
   debug1: match: OpenSSH_4.3 pat OpenSSH*
   debug1: Enabling compatibility mode for protocol 2.0
   debug1: Local version string SSH-2.0-OpenSSH_4.6
   debug1: SSH2_MSG_KEXINIT sent
   debug1: SSH2_MSG_KEXINIT received
   debug1: kex: server->client aes128-cbc hmac-md5 none
   debug1: kex: client->server aes128-cbc hmac-md5 none
   debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
   debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
   debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
   debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
   debug1: Host '<ip_address>' is known and matches the RSA host key.
   debug1: Found key in /home/<winuser>/.ssh/known_hosts:1
   debug1: ssh_rsa_verify: signature correct
   debug1: SSH2_MSG_NEWKEYS sent
   debug1: expecting SSH2_MSG_NEWKEYS
   debug1: SSH2_MSG_NEWKEYS received
   debug1: SSH2_MSG_SERVICE_REQUEST sent
   debug1: SSH2_MSG_SERVICE_ACCEPT received
   debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
   debug1: Next authentication method: publickey
   debug1: Trying private key: /home/<winuser>/.ssh/identity
   debug1: Trying private key: /home/<winuser>/.ssh/id_rsa
   debug1: Trying private key: /home/<winuser>/.ssh/id_dsa
   debug1: Next authentication method: password
   <user>@<ip_address>'s password:
   debug1: Authentication succeeded (password).
   debug1: channel 0: new [client-session]
   debug1: Entering interactive session.
   Last login: Thu Jul 19 14:34:24 2007 from newark-nat1.na.baesystems.com

   $

I sure don't see any mention of X11 forwarding in this output.

>> What other setup/configuration requirements have I missed? For those who
>> might ask "Have you enabled X11 forwarding in the server's sshd_config
>> file?", the answer is yes.
>
> Can you verify that for us?  That is, type the following command on the
> remote host and post the output:
>
> ( set -x ; grep -i x11 /etc/ssh/sshd_config )
>
   $ set -x ; grep -i x11 /etc/ssh/sshd_config
   + grep -i x11 /etc/ssh/sshd_config
   grep: /etc/ssh/sshd_config: Permission denied

Well, allrighty then... su to root on the remote server and re-run it:
   # set -x ; grep -i x11 /etc/ssh/sshd_config
   + grep -i x11 /etc/ssh/sshd_config
   #X11Forwarding no
   X11Forwarding yes
   #X11DisplayOffset 10
   #X11UseLocalhost yes

It's my understanding that a # in column 1 makes the entire line a
comment. By convention, though, all variables and their default values are
shown after the # for reference. In this case, the default value of
X11Forwarding is "no", but sshd_config has been edited to explicitly
change that to "yes".

I'll go out on a limb here and guess that the remote server either (a)
isn't doing what it's supposed to do, or (b) isn't being told to do the
right thing.

Back at ya.

--Doc

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.