Re: Remote X login
Jon Dowland said...
> On Mon, Oct 31, 2005 at 03:00:26PM -0000, marc wrote:
> > Used on the client
> ^^^^^^
> Beware confusing client and server when discussing X. In X parlance, the
> server is your desktop and the machine with the applications on is the
> client. This is because the X server is running on your desktop (or
> laptop, or whatever).
Yup, I figured this out reading the docs today. Bizarre.
> > # ssh -X user@host
> > ssh logs in, as it does without -X.
> >
> > If I then try to run, say, kwrite, I receive the error:
> > # kwrite: cannot connect to X server
> > which is the same as without the -X option.
>
> That suggests that $DISPLAY is not set - try
> ssh -X user@host 'echo $DISPLAY'
It prompts for password, then drops back to the local prompt.
> If you don't get something like 'localhost:10.0' back, then there's a
> problem tunnelling X . Add a -v argument to ssh, and try again:
>
> ssh -v -X user@host 'echo $DISPLAY'
>
> You'll get a lot of output. Normally it's something like the xauth
> binary not being available on the remote computer (install xbase-clients
> in that case)
xbase-clients is installed.
I don't see anything in the debug info.
boom:~# ssh -v -X user@host 'echo $DISPLAY'
OpenSSH_4.2p1 Debian-5, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to host [192.168.0.41] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_
4.2p1 Debian-5
debug1: match: OpenSSH_4.2p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-5
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 'host' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
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,keyboard-
interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = en_GB
debug1: Sending command: echo $DISPLAY
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0
boom:~#
Without 'echo $DISPLAY', ssh completes the login successfully.
Any other pointers? I've read a stack of docs today, but they meander
all over the place without getting into the detail in a useful way in
the context of this problem.
> > Nevertheless, while this function is certainly useful - if my
> > understanding is correct that it allows you to use remote named
> > X-based progs - I still have the requirement of loggin on to a remote
> > machine via XDM.
>
> Yeah, I'm curious about the best approach for that sort-of stuff, too.
I've now got this working.
There appears to have been a bug in KDM [1] that may, or may not, have
been fixed [2]. However, I'm running testing, so can't try the fix.
Instead, I loaded GDM, and I can KDE sessions on remote machines without
difficulty. However, GDM presents other problems :-( so, hopefully, KDM
4:3.2.2-1 will be available soon.
[1] http://lists.debian.org/debian-qt-kde/2004/08/msg00110.html
[2] http://lists.debian.org/debian-qt-kde/2005/08/msg00315.html
--
Best,
Marc
Reply to: