RDP over SSH using port 443

I recently built my own home lab which lives on Hyper-V managed by System Center Virtual Machine Manager 2008 thanks to my Technet Subscription. I wanted to be able to manage this lab when I am at client sites in case I ever need to test something. Port 3389 is often scanned by hackers but Server 2008’s RDP is pretty secure just as Server 2003’s RDP was if you always keep your machine up to date due to RDP being encrypted traffic. But 3389 is often blocked on corporate firewalls. So I elected to use SSH listening on port 443 to RDP into my lab. How? Read on…

After bringing up my server, installing Hyper-V, patching it, and all that other good stuff, I installed FreeSSHD which is a free download here.

The first thing I did was configure FreeSSHD to utilize port 443 instead of port 22.

There are two ways to authenticate when we SSH in. One is Password Authentication and one is with Public Key Authentication. I elected to utilize Password authentication only and because of that, I set it to required. We can still use Public Key Authentication if we want but I decided Password Authentication is good enough for my needs.

I want to utilize port forwarding when I am utilizing an SSH client. You will see how we take advantage of local port forwarding when I show our Putty configuration below.

We then have to add the account we want to grant access to use SSH. Because this is a lab, I elected to use the Administrator account. In a production environment, the Administrator account should not be used as it’s not a good security practice.

The next thing we’ll want to do is set up a port forwarding rule on our home router. Portforward.com is a great site to assist you in how to forward your public IP traffic to your private IP on your lab server for port 443.

This means that any time you want to SSH in, you’ll have to SSH into your public IP. This can be annoying if you have a DHCP IP. Instead of paying extra monthly fees for a static IP from your ISP and not contributing to the “we need to go to IPV6″ cause, keep your DHCP address and use something like Dynamic DNS (DynDNS.org).

My home router is a Linksys router in which I am using the DD-WRT software. After signing up for a DynDNS.org account, you can tell your router to update your Dynamic DNS account so you can always use DNS and know it’ll hit the correct public IP.

Now let’s load up PuTTY and check out the configuration.

We’ll want to specify the hostname we are connecting to as well as port 443 since that’s what SSH is listening on and that’s what we’re port forwarding.

The final configuration step of Putty is to set up our tunnels.

This tunnel essentially allows us to map port 3391 to port 3389. Essentially the way this works is when we PuTTY to our server, we have a secure connection to our server. Because we enabled local forwarding on our SSHD server, we can create a tunnel rule in PuTTY so if we RDP to port 3391 it will map to 3389 on our server.

So after clicking Open we will get prompted for our Administrator credentials. You must use an account in which you granted access in FreeSSHD.

After hitting enter and being connected, we can now launch our RDP client. Because we used our forwarded port from 3391 to 3389, we will RDP to localhost:3391 and because we created that tunnel for our forwarded port, it will automatically connect to ServerIP:3389. ServerIP is the IP that is defined in the Tunnel settings in PuTTY.

As we can see in the following screenshot, everything works as expected and we can now successfully connect to our lab via port 443, have it be secure, and not have to worry about a port being blocked as 443 is rarely blocked .

There’s one more thing to consider. Because you are using port 443 for SSHD, you obviously won’t be able to use IIS on the box and have SSL use port 443 or use other applications that listen on 443. I am using System Center Virtual Machine Manager 2008 which does utilize port 443. When you install System Center Virtual Machine Manager, it gives you the option to modify the 443 port. I elected to use port 543 instead. Everything has worked perfectly and it’s been a month or so since I’ve had my lab up this way.