From 73cb21837c5054f3640aa3d3b8a99af79f94a645 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Wed, 18 May 2011 11:57:44 -0400 Subject: [PATCH] Add mxconns post and package reference. --- posts/Gentoo_overlay.mdwn | 5 ++- posts/mxconns.mdwn | 88 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 92 insertions(+), 1 deletion(-) create mode 100644 posts/mxconns.mdwn diff --git a/posts/Gentoo_overlay.mdwn b/posts/Gentoo_overlay.mdwn index 1d89053..1c549a3 100644 --- a/posts/Gentoo_overlay.mdwn +++ b/posts/Gentoo_overlay.mdwn @@ -28,7 +28,8 @@ personal `layman.xml`). The overlay is a fairly strange mix: - dev-util/be ([Gentoo 303867](http://bugs.gentoo.org/303867)) - media-gfx/metacam - ([Gentoo 65200](http://bugs.gentoo.org/65200)) + ([Gentoo 65200](http://bugs.gentoo.org/65200), but I suggest you use + `media-gfx/exif` if you don't need `metacam`'s special decoding) - media-sound/abcmidi ([Gentoo 76017](http://bugs.gentoo.org/76017), also in the [Sunrise overlay][]) @@ -52,6 +53,8 @@ personal `layman.xml`). The overlay is a fairly strange mix: (my [[sawsim]] force spectroscopy simulator) - virtual/thesis-tools (useful dependencies for compiling a [[thesis]]) +- x11-misc/mxconns + ([[mxconns]]) For those that aren't yet familiar with layman and overlays, install layman with: diff --git a/posts/mxconns.mdwn b/posts/mxconns.mdwn new file mode 100644 index 0000000..e4813ec --- /dev/null +++ b/posts/mxconns.mdwn @@ -0,0 +1,88 @@ +[[!meta title="mxconns"]] + +[Lionel Cons][LC]'s [mxconns][] is an X Windows monitor and proxy. +The author suggests you use it to enhance the security of your X +server by monitoring for connection attempts and dangerous requests +(e.g. keylogging). + +I ran into it while trying to get X forwarding working with my +[[cluster|Abax]]. Ususally if you [[SSH]] into a remote computer and +want to run X applications, you use `ssh -Y` to forward your X +connection to the remote host, and everything works as expected. +However, I could not figure out how to expose the forwarded server so +it could except connections from other nodes in the cluster. For +example, if a job I had running on `n1` wanted to talk to my X server +(e.g. via [[MPE]]), it would need to connect to `n0`: + + home <--(ssh -Y)----> n0 <--(???)----> n + +`mxconns` fills the gap by providing a proxy between the local socket +provided by `ssh -Y` and a new publicly exposed X socket available to +`n*`: + + home <--(ssh -Y)----> n0 <--(mxconns)----> n1 + +`mxconns` needs a configuration file telling it to trust all the +computers on the cluster, which should look something like: + + n0$ cat ~/.mxconns + 192.168.2.* allow + +After you've set that up, a full connection will look like + + home$ ssh -Y n0 + n0$ export DISPLAY=`mxconns -config ~/.mxconns -fork -hunt -verbose` + n0$ echo $DISPLAY + n0.*.edu:5 + +after which you can do things like + + n0$ ssh n1 + n1$ export DISPLAY=n0:5 xeyes + +You can explicitly kill `mxconns` when you're done: + + n0$ killall mxconns + +or just wait and it will die naturally when you close your initial X +connection to `n0`. + +Packaging +--------- + +`mxconns` is enough of a niche app that it's not widely packaged at +the moment. However, building and installing it is really easy, and +is well explained in the `README` file. I've added an ebuild to my +[[Gentoo overlay]] if you're running Gentoo. + +Messy details +------------- + +`ssh -Y` sets up an X proxy on `n0` on 127.0.0.1:6010 and sets my +`DISPLAY` to `localhost:10.0`: + + n0$ netstat -an | grep 6010 + tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN + tcp6 0 0 ::1:6010 :::* LISTEN + +However, I *want* the X proxy to bind to `eth0` (192.168.2.100) not +localhost (127.0.0.1), so other nodes can connect. If you're using +[OpenSSH][]'s `sshd` on `n0`, you can set `X11UseLocalhost no` in your +`sshd_config`. However, this binds the `ssh -Y` X connection to the +wildcard address, exposing it to the world through eth1 (which is bad) +as well as to the cluster through eth0 (which is good). + +X authentication is handled with cookies, and getting cookie detection +working in `mxconns` turned out to be a key part of patching `mxconns` +to work in this situation. The `ssh -Y` connection stores its X +authority cookie under `hostname/unix:dpynum`: + + n0$ xauth list + n0/unix:10 MIT-MAGIC-COOKIE-1 ... + +as described under the `DISPLAY NAMES` section of [xauth(1)][xauth]. + +[LC]: http://cons.web.cern.ch/cons/ +[mxconns]: http://mxconns.web.cern.ch/mxconns/ +[OpenSSH]: http://www.openssh.com/ +[xauth]: http://www.x.org/archive/X11R6.8.1/doc/xauth.1.html#sect5 -- 2.26.2