On Fri, Sep 03, 2004 at 04:39:10PM -0500, Doc Shipley wrote:
| Yebbut, do the *clients* have it set? Check /etc/ssh/ssh_config on
| the client side.
Look at the ssh -v output. It'll tell you if X is being forwarded or
not.
| >I did notice that the display variable was not set properly. So, comparing
| >it to a machine that works (ur... the way I want) and a machine that
| >doesn't:
| >
| >works:
| >$ echo $DISPLAY
| >localhost:10.0
| >
| >doesn't:
| >$ echo $DISPLAY
| >:0
|
| This infers that the client isn't doing the xauth auto-handshake on
| connection.
No, it implies that the DISPLAY is being set incorrectly on the
machine that doesn't work. :0 means the local display. ssh should
never set the DISPLAY like that. Assuming that this is in fact seen
on the remote machine (and not inside a previously opened screen
session), the most likely cause is something like this in a startup
file somewhere --
setenv DISPLAY :0 { csh }
export DISPLAY=:0 { bash }
DISPLAY=:0 ; export DISPLAY { sh }
I've seen people do this before to their dot files as they tried to
make various X things work, like they'd telnet/rlogin into their own
box, then X applications wouldn't work, so they'd slap one of these
lines in their startup file ...
If it works on one remote machine, and not another remote machine,
that suggests that your local machine is fine. So look at what's
different between the two remote machines.
| I haven't used any distribution in years that doesn't
| install xauth (.Xauthority "Magic Cookies") as part of the XFree86
| packages, so you're left with enabling X11Forwarding on the client.
Me neither.
| I have also, when the client was a much older release than the
| server, had problems with the line "X11DisplayOffset" on the server
| side. That sets $DISPLAY to :10 as above. If your client is anywhere
| near the same version as the server, that should not be a problem.
Even if the offset were set to 0 (which would be sub-optimal), it
would set the DISPLAY to localhost:0, not :0. localhost:0 means `tcp
port 6000, host localhost', where :0 means `the fastest way to talk to
screen :0' (which is usually shared memory). ssh always uses tcp.
| >Obviously, changing the display var doesn't fix it.
I'm not so sure it's so obvious.
| > I can also just add
| >the local machine to xhosts, set the display var, and throw apps straight
| >over the wire.
| >
| >But, I want to pipe it through the ssh connection.
|
| Technically, you still are. However, that's not "The SSH Way", and
| it's not as secure.
Just so we're talking about the same thing ...
I ssh from hostA into hostB.
on hostB, I do this :
setenv DISPLAY hostA:0
on hostA, I do a :
xhost hostB
and then on hostB, I do a :
xterm &
then I am *not* piping my X session through ssh. And I think this is
what he's talking about.
--
Doug McLaren, [EMAIL PROTECTED]
Marriage is like a coffin and each kid is like another nail.
--Homer Simpson
_______________________________________________
Siglinux mailing list
[EMAIL PROTECTED]
http://machito.utacm.org/mailman/listinfo/siglinux
