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:
:1
determines the X11 screen to be used on the local workstation, screen 0 is the default screen used for X11
-geometry
set the screen resolution to use for the X11 window on the local workstation
-query localhost
determines which host to actually make the connection with
-terminate
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
When doing system administration it is often more convenient to connect to a server through some sort of remote connection setup rather than having to sit at a console in a datacenter. The comfort of one’s office (or living-room) is often far superior in terms of noise and temperature than the environs of the datacenter itself.
When setting up the RHEL5 server this week here at VSU, I was forced to use the Sun iLOM connection to do the initial install of the server. While I generally use command-line only tools, the ease of use one gains from the GUI tools can often make some tasks much simpler. Towards this end I decided to setup the server and my client to allow XDMCP sessions so that I could have full access to the GUI when necessary.
On the server there are a couple of things that you need to configure in order to make this workFirew:
- Firewall ports
- GDM configuration options
On the client you will need to configure the OS X firewall, as well as use the correct Xephyr connection syntax.
Continue reading