Day: January 7, 2011

Recently we acquired a new firewall to place in between our datacenter and the rest of our network.  This is a fairly standard security procedure used to isolate the servers from the rest of a network that can be loaded with all kinds of nasty spyware, malware and viruses, not to mention really nifty people that want to violate the security of the data.

Security is a two-edged sword for many systems folk. Firewalls are really great security tools, yet they can also get in the way of nice tools that provide access into the servers for remote administration.

Prior to the placement of the new firewall, I often used XDMCP sessions to access my unix servers from the comfort of my office, rather than traipsing to the data center to use the console.  While these servers do have iLOM ports, there are some interface issues that make their use less elegant that I would wish.

After the new firewall entered the equation, I found that my normal XDMCP setup using Xephyr on my iMac no longer worked for some reason.  It appeared that some of the rulesets were blocking either the particular TCP or UDP traffic necessary for the communication to work.  Rather than worry our firewall administrator with troubleshooting the issue, I decided to find another way in via ssh.

It turns out that I could easily tunnel an X11 login session through an ssh session.  Given that I have sshd configured to allow for TCP forwarding I was able to use an Xnest session that was initiated after logging in via ssh.  Here’s the process I used:

First you need to initiate the ssh session while enabling X11 TCP forwarding.  Depending on your particulars this can be done by one of the following commands:

bash-3.2$ ssh -X server.example.com

bash-3.2$ ssh -Y server.example.com

The next command is executed on the server, but the X11 session is actually running under the X11 installation on the local workstation:

Xnest :1 -geometry 1280x1024 -query localhost -terminate

Here’s a breakdown of the command parameters:

determines the X11 screen to be used on the local workstation, screen 0 is the default screen used for X11

set the screen resolution to use for the X11 window on the local workstation

determines which host to actually make the connection with

closes the XDMCP session once the user logs out

All of this can actually be accomplished with a single step, by chaining the ssh login command with the Xnest command:

ssh -X REMOTESERVERNAME Xnest :1 -geometry 1280x1024 -query localhost -terminate

Related posts

This entry was posted in geeky, work and tagged system administration, X11, xdmcp. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

In the application selection process for 10.5, the X11 maintainers elected not to include Xnest.

While most users will probably not need this, since you can export X11 application through a SSH connection, sometimes it is quite handy to have the entire gui session available from a remote server.

I use this when managing some of my Solaris servers. With X11 on 10.4 this was readily available, but after installing 10.5 I found that it had not been included. Initially I just copied the binary from my 10.4 install into the expected location and tried to use it. However, as I expected, the results were not particularly satisfactory, given that the binary was built against a different X11 source tree.

After posting some of my compile issues to the X11-Users mailing list (archives are here), the code maintainer released a patch to the xorg code that fixed the symbol issues that had reared their ugly heads.
For those who are interested in making it work here’s what you need to do:

1. Follow the first seven lines under the section Source installation on the XDarwin wiki page
2. Change the configure instruction line to be as follows:
   ./configure --prefix=/usr/X11 --enable-xnest=yes --with-mesa-source=`pwd`/../Mesa-6.5.2
3. Continue with the rest of the source instructions as posted in the wiki page
4. After copying the new Xquartz binary over, copy the Xnest binary as well:
   sudo cp hw/xnest/Xnest /usr/X11/bin/
5. Don’t forget the manpage:
   sudo cp hw/xnest/Xnest.1 /usr/share/man/man1/

Now you have a nicely patched install of the latest fixes for Xquartz as well as the Xnest binary.

If only compiling Xpehyr was working now…sigh.

Resources:

• Applications supplied with the default X11 install on 10.5

Related posts

This entry was posted in work and tagged mac os x 10.5, operating systems. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.