Easy RDP over SSH Instructions

F

farmdwg

n00b
Joined
Jun 6, 2004
Messages
34
I thought I would throw this out there for those looking for a secure way to use RDP over SSH. Here is some background on why I am using SSH with RDP. I work for a security company and we only have a limited # of ports open to the internet, port 22 being one of them. Many times my wife might have an issue with her computer and instead of her calling me and me telling her how to fix it, I just use RDP to get to my home network. I initiate an SSH session out of our network over Port 22, and tunnel 3389 within the SSH session.

Unfortunately I am also running XP here at work and when you try to call 127.0.0.1 it tries to connect locally instead of going out the SSH tunnel. So I just use 3390 for my local port but map it to 3389 at home. This will make more sense on why I have steps 4, 7 and 10.

Please let me know if you have any problems with the below process and I will try to clarify/fix if needed.


*********************************************************************************

XP Pro (Win2k Server with Terminal Services) with Remote Desktop

*********************************************************************************


1. Go to http://sshwindows.sourceforge.net/ (Package - http://sourceforge.net/project/showfiles.php?group_id=103886&package_id=116570) and download OpenSSH for Windows. Install package. Once installed, there is a READ ME/QuickStart that shows you how to create a local group and register your local windows user.

2. Go to your home router and forward port 22 to your XP Pro system.

3. Enable Remote Desktop (My Computer - Properties - Remote) on the XP system.

Following Steps to be done on your work system.

4. On your XP work system, create the directory 'C:\RDP' and copy the following files to this directory.

C:\WINDOWS\system32\mstsc.exe
C:\WINDOWS\system32\mstscax.dll

5. Go to C:\RDP and right click on mstsc.exe and select Properties. Change the Compatibility mode to Windows 98/Windows ME and then Click OK.

6. Go to http://www.mirrors.wiretapped.net/security/cryptography/apps/ssh/SSH/ and download the SSHSecureShellClient-3.2.9.exe program. Install it on your work system.

7 . Launch SSH Secure Shell and go to Edit - Settings - Tunneling. Add an Outgoing tunnel with the following:

Display Name: RDP
Type: TCP
Listen port: 3390 with "Allow Local Connections Only" checked
Destination Host: the NetBIOS name or IP address of your XP Pro system
Destination Port: 3389

8 . Click OK to close the Settings box.

9 . Use quick connect and use the following:

Host Name:
User Name: the windows user that you use to log into your XP Pro system
Port: 22

You need the IP address of your router's public ip address. I use www.dyndns.org configured on my router. So then I can just use myname.gotdns.com. If your router doesn't support one of the dynamic DNS providers, the software client will work as well.

When connecting accept the host key and then use your XP Pro system's password when prompted.

10. Once SSH has connected, launch Remote desktop from C:\RDP\mstsc.exe and use the following:

Computer: 127.0.0.1:3390

Also, go to the Options tab -> Experience and selelct Broadband for connection speed.
 
So I forgot to give you some background on why I am using SSH with RDP. I work for a security company and we only have a limited # of ports open to the internet, port 22 being one of them. Many times my wife might have an issue with her computer and instead of her calling me and me telling her how to fix it, I just use RDP to get to my home network. I initiate an SSH session out of our network over Port 22, and tunnel 3389 within the SSH session.

Unfortunately I am also running XP here at work and when you try to call 127.0.0.1 it tries to connect locally instead of going out the SSH tunnel. So I just use 3390 for my local port but map it to 3389 at home.

Hope this helps.
 
Makes perfect sense. It's a lot easier to use SSH out than to convince security services to open an MS specific port. :eek:

(and by the way I have the good sense not to ask them in the first place)
 
Sorry guys. I found a mistake.

I updated Step 10.

It used to say C:\WINDOWS\system32\mstsc.exe, but it should read C:\RDP\mstsc.exe
 
I'm curious, since RDP apparently has RC4 encryption couldn't you just set it to port 22 in the registry and connect to it? Or would this pose potential security issues?
 
sgt said:
I'm curious, since RDP apparently has RC4 encryption couldn't you just set it to port 22 in the registry and connect to it? Or would this pose potential security issues?
Click to expand...

Won't work, because most corporate firewalls filter up to the application layer, and will check to make sure port 22 traffic is SSH traffic. Tunneling other protocols through SSH will defeat these firewalls (as long as port 22 is open).
 
seanx said:
Nice, this should be added to the Networking FAQ
Click to expand...

Perhaps the Security FAQ as well, or at least a note. Then again, that's assuming I ever get some free time at home to do it.

Back to work.....
 
korpse said:
Won't work, because most corporate firewalls filter up to the application layer, and will check to make sure port 22 traffic is SSH traffic. Tunneling other protocols through SSH will defeat these firewalls (as long as port 22 is open).
Click to expand...
im curious....how can a firewall tell the difference between encrypted ssh sessions (say when you use pub/private key auth instead of password) versus say https encryption traffic? I have used ssh to tunnel traffic over 443 before because it was one of two ports allowed, and i figured that 443 would be the best to do it over simply because its just sending out encrypted traffic over a port that _should_ have traffic like that on it...
 
The receiving end is the one that will determine if the traffic is appropriate. In theory you could have every application use the same port and HOPE that the distant end is smart enough to discern one traffic type from the other. To mitigate this chance of failure/conflict we use different sockets (protocol + port).
 
farmdwg said:
4. On your XP work system, create the directory 'C:\RDP' and copy the following files to this directory.

C:\WINDOWS\system32\mstsc.exe
C:\WINDOWS\system32\mstscax.dll

5. Go to C:\RDP and right click on mstsc.exe and select Properties. Change the Compatibility mode to Windows 98/Windows ME and then Click OK.
Click to expand...


Just one question... why are these steps necessary? Seems to work fine without compatibility mode...
 
So the reason why you need to copy the files to a new directory is that on most XP systems (I have seen a few where you didn't need to do this... why, I don't know at this point.). is when you call 127.0.0.1(3389 implied) you will most likely get the following error.

rdp.gif


Here are some comments on this.

The limitation of Windows's XP Remote Desktop client is that it refuses any connection from the localhost (127.0.0.1) to the localhost with the following error message: "The client could not connect. You are already connected to the console of this computer. A new console session cannot be established". In order to be able to tunnel this through SSH, this limitation must be broken. The first idea was to hack the client executable and remove the limitation but it's simpler than that. I noticed that if you run the executable mstsc.exe from another operating system than XP, the limitation does not exist. Drilling a bit into that, it is possible to run mstsc.exe on Windows XP to the localhost by using application compatibility with older windows 9x.

A while ago we ran into this issue and found a fix that was particularly ugly. You would copy the mstsc.exe and mstscax.dll files from system32 to another folder, and change the compatability mode properties on them to Windows 95. You can then connect to localhost. Why it works? Who knows. Except that while that works connecting to remote workstations and Terminal Servers initially, once the Terminal Server is moved into licensed mode it stops. This happens because the licensed TS connection requires a key that is written to the local clients registry. And in compatibility mode, you can't write to the registry.

Hope this helps.
 
farmdwg said:
So the reason why you need to copy the files to a new directory is that on most XP systems (I have seen a few where you didn't need to do this... why, I don't know at this point.). is when you call 127.0.0.1(3389 implied) you will most likely get the following error.

rdp.gif


Here are some comments on this.

The limitation of Windows's XP Remote Desktop client is that it refuses any connection from the localhost (127.0.0.1) to the localhost with the following error message: "The client could not connect. You are already connected to the console of this computer. A new console session cannot be established". In order to be able to tunnel this through SSH, this limitation must be broken. The first idea was to hack the client executable and remove the limitation but it's simpler than that. I noticed that if you run the executable mstsc.exe from another operating system than XP, the limitation does not exist. Drilling a bit into that, it is possible to run mstsc.exe on Windows XP to the localhost by using application compatibility with older windows 9x.

A while ago we ran into this issue and found a fix that was particularly ugly. You would copy the mstsc.exe and mstscax.dll files from system32 to another folder, and change the compatability mode properties on them to Windows 95. You can then connect to localhost. Why it works? Who knows. Except that while that works connecting to remote workstations and Terminal Servers initially, once the Terminal Server is moved into licensed mode it stops. This happens because the licensed TS connection requires a key that is written to the local clients registry. And in compatibility mode, you can't write to the registry.

Hope this helps.
Click to expand...


Hmm, maybe it works for me due to the fact thet I have terminal services turned off on the XP box that I am connecting from...
 
Wow, oh wow. Thank you for your post. I have struggled to understand SSH in the past and never quite got it.

I followed your post and suddenly the light bulb went on and it all made sense. I immediately closed the 3389 port that I had open on my home router and opened port 22 so that my 2k3 server login is no longer available for someone to try.

It also solved a problem I was having in that one of my outside Unix programmers is going out of country for a few weeks. I setup the OpenSSH server and redirected the port for the app that he uses and it works like a charm. He and I were really worried if something were to happen but now that he can remotely access the server we are breathing easier (plus it will save me $$$ by not being charge for his 1 hour drive when there are quick fixes to be made).

The only problem I am having is that it seems to lock up for no reason on Win 2003 Servers and requires a reboot to get the service started again. I tried two of them at work with the same result. I've sinced moved it to an older Win 2000 server and it has been fine. My 2003 server at the house has had no problems though.

Thanks again. :D
 
Very nice little guide. :)

Of note, you can have alternatives:

- Use PuTTy instead of SSHSecureShellClient-3.2.9.exe. This is a smaller little tool, but does the same things: ssh connection, can open a listening local port and forward it to destination, tunnel over ssh...

- Use VNC instead of RDP; use UltraVNC if you want better features/encryption

- To find your IP, your wife can go to www.whatismyip.com to get it quick instead of a dynamic dns service

And of course the applications of this guide in other realms is very useful, for instance forcing mail checking over SSH to a home mail server, etc. Once you learn how to tunnel one thing, you can conceivably tunnel many other things. This is very useful to people on insecure networks like cafe's, hotels, bookstores, client sites, etc. :)

Again though, excellent guide!
 
You must log in or register to reply here.
Back
Top