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