X with ssh, (was Novell to acquire Suse)

[Dan Coutu]

On Wed, 2003-11-05 at 11:07, bscott at ntisys.com wrote:
> On Tue, 4 Nov 2003, at 3:56pm, coutu at snowy-owl.com wrote:
> >>> ssh -XCA -l mylogin remote.system.name
> 
>   What if you turn off compression?  I've seen it cause weird compatibility
> problems before.

Turning off compression makes no difference at all.

> > It nicely told me that it was requesting X forwarding with authentication
> > but still there is no DISPLAY variable defined and thus no X forwarding is
> > possible.
> 
>   Could you please post the exact error message, along with anything else
> that looks interesting?  For example, here is what I see if I try to SSH
> into a system with no X11 support installed, but requesting X11 forwarding
> anyway:

Here you go:

debug1: ssh-userauth2 successful: method password
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel request 0: x11-req
debug1: Requesting authentication agent forwarding.
debug1: channel request 0: auth-agent-req at openssh.com
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768

As you'll note I don't get the xauth error message that you got.

>   While I'm not sure where that error message about the DISPLAY variable is
> coming from, I don't think the lack of a DISPLAY variable on the server is
> causing your problem.  The sshd daemon is going to be running without a
> DISPLAY variable anyway -- indeed, it won't even have a TTY.  I do think
> you're on to something about some needed package being required but not
> present.

I respectfully disagree. Time and time again I've noted that ssh
will define a DISPLAY variable that points to the 'virtual display
socket' (or whatever the right term is) that gets X applications
connected through the ssh tunnel back to my workstation. An X
application will not work if there is no DISPLAY environment
variable defined and there is no value for display specified
in the command line when you start it. An X display is required.

Here's an example from an ssh connection that does the remote
X display thing correctly:

DISPLAY=localhost:10.0

You'll note that instead of the conventional value of '0.0' or '0'
the display is offset by the amount specified in the sshd config
file (typically 10).

>   When you SSH in, check the output of "netstat".  Specifically, look for a
> TCP connection listening on port 6010 or so.  That will at least tell us if
> the SSH server is even trying to proxy the X11 connection.  I suspect not.

It shows no network connections near 6000. I only see the
ssh connection between the two machines. Experimentation shows
that when a successful X connection is established (by actually
running an application) I see a network connection whose local
address is 'localhost:x11-ssh-offset'. With no live X connection
this address is not listed by netstat.

>   Can you run a test on a failing system with the sshd daemon in debug mode
> (foreground, verbose output to console, single connection only, no forking)?  
> While you pretty much need local access (since you're testing your remote
> access method), the output can be very informative.

This is a little more involved. I'll have to see if I can identify a
system that I can do this with without impacting production work.
-- 
Dan Coutu
Managing Director
Snowy Owl Internet Consulting, LLC
http://www.snowy-owl.com