On Wed, 2003-11-05 at 11:07, [EMAIL PROTECTED] wrote: > On Tue, 4 Nov 2003, at 3:56pm, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss