posts/mxconns.mdwn

   1 [[!meta  title="mxconns"]]
   2
   3 [Lionel Cons][LC]'s [mxconns][] is an X Windows monitor and proxy.
   4 The author suggests you use it to enhance the security of your X
   5 server by monitoring for connection attempts and dangerous requests
   6 (e.g. keylogging).  I tend to use it as a flexible proxy fo X
   7 forwarding with my [[cluster|Abax]].
   8
   9 Ususally if you [[SSH]] into a remote computer and want to run X
  10 applications, you use `ssh -Y` to forward your X connection to the
  11 remote host, and everything works as expected.  However, I could not
  12 figure out how to expose the forwarded server so it could except
  13 connections from other nodes in the cluster.  For example, if a job I
  14 had running on `n1` wanted to talk to my X server (e.g. via [[MPE]]),
  15 it would need to connect to `n0`:
  16
  17     home <--(ssh -Y)----> n0 <--(???)----> n*
  18
  19 `mxconns` fills the gap by providing a proxy between the local socket
  20 provided by `ssh -Y` and a new publicly exposed X socket available to
  21 `n*`:
  22
  23     home <--(ssh -Y)----> n0 <--(mxconns)----> n*
  24
  25 `mxconns` needs a configuration file telling it to trust all the
  26 computers on the cluster, which should look something like:
  27
  28     n0$ cat ~/.mxconns
  29     192.168.2.*     allow
  30
  31 After you've set that up, a full connection will look like:
  32
  33     home$ ssh -Y n0
  34     n0$ export DISPLAY=`mxconns -config ~/.mxconns -fork -hunt -verbose`
  35     n0$ echo $DISPLAY
  36     n0.*.edu:5
  37
  38 after which you can do things like:
  39
  40     n0$ ssh n1
  41     n1$ export DISPLAY=n0:5 xeyes
  42
  43 You can explicitly kill `mxconns` when you're done:
  44
  45     n0$ killall mxconns
  46
  47 or just wait and it will die naturally when you close your initial X
  48 connection to `n0`.
  49
  50 Packaging
  51 ---------
  52
  53 `mxconns` is enough of a niche app that it's not widely packaged at
  54 the moment.  However, building and installing it is really easy, and
  55 is well explained in the `README` file.  I've added an ebuild to my
  56 [[Gentoo overlay]] if you're running Gentoo.
  57
  58 Messy details
  59 -------------
  60
  61 `ssh -Y` sets up an X proxy on `n0` on 127.0.0.1:6010 and sets my
  62 `DISPLAY` to `localhost:10.0`:
  63
  64     n0$ netstat -an | grep 6010
  65     tcp     0    0    127.0.0.1:6010    0.0.0.0:*    LISTEN
  66     tcp6    0    0    ::1:6010          :::*         LISTEN
  67
  68 However, I *want* the X proxy to bind to `eth0` (192.168.2.100) not
  69 localhost (127.0.0.1), so other nodes can connect.  If you're using
  70 [OpenSSH][]'s `sshd` on `n0`, you can set `X11UseLocalhost no` in your
  71 `sshd_config`.  However, this binds the `ssh -Y` X connection to the
  72 wildcard address, exposing it to the world through eth1 (which is bad)
  73 as well as to the cluster through eth0 (which is good).  With
  74 `mxconns` you can explicitly specify the interfaces you want to bind.
  75
  76 X authentication is handled with cookies, and getting cookie detection
  77 working in `mxconns` turned out to be a key part of patching `mxconns`
  78 to work in this situation.  The `ssh -Y` connection stores its X
  79 authority cookie under `hostname/unix:dpynum`:
  80
  81     n0$ xauth list
  82     n0/unix:10  MIT-MAGIC-COOKIE-1  ...
  83
  84 as described under the `DISPLAY NAMES` section of [xauth(1)][xauth].
  85
  86 [LC]: http://cons.web.cern.ch/cons/
  87 [mxconns]: http://mxconns.web.cern.ch/mxconns/
  88 [OpenSSH]: http://www.openssh.com/
  89 [xauth]: http://www.x.org/archive/X11R6.8.1/doc/xauth.1.html#sect5
  90
  91 [[!tag tags/linux]]
  92 [[!tag tags/tools]]