X with ssh, (was Novell to acquire Suse)

bscott at ntisys.com bscott at ntisys.com
Thu Nov 6 18:26:25 EST 2003


On Wed, 5 Nov 2003, at 11:46am, coutu at snowy-owl.com wrote:
> Turning off compression makes no difference at all.

  Oh well.  It was worth a shot.

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

  Very curious.  I also note that you *do* get messages to the effect that 
the X11 forwarding *is* being requested:

> debug1: Requesting X11 forwarding with authentication spoofing.
> debug1: channel request 0: x11-req

  So, while your SSH client appears to be requesting X11 forwarding, the
lack of a DISPLAY variable in the resulting SSH shell session does imply a
failure on the part of the SSH server (sshd).

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

  Ah, I didn't explain that very well.  Yes, certainly, the sshd subprocess
that starts your SSH session should -- indeed, almost has to -- define a
DISPLAY variable, so that X clients you start from the SSH session know what
X display socket to connect to.  What I was trying to say was that the lack
of a running X server on the system you're SSH'ing into should not be a
problem.  The sshd daemon runs in the background, without a DISPLAY or a
tty.  The sshd daemon is responsible for creating a new DISPLAY socket,
should your SSH client request it.  It should not care what the server's
head is -- or even if it has one.  Looking back, you may not have even meant
to imply that you thought it did; if you did not, you can ignore this whole
issue.  :-)

  What likely does matter, as you have stated, is the particular combination
of SSH configuration options and software packages on the system you're
SSH'ing into.

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

  Further evidence that sshd is not doing anything for X11 forwarding.

  (Just to double-check: You did look for *listening* connections, yes?  
For example, on my Red Hat-based system, I use "netstat -ltn" to find sshd
listening on 127.0.0.1:6010 when X11 forwarding is working.)

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

  Yes, it is.  Unfortunately, the more we look at this, the more I think
you're going to have to do this.

  If SSH is in production use, you can try creating another instance of sshd 
on a different port, and using that for debugging.  For example:

	sshd -d -e -p 26

That asks sshd to run in debug mode (-d), to send debug output to stderr
instead of syslog (-e), and to bind and listen on port 26 (-p 26).  Specify
"-d" multiple times to increase verboseness.  In debug mode, sshd does not
fork, runs in the foreground, generates debugging output, allows only one
session, and exits when the session closes.

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