Cormac McGuinness <[EMAIL PROTECTED]> writes: > On Mon, Dec 13, 1999 at 09:24:30AM -0700, Gary Hennigan wrote: > > [EMAIL PROTECTED] writes: > > > Mark Santaniello <[EMAIL PROTECTED]> wrote: > > > > > > >Right now, if I ssh to the machine, and attempt to run an X app...say > > > >xterm...it gives this error: > > > > > > >_X11TransSocketINETConnect: Can't connect: errno = 110 > > > >xterm Xt error: Can't open display: progression:10.0 > > > > > > > laptop% xclock > > _X11TransSocketINETConnect: Can't connect: errno = 113 > > Error: Can't open display: laptop:11.0 > > > > Well, it might help if you issue an "xhost +" command on your laptop > so that the xterm is allowed to open the display on your laptop. > There could of course be other more complicated reasons for this behaviour > however... but I always forget to issue an xhost command myself and I > always see this.
Well, sort of. SSH doesn't require you to use xhost. xhost leaves a security hole a mile wide and just about anybody can use a snoop program to echo your keystrokes to a file. So, xauth is used to circumvent this hole, to a degree. Anyway, my problem was related to Mark's, and he found the solution. Turns out that ssh uses a DNS lookup for your host to set the DISPLAY variable. In Mark's case he had a bad entry in /etc/hosts. In my case the remote system is a laptop that lives on various networks. I've always kept it's local name the same no matter what network it was attached to. This local name doesn't necessarily correspond to its real name on the network and thus ssh was setting the display to this local name instead of the laptops real network name. Obviously this disallows a functional forward of X11. In my case I need to figure out how to set the host name to the "real" name of the laptop depending on what network it resides (maybe PCMCIA has some provision for this?). For now I can set it's host name manually via the "hostname" command to it's real network name and that fixes the problem. Gary
