Remote desktop via ssh tunnel problem

Hello,

I am trying to set up ssh tunnelling for a Windows remote desktop connection.

I have ssh up and running on 'Server' with port 22 forwarded on my router. I can ssh to the router's external IP => Server just fine. I have set up a tunnel for vnc (Server port 5900) with putty by connecting to router external IP, tunnels source port: 5901, destination: localhost:5900. That all works great.

When I try to connect to remote desktop, set up a tunnel with source port: 3390, destination: localhost:3389, open mstsc and connect to localhost:3390 I get the initial connection prompt, enter in username and password, but all I get is a black screen which ends up timing out saying "This computer can't connect to the remote computer. The two computers couldn't connect in the amount of alloted time. Try connecting again. If the problem continues, contact your network administrator or technical support."

Sorry if this is hard to follow! BTW, I can connect to Server remote desktop via the LAN address.

What ssh server are you using? FreeSSHD never worked for me with remote desktop, I ended up removing freesshd and installing cygwin ssh server on my vista box.

I am running FreeSSHD. I'll give openssh or something else a try when I get home.

I tried running Openssh under Cygwin and that seemed to do the trick, very odd. Oh well, thanks for the help!

I think it's a bug in the freesshd code. I ran across the problem when I couldn't install an ancient version of quickbooks on my accountant's system, and it turned out running the installer over a vnc connection over ssh to a freesshd server caused the quickbooks install to crash. Running the installer from the local console worked fine.

I posted on the freesshd forum a few months ago but never got any reply or fix, so I just got a different ssh server for windows.

I'm not sure this is a freeSSHd problem. It could be a problem with the way the Remote Desktop server works. I've experience a pecuilar and strange problem when connecting to Remote Desktop through a ssh or proxy tunnel.

These are other thread I've found that seems to describe the same problem. Although possibly in a somewhat different setup:

• Remote Desktop killing SSH session, November 07, 2005, fogbugz.bitvise.com/default.asp?Tunnelier.2.3157.4
• Black screen after Remote Desktop Session, July 29, 2005 at 01:48:01 PM, tomshardware.co.uk/forum/54822-35-black-screen-remote-desktop-session

To connect to Remote Desktop (in Windows 7 at least, since that's what I tried) it seems like you need to run the ssh server on localhost, i.e. on the same IP-address or network interface that the remote desktop server is listening on. However, strangely, there is an exception to this since I can connect to the bridged VMware virtual machine desktops running in the server from an ssh server running on the server, but not the other way around.

An example of the setup can clear things up:

The router: 192.168.0.1
The remote desktop server, called the "server": 192.168.0.10
Another server on the same network: 192.168.0.11
The local remote desktop client: 192.168.0.12
The wan remote desktop client: WAN address (with access to both 192.168.0.10 and 192.168.0.11 through the router)

The local remote desktop client is used for testing and experience the same results as the WAN remote desktop client.

This summarizes what fails and what works:

ssh server on 192.168.0.10 and connect to remote desktop server on 192.168.0.10: ok
ssh server on 192.168.0.11 and connect to remote desktop server on 192.168.0.10: fails
ssh server on 192.168.0.10 and connect to remote desktop server on 192.168.0.11: ok

Remote Desktop is the only client/server application I've tried that fails if I try to tunnel it through a ssh server that is not running on localhost, i.e. on the same IP-address or network interface that the remote desktop server is listening on. I haven't used any other client/server sofware where it makes a difference if the ssh server is running on 192.168.0.10 or 192.168.0.11. It's more natural for me to run the ssh server on 192.168.0.11 since all other server software is on 192.168.0.11 rather than on 192.168.0.10. But 192.168.0.10 is my home desktop and I need to be able to connect to it from school. I can of course use another remote dekstop program like UltraVNC instead, which doesn't have this problem, but Remote Desktop is faster than any VNC program on the high speed and low latency connection that I have between home and school. And I haven't tried and won't try to tunnel to a Citrix XenApp server on 192.168.0.10 since it's to heavy to install (a default installation creates 25 services). So windows Remote Desktop is the preferred application for me to connect to my home dekstop.

It doesn't seem to be a problem with the ssh server since it affects all ssh servers I've tried; FreeSSHd, WinSSHD, OpenSSH in Cygwin and OpenSSH in Ubuntu 10.10 on a bridged server that's running in a VMware virtual machine inside server. The result is the same with all of them: The remote Desktop client sees a black window, or at best parts of the desktop, before an abrupt disconnection of the remote desktop connection occurs. The disconnection also disables all connections from the server, so that the ssh connection from the client fails at the same time. The Catalyst Control Center also crashes on the server. And if I have physical access to the server and try to login to the Windows desktop again on the server I get the message "The task you are trying to do can't be completed because remote desktop services is currently busy." After around 30 seconds the server is reset and I can login to it again and network connections can be established to it again.

The choice of ssh client doesn't matter, it's only that the ssh server runs on the same interface as the remote desktop server that matters. It makes no difference if you use PuTTY or Tunnelier or another ssh client on the remote desktop client.

I can also mentions that if I try to connect to the remote desktop server through a http proxy running in a ISA Server 2006 in a bridged VMware virtual machine (exemplified by 192.168.0.11) inside the server I get the same temporary lockdown/crash of the server. So it seems to be a general problem with routing a remote desktop connection thrugh a ssh or proxy tunnel.

Does anyone understand this behavior better? Is it a security feature in the remote desktop sever that goes wrong? Why can't connections (at least sometimes) be routed through another machine inside the network to the remote desktop server?

The reason I'm connecting to remote desktop through ssh is that I'm connecting from my school where the only internet access is through a http proxy. So the only internet access is http connections and only to port 80 and 443. So to connect to a remote desktop on the internet (in this case my home computer) I need to connect through a ssh client (and one that supports a http proxy, like Tunnelier or PuTTY).

Wow, that's 100% my case. I have a VMWare virtual machine running Ubuntu and OpenSSH. Connect to it from a remote network limited by a proxy to 80 and 443 port. Set up tunnel to RDP. When I logon, blank black screen, rarely with some partially drawn controls on it. And Catalyst Control Center crashes (even when I use RDP through TeamViewer's VPN. TeamViewer VPN does offer what I need, but it seems to me that the speed is very low, and connections are very unstable.

Maybe it has something to do with Catalyst Control Center (random guess)?

Thanks for confirming my problem.


I didn't try that. I currently use RD through SSH with WinSSHD listening on the same network interface (on the same ip address) that the RD server is running on since that works. (And since it's a server problem, you can use any SSH client you like to connect to this server. I use their Tunnelier, but PuTTY also works.) And I'll mention again that the RD server, which is also my home desktop, is Windows 7 64-bit.


Possibly. But then someone with Nvidia should be able to confirm that it works for them.

Hello, you can try LiteManager. I've no problems. it's a software for remote control.