Brain on Fire » Blog feed Tim McCormack says words

Use your home computer from work (VNC over SSH)

Automated disclaimer: This post was written more than 15 years ago and I may not have looked at it since.

Older posts may not align with who I am today and how I would think or write, and may have been written in reaction to a cultural context that no longer applies. Some of my high school or college posts are just embarrassing. However, I have left them public because I believe in keeping old web pages alive—and it's interesting to see how I've changed.

I've got a handy tip for folks who have a desk job: Keep your personal and professional life separate by securely controlling your home computer from work (VNC over SSH). As long as you're aware of the advantages and disadvantages of this technique, it's very convenient and useful.

Edit 2006-10-8: I flubbed the ssh installation instructions. There is no "openssh" package. There is "openssh-client" and "openssh-server", both of which are necessary. You can install them both by installing the package "ssh".

Edit 2008-2-17: Changed local VNC listening port to 5901 to avoid port conflicts.

Thanks to Nicholas Fong for the original tutorial, which appears to be down at the time of this writing.

Assumptions

The instructions I give in this post assume that the home computer runs Ubuntu Linux and that the work computer runs Windows. If your work computer runs linux, you can use the putty and vncviewer commands instead of downloading Putty and Tight VNC.

Basic idea

(There used to be a diagram here, but it was hosted on Zooomr, which is long since dead. The caption was "The VNC programs are not aware of the SSH tunnel.")

SSH tunneling is a technique that allows sensitive data to pass through the larger internet without being tampered with or copied. Any sort of data can pass through the tunnel without the source and sink programs being aware of the situation.

VNC is a remote-desktop system that allows the user to view and control the desktop of a remote computer within a window on the local machine. Mouse and keystroke data is transmitted to the remote computer, and partial screen updates are transmitted back. The password used to start the session is only mildly encrypted.

If you mess this up, someone could take control over your computer without your knowledge. This happened to me. I had a very unprivileged account called "guest" (password: "guest") for roommates, parents, etc. to use to shut off my computer in case of thunderstorms, and when I installed an SSH server I forgot to consider this easily-entered account. A few days later I noticed that my network connection was a little too active, and I found and killed a process that was attempting to hack into other peoples' computers. (Linux RST-B trojan, if I recall correctly.) Didn't do any damage to my machine, but it could have used my internet connection indefinitely. So be sure to read up on securing your SSH server, or at least restrict logins to a single account... and make sure your password is very secure.

Setup

We'll set up VNC over SSH for a fictional user "Bob", and even throw in a free subdomain address for his home computer: http://sparky.no-ip.info/.

Home computer

Your home computer will be set up as a server for SSH and VNC.

  1. Install and verify No-IP so that you can use a domain name instead of an IP address to refer to your home computer.
    1. Register at no-ip.com.
    2. Add a host in your account (Hosts/Redirects -> Add), leaving the defaults in place. If you were Bob, you'd choose the hostname "sparky" on the domain "no-ip.info", giving the home computer the address "sparky.no-ip.info".
    3. On your home computer, install the No-IP software, which will update No-IP's records every half hour. (On Ubuntu, the package is no-ip.)
    4. Configure No-IP by running sudo no-ip -C and entering your No-IP login information when prompted. Accept the default value for the update interval and other options. (Here, there's only one host, and thus no ambiguity as to which DNS entry the No-IP client is updating. I'm not clear on how the service distinguishes between different hosts.)
    5. If you have a webserver running on your machine, you can verify successful No-IP configuration by visting the address you set up, e.g. http://sparky.no-ip.info/.
    6. Start the No-IP client for the first time with the command sudo no-ip. (By default, the client will automatically start every time your computer starts. This command is only needed if you aren't restarting any time soon.)
  2. Install and verify VNC server. (Ubuntu comes with remote desktop functionality right out of the box, but it will need to be configured to allow connections.)
    1. If you're using the Gnome display manager (if you don't know, then you are), go to System -> Preferences -> Remote Desktop.
    2. Under Sharing, allow other users to view your desktop and control it.
    3. Under Security, do not require confirmation, but do require a password. (Restricted to 8 characters, unfortunately.)
    4. Verify your VNC settings by running vncviewer localhost, but do not enter the correct password. If you do, your computer will undergo VNC loopback and lock up. If you are prompted for a password, your settings are correct. Hit cancel.
  3. Allow incoming port 8443 on the home firewall/router to let the SSH traffic in. (Use 8443 because your workplace firewall will likely let the traffic through on that port -- some websites still use 8443 for HTTPS traffic.) The details of this are completely specific to your setup at home.
  4. Install and verify SSH server on the home computer.
    1. Install the ssh package, giving you both an SSH server and client. (It is a metapackage that depends on both openssh-client and openssh-server.)
    2. Open the SSH daemon configuration file, located at /etc/ssh/sshd_config.
    3. Near the top of the config file, change the Port instruction from 22 to 8443.
    4. In the Authentication section of the config file, change the PermitRootLogin instruction from yes to no. (I may never understand why they allow remote root logins by default.)
    5. In the Authentication section of the config file, add the instruction AllowUsers bob.
    6. Apply the changes by restarting the SSH server with sudo /etc/init.d/ssh restart.
    7. Find your SSH fingerprint by using ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub. Write it down. The first time you log in remotely from any machine, you'll need to check this fingerprint against what Putty reports as the server's fingerprint. This is extremely important.

Work computer

You won't have to install anything on your work computer, but you will have to run some stand-alone programs.

  1. Download Putty and the Tight VNC stand-alone client on the work computer
  2. Create an ssh profile that you can reuse.
    1. Run putty.exe.
    2. Set the host name to your No-IP address or IP address. (e.g., spark.no-ip.info).
    3. Set the port to 8443.
    4. Under "Connection" -> "SSH" -> "Tunnels", add a tunnel: Set the source port to 5901, set the destination to localhost:5900, and click the "Add" button.
    5. Save your session: go back to the "Session" category, type "tunnel-home" in the text box under "Saved Sessions" heading, and click the "Save" button.

Usage

  1. On your work computer, open putty and run the "tunnel-home" profile.
  2. A terminal window will appear — log in using your username and password for your home computer. (If this is your first login from this machine, check to make sure the fingerprint matches. If not, don't enter your password!)
  3. Open VNC client and open a connection to localhost:5901.

Cautions

  • Prevent man-in-the-middle attacks by writing down your SSH server's signature and verifying it the first time you connect.
  • Keep port 5900 closed on your firewall. The VNC service accepts 8-character passwords at most, so brute force attacks are a concern. That's why we're only allowing connections from inside the firewall (via SSH.)
  • Keyloggers can monitor your keystrokes at work, including your SSH password.
  • Your boss can most likely view your screen over VNC.
  • VNC over SSH will eat up bandwidth. This may or may not be a concern.
  • Is it overkill? If you are only concerned about "sensitive" websites, you might just want an HTTP proxy.

Responses: 13 so far Feed icon

  1. #1415 | Wednesday, October 4th, 2006 at 21:19 (EDT)

    ron says:

    I installed the no-ip package as described in this article and have registered with no-ip, but when I try to do the following command, I get the following error: $ sudo no-ip -C

    Auto configuration for Linux client of no-ip.com.

    Connect to dynupdate.no-ip.com timed out Network must be operational to create configfile. Ending!

    Got any ideas why this would occur?

  2. #1425 | Thursday, October 5th, 2006 at 14:04 (EDT)

    Tim McCormack says:

    Perhaps you have a router or firewall that is blocking the outbound connection. The no-ip client connects to dynupdate.no-ip.com on TCP port 8245. I googled the error message and I didn't find any useful info on it.

  3. #1440 | Friday, October 6th, 2006 at 14:50 (EDT)

    Ron says:

    Yes, I had finally figured that out...just wasn't thinking. Still trying to figure out how to do port forwarding and get everything else set up properly. I didn't know which port to open up though. Thanks for the info... Would you happen to know what other ports I have to open up and whether or not they are for inbound or outbound traffic?

    Thanks Tim.

  4. #1443 | Friday, October 6th, 2006 at 18:07 (EDT)

    Tim McCormack says:

    Phew! I was hoping that would solve the problem, 'cause I wouldn't have been able to suggest anything else.

    That should be the only outbound port you have to open. Personally, I don't worry too much about outbound ports, since I basically trust what is running on my box. (Is this a dedicated firewall/router, or a software firewall?) Of course, if you have any unknown quantities on your network (friends' computers, open wireless, public terminals), it's not a bad idea to block all but explicitly allowed ports (http: 80, 8080, 443, 8443, mail: 25, 587, VNC: 5900, SSH: 22, and others.)

    Inbound ports are a different matter. If you're going to be relaying everything over SSH, just pick a port (like 8443), open that (inbound), and set SSH to listen on that port. If you run public applications (web server, ftp server, game server...), you'll want to open those as well, making sure the ports don't conflict.

    I'd also recommend picking a non-standard port for SSH because you are more likely to be probed for ssh on port 22. Not exactly security through obscurity, more along the lines of keeping script kiddies on their toes.

    And again, I can't stress the importance enough of 1) having a really good passphrase and 2) limiting ssh logins to a non-administrative account.

  5. #1471 | Sunday, October 8th, 2006 at 19:45 (EDT)

    ron says:

    Hey Tim, Ugh....ok...So I had to step back a bit. I've got no-ip working, I setup tightVNC server on ubuntu and did a port forward of 5900. I setup tightVNC viewer on my work machine and it actually worked...It was a "oh my god...it worked" moment. I setup my ubuntu desktop for remote viewing so I can control the desktop. So far so good. I just wanted to make sure that I could get it working without ssh first and I did...

    Now this is the tough part. SSH is just kicking my butt.

    root@ubuntu:~# ssh -v -v -v -p 8443 localhost OpenSSH_4.2p1 Debian-7ubuntu3.1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [127.0.0.1] port 8443. debug1: connect to address 127.0.0.1 port 8443: Connection refused ssh: connect to host localhost port 8443: Connection refused

    I noticed that the config options you specified here don't seem to exist or maybe deprecated(either that or I'm the one with the older version). I dunno...but permitrootlogin is not a parameter I can use and neither is AllowUsers...they do have just a Users parm in ssh_config tho which I assume is the same thing. Also, /etc/init.d/ssh restart doesn't exist. I have just rebooted my system for a lack of a better way. Oh, and sshd, doesn't seem to exist either....And yes, I did get the package and install it as you can see above.

    I hate to be a pain in the butt on the evening of Octoberfest and the day before Canadian Thanskgiving, but I need help Ah!

    At any rate, got any ideas here?

    Just to be complete, below is my ssh_config...

    Host *

    ForwardAgent no

    ForwardX11 yes

    ForwardX11Trusted yes

    RhostsRSAAuthentication no

    RSAAuthentication yes

    PasswordAuthentication yes

    HostbasedAuthentication no

    BatchMode no

    CheckHostIP yes

    AddressFamily any

    ConnectTimeout 0

    StrictHostKeyChecking ask

    IdentityFile ~/.ssh/identity

    IdentityFile ~/.ssh/id_rsa

    IdentityFile ~/.ssh/id_dsa

     Port 8443

    Protocol 2,1

    Cipher 3des

    Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

    EscapeChar ~

    SendEnv LANG LC_*
HashKnownHosts yes

    thanks, Ron

  6. #1474 | Sunday, October 8th, 2006 at 20:13 (EDT)

    ron says:

    ops....So, after rambling like I did above, I decided to check one more time to see if I did indeed have ssh server installed. And, yes, I sorta did, but I only had the client. Sorry 'bout that. Totally disregard my last email. I'm a complete idiot...but knowing it is half the battle(I hope) ! Thanks again for this blog Tim. --Ron

  7. #1475 | Sunday, October 8th, 2006 at 20:14 (EDT)

    Tim McCormack says:

    @ron: All the sshd files are daemon-related, which means you probably don't have the ssh-server installed. smacks forehead Oh, my instructions are incomplete. Just issue "sudo apt-get ssh" and you should be fine. That will install both the openssh-client and openssh-server packages. No wonder it wasn't working for you!

    Edit: @ron: We appear to have cross-posted. In any case, I'm glad you posted, because otherwise this howto would have stood incorrect indefinitely.

  8. #1975 | Wednesday, October 25th, 2006 at 23:40 (EDT)

    bhanu says:

    i am getting an error saying network connection refused...

  9. #1977 | Thursday, October 26th, 2006 at 00:15 (EDT)

    Tim McCormack says:

    I assume you are getting the error when you try to open a VNC session, and that you have SSH working.

    Test the VNC server setup: If you temporarily open up port 5900 on your home computer and don't start the SSH tunnel, can you connect a VNC client to your home machine from remotely?

    Test the SSH tunnel setup: Do you have a web server on your home computer? Try building an SSH tunnel on port 80 and visiting localhost:80 in your web browser at work.

  10. #7409 | Monday, January 15th, 2007 at 16:32 (EST)

    Nathaniel Schwartz says:

    I'm using xubuntu edgy and trying to follow your guide. It seems like it will all work, except that I don't have a "sharing" tab on my gdm. Any ideas how to get this, or what additional software I might need for xfce? Thanks!

  11. #7421 | Monday, January 15th, 2007 at 18:54 (EST)

    Tim McCormack says:

    @Nathaniel: If it helps, here's what my Remote Desktop preferences dialog looks like. It's not a tab, just a fieldset. The relevant packages I have installed are vino, vnc-common, and xvncserver. I also have tsclient, but I think that is only a client for Microsoft Remote Desktop.

  12. #7428 | Tuesday, January 16th, 2007 at 00:48 (EST)

    Nathaniel Schwartz says:

    Thanks Tim. I don't have that option under xubuntu. I'll have to read up some more on this stuff and see if I can get it working. I might have to go with regular ubuntu. :-(

  13. #94671 | Wednesday, March 9th, 2016 at 21:21 (EST)

    Computer Net Work | emergingloan.com says:

    […] Use your home computer from work … – I’ve got a handy tip for folks who have a desk job: Keep your personal and professional life separate by securely controlling your home computer from work … […]

Self-service commenting is not yet reimplemented after the Wordpress migration, sorry! For now, you can respond by email; please indicate whether you're OK with having your response posted publicly (and if so, under what name).