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

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 [] 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_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-
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
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

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


Reply to: