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).