X with ssh, (was Novell to acquire Suse)

bscott at ntisys.com bscott at ntisys.com
Wed Nov 5 11:07:38 EST 2003


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.

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

debug1: ssh-userauth2 successful: method publickey
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: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug1: Remote: No xauth program; cannot forward with spoofing.

  The only real indication of failure is that bit about xauth.  Oh, and I
don't get a DISPLAY variable, either.  Here is similar output, from a system
*with* X11 support.

debug1: ssh-userauth2 successful: method publickey
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: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768

  You might also try using multiple "-v" options to increase verbosity.

On Wed, 5 Nov 2003, at 10:24am, coutu at snowy-owl.com wrote:
> The key here seems to be that remote X display works fine if the remote
> system is a workstation that is already running X. If the remote system is
> configured as a server *without X* (has a text mode console) then there is
> no DISPLAY variable defined on the remote system in the first place and
> ssh doesn't seem to define one no matter what switch settings I specify.

  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.

  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.

  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.

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |




More information about the gnhlug-discuss mailing list