Summary: Xaccess and Gtk

Thanks go to Bob Vickers and Mike Brodbelt for pointing out the error,
confusion
and insecurity of my ways.

  The problem:  

   I could not ship an "X-application" from one machine to another because
   "Gtk-WARNING **: cannot open display: "

   The solution:
    Do not use Xaccess and xhost as they are insecure.
    Let ssh do the work for you:

    ssh -X -l user host
    
   where the "-X" option tells ssh to create a secure X11 tunnel.
  

------------------ Bob Vickers' Reply ------------------------

You are doing it all wrong! You don't want /etc/X11/xdm/Xaccess to be wide
open, you don't want xhost + (which is a huge security hole), you don't
want to mess around with DISPLAY variables. Instead let
ssh do the work for you with the -X parameter, e.g.
  ssh -X -l escown mnementh

ssh will set up a secure tunnelled X connection and will set the DISPLAY
variable for you on the remote session. Don't reset it to something else.

Possibly the problem you were having was that a firewall was blocking X11
traffic; this shouldn't happen if you tunnel it through ssh.

Bob


------------------ Mike Brodbelt's Reply ----------------------------


You're confusing two access mechanisms somewhat. Firstly, there are
standard X11 connections. This is where an X client program (such as
xterm, xeyes, etc, etc) started on machine A connects to the X server
running on machine B. Typically, it will connect to the first display on
B (which listens on tcp/6000), and it does this over a tcp connection.
To run an X program like this, on logs into machine A in some way
(telnet, rlogin ssh) and starts the program like this:-

[user@a ~]$ xterm -display b:0.0

For this to work, the X server on B must allow access to X clients from
A, *and* the X server must also be listening for TCP connections. The
former can be fixed with "xhost +" to disable access control, and once
you have it working, you can fine tune the allowed host list. The latter
is a common gotcha - many distributions these days start the X server
with TCP listening turned off by default - on my Debian box the command
line is:-

/usr/X11R6/bin/X :0 -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7

If yours is like that, it should be obvious why it's not working.


The second means of getting X connections to work is to tunnel them via
ssh. In this case, you start logged into machine B, ssh to machine B,
and then simply start your X program. No display argument is necessary.
This works because the ssh server creates a virtual X display, typically
something like A:10.0, and sets the DISPLAY environment variable such
that X clients connect to it by default. Connections to this virtual X
server are forwarded back to the originating machine across an SSH
tunnel, where they connect to the real X server on B. As far as the X
server on B is concerned, the connections come from localhost, and so
the server does not need to be listening for tcp connections. For this
to work, the ssh client must ask for X11 forwarding, and the ssh server
must provide it. You want something like these config file snippets.

In /etc/ssh/ssh_config on machine B:-

Host *
  ForwardAgent yes
  ForwardX11 yes

and in /etc/ssh/sshd_config on machine A:-

X11Forwarding yes
X11DisplayOffset 10

Then, restart sshd, and ssh from machine B to machine A. At the prompt,
you should be able to test like this:-

[user@a ~]$ echo $DISPLAY
localhost:10.0

If the display environment variable is empty, you've got something in
the setup of ssh wrong.

In general, it's better to leave tcp listening off, and forward X
connections over ssh. Using unencrypted X sessions over the network is
probably best avoided unless you trust your environment implicitly.

HTH,

Mike. 

   


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
_______________________________________________
LinuxManagers mailing list - http://www.linuxmanagers.org
submissions: LinuxManagers-35TzE1X9F6582KRnZfj+bdi2O/[email protected]
subscribe/unsubscribe: http://www.linuxmanagers.org/mailman/listinfo/linuxmanagers