XDMCP and a tale of a firewall

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.

%d bloggers like this: