I got some comments and questions regarding my set up, so I figured that I would address them here.

A friend of mine asked why I was using SSH for TS/Remote Desktop connections when Terminal Services uses encryption natively for its connections.

I did a bit of research on this and here is what I found:

  • The protocol that is used by Remote Desktop Client is the Microsoft Remote Desktop Protocol (RDP).  Windows 2000 supports RDP 5.0. and XP Supports RDP 5.1.
  • RDP uses RSA's RC4 cipher. The encryption strength that is used is determined by the server, and can be up to 128-bits. It will also connect using a 40-bit or 56-bit key if that is what the server is using.
  • W2K Terminal Services has 3 levels of encryption (Low, Medium and High) which is configured on the server side. Low encryption specifies that only data you send from the client to the server should be encrypted. If you select Medium encryption, Terminal Services encrypts the data sent in both directions. If your client is a Win2K computer, Terminal Services uses a 56-bit key for Low and Medium encryption. If you connect with any other client, Terminal Services uses a shorter 40-bit key. If you select High encryption, Terminal Services encrypts data sent in both directions—like Medium, except that High encryption uses a much stronger 128-bit key.
  • From what I understand XP Defaults to a Medium Security model (56 bit both ways).
So what does all that mean? Simply that Remote Desktop does provide encryption as noted above and if that is all you need, go for it. I am a bit concerned with the 56 bit key default for XP. I have not explored if it is possible to bump it up to 128 bits when you have XP on both ends.
 
But in my case, an important criteria that I was looking was secure direct access to my source control tree which is on my internal network.
 
I was familiar with using SSH on my Linux and FreeBSD boxes primarily as a replacement for Telnet. The things I like about it are:
  • It encrypts all traffic to effectively eliminate eavesdropping, connection hijacking etc.
  • It provides strong authentication. I like having the option of using PubKey authentication. I am one of those people who actually LIKE two factor authentication :-)
  • You can redirect TCP/IP ports through the encrypted tunnel.  For example I mentioned that I access my source control provider (Sourcegear Vault) via its Web Services API which is available on port 80 of my W2K box on my internal network. To access my source tree, I simply point the Vault client to localhost:8080. That traffic is automatically redirected via my encrypted SSH connection over the internet to the port 80 of my Vault Server. (Port 8080 because, my local dev machine is running its own web server on port 80).

    I could just as easily redirect IMAP, POP traffic here as well. Also do note that I mentioned that I am using my client machine over WiFi connections, so over the air snooping and eavesdropping is a possible concern which is addressed by having all important traffic going out over a SSH tunnel.
  • SSH is built on the premise of never trusting the network. That satisfies my paranoid side. :-)
Another option that I was not aware of, but was pointed out to me by Dana, is the OpenVPN package.  It looks very interesting and is something I will take a look at to see if it meets my needs.
 
UPDATE:My friend who likes Terminal Server sent me a couple of links on Terminal Services on XP, Win2k3.