In the process of setting up a new PC for my mother, I finally figured out how to get remote desktop sharing in Kubuntu Hardy working. You’d think the bog-standard (and default) krfb would work, but it crashed every time. Come to find out, after much searching, the solution boils down to this…
Shoot krfb in the head, use vnc4server and x11vnc.
Use synaptic or apt-get to install those and all their dependencies on the remote machine (i.e., the one that will become my mother’s PC). While you’re at it, uninstall krfb: good riddance.
Run vncpasswd and feed in an appropriate password that you’ll use to authorize yourself to the vnc session.
Log out, restart X (with Ctrl-Alt-Backspace, perhaps), log back in again to get all the X11 infrastructure up to speed.
On your local machine (i.e., mine), use SSH to sign in to the remote box:
ssh -p unusual-port -L 5900:localhost:5900 remote.PC.ip.addr
The -L creates a tunnel from your local machine’s port 5900 to the remote machine’s port 5900, through the authorized SSH session.
I use an unusual port because running SSH on port 22 on an internet-facing machine (even behind a firewall router) is just plain dumb. I doubt the unusual port provides much protection, but it should shake off a few script kiddies.
[Update: Just in case you regard shared-key authorization and a nonstandard port as evidence of clinical paranoia, read that. One of the comments notes that using a nonstandard port gets rid of all the low-speed zombies...]
Incidentally, the firewall router must forward the unusual port directly to the PC’s local IP address, which requires a bit of tweakage all by itself; that depends on which router you have. Word to the wise: do not use DHCP to get the PC’s IP address. Think about it.
That PC is also set up with my RSA keys, so that the kiddies can’t brute-force a username / password login attack. And, yes, I regenerated the keys after the Debian goof.
This is still on my LAN, so I use a dotted quad IP address (being too lazy to tweak /etc/hosts for a temporary machine), but you can use the host name maintained by DynDNS or their ilk for a truly remote box. See this post for the straight dope on making that work.
Then fire up a remote-desktop client like, for example, krdc on your local PC, with the “remote desktop” address aimed at:
That’s the local end of the SSH tunnel to the remote PC. It won’t work if you aim it at the remote machine’s IP address, because it’s not watching for incoming connections (nor is the router forwarding them).
Type in the password and shazam you should see whatever’s appearing on the remote desktop. Mouse & keyboard control should work just fine, too. Word to the wise: make sure your local monitor is bigger than the remote monitor; while you can scroll around or scale what you see, that’s icky.
It should be obvious that you cannot “switch users” to a different X console on the remote box and expect it to work. I tried it, just for grins, and it doesn’t. You could probably tunnel another session in through port 5901 (or 5900 + whatever the X11 console might be), but I haven’t tried that.
Last year I set my mother up with Verizon’s cheapest DSL service: 768 kb/s down and 16 kb/s up, all for a whopping 15 bucks plus tax a month. Yes, that’s 16 kb/s: slower than old-school dial-up modems. Sheesh & similar remarks. So all this fancy remote-desktop GUI stuff won’t work for diddly with the PC in her apartment.
SSH and the command line rule!