Inchoate Curmudgeon

While looking for an OS X alternative to the ESX Virtual Infrastructure CLient for accessing the console of a virtual machine hosted on ESX, I found this article. An example configuration for accessing the console for a client on the ESX server using VNC port 5901 using a password of “secret” would require adding the following entries in the .vmx file for the virtual machine.

RemoteDisplay.vnc.enabled = "true"
RemoteDisplay.vnc.port = "5901"
RemoteDisplay.vnc.password = "secret"

The instructions work for ESX, except for one small detail: the ESX server won’t accept remote VNC connections. There is likely some way to turn this on, but allowing remote vnc connections to a server is typically not allowed and is considered a security hazard.

The solution is too use ssh port forwarding. If the vnc port on the ESX server is 5901, you create a tunnel with the following ssh command:

ssh -L5901:localhost:5901 user@esxhost

where “esxhost” is the hostname of the esx server and “user” is an authenticated user on the esx host.

Once logged in, you can connect to vnc port 5901 using any vnc client on the ssh client machine you have just connected from. The host should be “localhost”, the port should be “1″ and the password should be “secret”. The console for the client on the ESX server should be displayed. My vnc client of choice on OS X is “Chicken of the VNC” but here are many alternative vnc clients for OS X and other operating systems.

Note that ssh is disabled by default for root on ESX server, so if the “user” for ssh access is root, you will either need to enable root access by editing /etc/ssh/sshd_config on the ESX server and set “PermitRootLogin” to “yes”, or use another user authenticated on the ESX console. The later method is more secure since enabling root ssh access to the console is inadvisable for production installations.

There are a number of great resources on the Web explaining how to combine VNC with SSH so that you can get a remote display of a desktop. The exact combination of tools will depend somewhat on the operating systems of your client and host machines, but there are a host of options for Windows, *NIX and OS X.

If you want a cheap and relatively easy alternative to traditional conferencing and collaboration services, this stuff works pretty well. I’m not going to repeat the detailed instructions in all the different resources, but the summary steps are:

• Create shell accounts on a bastion server for the people you want to see your desktop to connect to. If you are using Solaris, you can create a Zone for these accounts to boot when you need it.
• If you are using a cable modem on the server side of things, you’ll need to open a port for SSH clients to connect to, and make sure your bastion server is listening for SSH on that port.
• Start the VNC server on the machine with the display you want people to be able to see. You can optionally turn on or off the ability to control the mouse and keyboard.
• Start your favorite IM and crank up a group for the meeting.
• Publish the tunnel piece of the SSH command (e.g. -L5901:192.168.10.1:5901) applicable to your installation.
• Note that you can avoid the client-side VNC client requirement if your VNC server has a Web server component. In this case you use an applet provided by the VNC server software. Your tunnel would be to the Web server instance of your VNC server in this case. I haven’t tried this in combination with an SSH tunnel, but it should work.

There are a number of security concerns and annoyances, so this facility may not be for you:

• Creating a bunch of shell accounts on a bastion host is a pain, and you don’t want to do this for a lot people you don’t trust.
• You need an open port in your firewall or NAT router. This may proliferate open ports in your firewall for a number of reasons, for example if you are running NAT and are already pointing 22, the well-known SSH port, elsewhere.
• You may not really want people on your bastion to see anything else on your inside network but your VNC server. It should be possible to deal with this with a restricted shell of some kind, but this obviously increases the complexity of the configuration.
• There are probably a host of other security issues with this, but I’m not a security expert. I’d ping someone I know about this if you have any concerns. (You should have concerns.)
• For the VNC server side of this, it’s not the sort of thing you would do, or be able to do, in a typical, traditional office network. But if you are somewhere like that, you’ve got Webex, right?

IMO, the best use of this is for collaboration with a few close colleagues you trust. We do a lot of working from home at Sun and this is handy.

Sun has a nifty collaboration tool built on top of this technology, but the last time I tried it I had trouble getting it to work through our VPN and haven’t followed up. But this is kinda geeky-cool, and I can make it work all by myself, plus I don’t have to futz with VPN.

There is probably a Web 2.0 startup idea here somewhere, like some kind of simple registration and proxy service.