Review: VNC Over SSH: The next best thing to being there
Volume Number: 20 (2004)
Issue Number: 7
Column Tag: Review
Review: VNC Over SSH: The next best thing to being there
by Aaron Adams
Securely control a remote Mac with two pieces of free software
The ability to remotely control a machine can come in handy for a variety of reasons, whether the purpose is system administration, or helping a friend. Apple's most recent remote control offering, Remote Desktop 2.0, can be overkill when it comes to a simple one-to-one connection between machines. Most users won't need all the features included in Remote Desktop; it's intended for labs and other environments that require the management of large numbers of machines at once, not the remote control of a single machine. Freeware VNC, on the other hand, fits the one-to-one bill perfectly. VNC stands for Virtual Network Computing, and it allows a user to control a remote machine as if he were sitting at the desk in front of it.
VNC is certainly a useful tool for those who need something simpler than Remote Desktop. However, it's the wild wild web out there, and security is a major consideration. VNC was developed at a time when security wasn't the same priority as it is now, and the data transmitted between a VNC server and client is unencrypted. Passing login names and passwords, or other sensitive data, over the public Internet in the clear isn't a good idea, and neither is advertising the fact that a machine can be controlled via VNC by leaving its corresponding TCP port open. Is there some way to keep VNC traffic from prying eyes?
Yes! The solution comes in the form of another piece of freeware included with every Mac: Secure Shell. SSH is the encrypted replacement for plain-text telnet, a command line utility used frequently on the old text-based Internet, with a few added features thrown in for good measure, including the ability to encrypt traffic generated by other protocols. This process is called tunneling because the data travels inside an encrypted virtual pathway created by the communicating SSH pieces. To force VNC to use the tunnel, it has to be instructed to connect to the local machine at a certain port. SSH intercepts the traffic from the VNC client at that port, encrypts it, sends it to the SSH server at the other end of the connection, where it is decrypted and passed to the VNC server. Besides encryption, one other advantage of using SSH to tunnel other protocols is that a server only needs to expose a single port for SSH instead of an individual port for each service offered, such as additional ports for each possible VNC session. This prevents port scanners, and other miscreants, from discovering VNC on a target machine.
Making this encryption happen requires use of the *gasp!* command line! Most Mac users cringe at the thought of using the command line because it's so "un-Mac-like", but it's a powerful tool that's not very hard to learn, and quickly becomes an excellent exercise in abstract thinking. Don't shy away from encrypting VNC sessions because of Terminal fright.
On the remote machine...
Two things are required on the remote machine to prepare it to accept an encrypted VNC session: An SSH server and a VNC server. Enabling SSH on any Mac is as simple as going in to System Preferences, bringing the Sharing pane, and checking the box next to Remote Login. Make sure the connecting user has a username and password available on the remote box.
As for VNC, a great server is OSXvnc, available at popular download sites, such as Version Tracker or MacUpdate. OSXvnc is a straightforward application, and most of the options it presents are obvious and don't require an explanation. The two important things to point out are that, under the General tab, the port should be set to 5900 for the purposes of this tutorial, and that, under the Sharing tab, the Only allow local connections (SSH) box should be checked. Checking this box is important because it requires that the VNC session be encrypted via SSH and won't allow any unencrypted sessions to be established. It won't even let the VNC server advertise the usual VNC port. VNC remains totally hidden to the outside world.
OSXvnc has the option to require a password before the VNC session can be established. Providing a password is strongly recommended. A Startup item can also be configured that starts the server with the machine, and it includes a keepalive script that restarts the server should it close for some reason.
On the local machine...
Locally, a VNC client is needed to connect to the remote machine. VNC clients are a matter of personal preference, and again, popular download sites such as VersionTracker and MacUpdate have a selection.
And now for the part everyone has been dreading... the *gasp!* command line part! The following command serves to establish the tunnel between machines. Perhaps the best way to explain the command is to write it out and then dissect it piece by piece.
The following line needs to be entered in the Terminal:
ssh -NfL 5900:127.0.0.1:5900 user@remote.host
ssh - The command that starts the SSH client to create the tunnel.
* Start SSH with these options:
N Do not present the user with a command prompt on the remote machine after login is complete.
f After the user authenticates, put the SSH process, and hence the tunnel, into the background to free up the local command prompt for other uses.
L Forward a local port to a remote address, creating the tunnel.
5900: - The port on the local machine where SSH will listen for traffic. This port can be anything >1025, but for this example 5900 has been chosen because it is the port typically used for VNC traffic.
127.0.0.1 - The address of the machine that is the ultimate destination for the connection. This particular IP is a loopback address because in this case, the VNC client will be connecting to the same machine the SSH server is running on. Due to an SSH oddity, localhost is not valid here, you must use the loopback IP.
:5900 - The port where the VNC server is listening on the remote machine. Again, 5900 is typically the port VNC uses.
user - The username allowed SSH access on the remote machine.
@ "at".
remote.host - The hostname or IP address of the remote machine running the SSH server.
Fill in the variables with the correct values to establish an SSH tunnel for VNC. After pressing enter, a prompt requesting a password will appear. This is the SSH password for the user on the remote machine.
On the local machine, start the VNC client. Where it asks for a server, enter localhost. (Previous instructions said localhost could not be used at the command line because of an SSH weirdness, but it can be used with the VNC client. Just know that localhost is the same thing as 127.0.0.1. They are both a designator for the local machine.) Where it asks for a port, enter 5900, or if it asks for a display, enter display 0. Click the connect button, and enter the password for the VNC server. Congratulations, it's a tunnel!
Aaron Adams is a LAN administrator, a self-employed Macintosh consultant in Dayton, Ohio, and a former star of Apple's "Switch" ad campaign. He can be reached via e-mail at adamsa@mac.com.
