Greg Laden’s having problems with his ScienceBlogs site‘s commenting (those problems being that Movable Type sucks), so he’s started posting stuff on his old WordPress site. Stuff like this great Linux Journal video, showing you how to spawn a GUI-based program on a remote server over SSH.

I pointed out on that post’s comments, if you’re going to tunnel into the box, you’re better off to SSH in, then spawn VNC Viewer and redirect its output to your local machine. However, after I did so, I realized I’d made a tiny mistake about this — my reasoning behind this was that VNC’s compression is vastly superior to the compression afforded by using -C on the SSH command line. If you do spawn a full VNC session, you’re actually running the video through two layers of compression — one, from VNC Viewer to the VNC Server, and one from the local computer’s X server to the remote’s, to pick up the VNC Viewer output. This is more a logic flaw on my part than an actual issue, and in this way you can get a full VNC connection encrypted over SSH, so the technique is not without its merits.

This site also shows you how to forward a port over SSH. It’s tailored for RPM-based distributions, and slightly incorrect about the SSH command line to use, but still. Even tells you how to do it using PuTTY on Windows!

Here’s the magic:

sudo ssh -N -T -L 5901:192.168.1.100:6000 [email protected] &

If you try without the username@ip at the end, as shown on the site I just linked, SSH will just spit up a syntax text and quit.

You’ll need to be root or sudo this, as it’ll first ask for local privileges, and you’ll need an SSH-enabled account on the remote box. This command will connect your local port 6000 to the remote computer’s 5901 (VNC display 1), over SSH, and keeps the command running as a daemon in the background (the &). You can then use VNC Viewer from your local computer, to your own computer’s port 6000, and you’ll see the remote screen, tunneled through SSH and thus encrypted.

If you connect a bunch of these ports at startup, you can create a “bouncebox” of sorts if you want a single point-of-access for multiple servers. Try this with port 80 on each remote server and a different local port for each connection, and you can create a whole web of bounces on your internal network so you just need one NATted computer to give to your client / open to the net, and a whole slew of open ports on it will grant access to myriad things. This way you can also run iptables on that bouncebox and meter out who gets access to what from one centralized location.

Something like this was used at one of my previous jobs to grant access to servers in a super-secure data centre. I wasn’t one of the privileged few allowed access to this — I was but a mere LAN monkey at the time. I’ve since upgraded my skillset significantly after having moved on from the company, spurred on by a need to prove I’m as capable and clever as any one of their Linux guys. I’m getting there. And, it’s all self-taught, every shred of that computer knowledge that I use daily to bring home the bacon. Was going to be an English teacher, you see, until I realized computers are easier to deal with than people.