C/D/H Talks Tech

Author:

Jason Cooper

I’ve been a C/D/H consultant for seven years. I have the dual distinction of being both C/D/H’s first Southeast Michigan consultant AND our first VMware Certified Professional.

Specializing in desktop management and virtualization, projects involving MetaFrame or System Center or VMware expose me to almost every corner of the enterprise, from messaging to networking to collaboration.

Technology is what I work at. Family and music are what I work for. In my copious spare time I enjoy gardening, camping, and cycling. I play guitar and a little harmonica, sometimes simultaneously. It occurs to me that I could duct tape a tambourine to my knee, but that would just be too weird.

More about Jason
Articles by Jason Cooper

Secure Shell is a standard tool in the bag’o'tricks of any Linux (and Unix) admin.  SSH (Secure Shell) is basically (forgive me security pros) encrypted Telnet (using TCP port 22).  Most Linux platforms have the SSH daemon enabled by default.  It provides a quick, easy way to get to a command line shell without physically accessing the console.

Perhaps the most common Windows SSH client is PUTTY (see http://www.chiark.greenend.org.uk/~sgtatham/putty/).  Many  admins use this tool everyday without knowing the full capabilities of the program.  Case in point, Putty can be configured to tunnel ANY protocol through SSH, providing a VPN of sorts for free using existing server hosts.  I use this configuration to access my home network remotely, but have also used it in a pinch to securely access client networks that don’t have a true VPN solution.  Few ISPs block port 22 – and none of them can monitor traffic inside the encrypted SSH session. 

I’ll describe using SSH to tunnel connection to a Windows host running RealVNC server.  Here are a few technical pre-requisites… 

• SSH host installed on a Linux server inside your network (SSH host).  On most Linux releases, no changes are required to the default SSH daemon configuration.
• A router that supports address translation (router), allowing port 22 to the address of the SSH host.
• Windows computer with RealVNC server enabled (VNC host).  (A good free version is found at http://www.realvnc.com/)
• Public IP addresses of the router and internal address of the VNC host.
• User names and passwords as needed for the VNC host and the SSH host.

I won’t get into the details of setting up Linux.  In either case, it’s impossible to cover all the possible permutations of versions and releases.  Suffice it to say, your router needs to be configured to pass SSH requests (port 22) through to the SSH host.  In this case, we’ll assume:

• Router address: 24.256.53.103. (Yes, I know that 24.256.53.103 is an invalid IP address.  If this bothers you, go learn to subnet IPv6 or something else useful…) 

• VNC host address: 10.22.70.103

PUTTY.EXE is downloaded for free here: http://www.chiark.greenend.org.uk/~sgtatham/putty/.  In effect, we setup the Windows machine running the PUTTY SSH client as a proxy for the VNC host, tunneled through SSH.  In Part 2, I’ll cover the client side configuration of PUTTY, and using the VNC client to connect to the VNC session.