Secure remote desktop control through ssh port forwarding

Take full graphical control of your remote machine. We'll use a vnc client and server pair. ssh will forward their connection through sshd on the gateway. As preliminaries, the server software needs to be running and configured on the remote. And, the ssh connection that affords the forwarding must be initiated from the client.

Prepare the remote server

Gain a command line connection to your server as root. In the file /root/.vnc/xstartup, obey the comment that reads "Uncomment the following two lines for normal desktop." If you don't uncomment those lines you'll get the lightweight twm window manager when launching X remotely. If you do uncomment, you'll get the same window manager/desktop environment as if you launched X locally. Probably gnome.

Now start the server

vncserver

It will ask you to establish a password that clients will use to authenticate themselves. Choose "password" as the password. vncserver should report that it's starting. The result should be that process Xvnc will be listening on port 5901. Here are 2 ways to verify that:

ps ax | grep Xvnc
netstat -pant

The server is ready for gui access now. Terminate your command line access:

exit

Prepare the local client

The 2 requirements are that you have a vnc client and set up an ssh port forwarding arrangment to your remote server's port 5901. If your client machine is linux you probably have the vnc client already installed. The command for it is "vncviewer". If it's Windows, tight vnc is a good client to install.

Now get the needed ssh forwarding arrangement in place. Your tool for that is the ssh command line or PuTTY. Your remote machine is 192.168.1.2xx. Use your tool to establish a correspondence between your local machine 127.0.0.1's port 592xx, and your remote machine's port 5901.

Get remote machine's desktop

At your client run:

vncviewer 127.0.0.1:592xx

or in TightVNC, for vncserver enter 127.0.0.1::592xx. If you connect the remote vncserver will ask you for the password then serve you the remote desktop. (Speed can vary a lot.) When you want to leave the desktop don't do it the normal way, from within the desktop. Rather, at the client side shut down the window containing the remote desktop. If you don't do it that way you may have difficulty getting the remote desktop back next time you connect.

You could do much the same thing with a Windows remote machine if it had a remote desktop connection server (XP Professional does, XP Home does not). And if you had a remote desktop connection client at your end. Windows has Start/All Programs/Accessories/Communication/Remote Desktop Connection, while linux has rdesktop.

Note: you may experience ssh's strenuous objection to connecting with your remote machine. We sometimes use ssh to connect to the gateway's sshd,  but other times forward those packets on to the remote machine and connect to its sshd instead. In both cases we use the same target domain name or IP (the gateway's). sshd maintains a host key, unique to the installation of sshd on that machine. Different copies of sshd have different host keys. Host keys are in effect machine identifiers. sshd sends its host key back to ssh whenever ssh makes a connection request. ssh records and remembers it. Using ssh if you try to connect to the remote machine when most recently you connected with the gateway, ssh will say, "Same machine name, but different machine!" and refuse to connect. On grounds that the target machine is an imposter. To get around this, give ssh a hostkey archive lobotomy by deleting the file "known hosts" in the connecting user's .ssh directory (linux or Windows). Then go ahead and connect.