SO I am building a SSH gateway to place in between some terminal servers we have at the office. The cool thing about the SSH server is that it will compress the RDP traffic and redirect the client to the internal RDP server.
What I am envisioning is a to build a small python app which will allow a user to login to a mysql database which will have some published app information, this information will be sent back to the client upon successfully logging in and tell the client which ssh server to connect to and which internal terminal server the client should call the rdp client to.
In essence the client connects to the ssh server and port forwards RDP to the local machine and then creates an RDP file that is autostarted by the localmachine which tells it to connect to itself at port 3389. That port will be forwarded automatically to the server running in the datacenter via ssh.
This way the only port that needs to be opened at the client end would be port 80 which is just web traffic port- I am going to have the SSH server listen on that port. Everything will be sent thru SSH so no RDP configuration on router.
I have tested it and file transfers work faster from RDP as well as screen refreshes. PDF rendering is alot smoother and I also like the fact that it is using SSH security and the data is encrypted.
Just another way opensource, ubuntu, python, ssh is helping me out.
Subscribe to:
Post Comments (Atom)
Posts
5 comments:
Not sure if I am understanding exactly what you want to do but RDP forwarding is already supported in the ssh client.
What I have is a Linux ssh server (CentOS) visible from the Internet and internal Windows servers not visible from the Internet, but reachable from the ssh server.
From my Linux (Kubuntu 8.04) laptop, I use the following command:
ssh user@outside_address_of_ssh_server -L 3389:internal_ip_address_of_windows_server:3389
I then fire up my remote desktop client (Gnome frontend for rdesktop) and enter 127.0.0.1 as the target address.
The ssh client redirects all data for port 3389 through ssh and the server redirects it to the windows box.
Benny
Yes, if you have ssh client installed on windows and don't mind going into a command prompt and you know the internal ip of the server and the user knows that now it is being forwarded and they connect their rdp client to themselves - Yes - you can do it this way. What I built is a portal application so your clients do not need to have ssh client, they do not need to know the intenal ip or ports, they do not need to know to open rdp client and launch it to themselves onto the forwarded port. Instead an administrator logs into the ssh gateway via a webinterface, adds published apps which expose the internal servers, the users simply launch a portal can see the apps they are assigned, click on them and voila an embedded ssh client launches in the background and gets all the necessary information and their rdp client is called and they connect, the user doesn't even know they used ssh or the internal or external port or even that they are connecting to rdp thru a forwarded port. And since it is a single exe no ssh install, no commandlines and no command prompt. Plus the applications are centrally managed by admins so they can changes server internally or add ssh exposed services without having to relay information to the client. Plus clients do not need to worry about adding ssh keys etc, it is all handled by the portable app. Basically it is a ssh equivalent of the metaframe webinterface.
ssh can expose any service, the portable portal application i wrote can allow admins to centrally push rdp, xdcmp, ftp, www, wedav to windows users so far. I have a generic type that can be published in the admin piece also which forwards the port but does not have an associated application so the portal just forwards the port in this case and the user needs to launch the desired app and connect to the service. Good for MS SQL, or Active Directory management, etc.
But with www, rdp, xdcmp, ftp and vnc - it has built in vncviewer, embedded filezilla, calls the mstsc.exe on the local machine for terminal services on x86 and x64 windows and for xdcmp i am playing with several windows xclients right now. The portal has grown in size to about 30mb single exe but it has everything included in it and no install, just double click and connect.
You could also setup an Adito SSL VPN. Very easy. Your users login to the VPN portal web page and can launch RDP sessions that you specify via icons. It also would allow you to direct traffic to you other internal file shares, intranet, etc.
Hey JM,
Thanks for reading my blog.
VPN is always a solution. And believe me - being in a datacenter - alot of clients need their VPN.
I find VPN has some limitations. It requires you give your end user an IP address on your local segment so they can broadcast and "speak" to your internal servers.
For my setup, I have thirdparty clients that need to only get to their own server or application and they may exceed 255 users, I really do not want to separate out a segment of my local lan and maintain that segment for each client's VPN traffic.
With the SSH solution gateway, they all share one ip, which for me is a maintenance saver and plus with the ssh gateway I can cluster them so they throttle bandwidth for connecting users amongst themselves. I can say if you are above 40% utilization check ssh2gateway and if it is under 40% pass the client to it. All without the client knowing. I can say client A gets a route to just this one server and nothing else. They have no internal address, they are just forwarded the servers port to their local pc's port and make the connection their. In essence if they were using SQL manager, they qould connect to our service and click on SQL manager icon on web interface. Our app would connect through our SSH gateway, forward the internal server's port running SQL, forward that port for that user to the user's local PC and then automatically open up their local SQL manager and connect it to their localhost running on that port. In essence the client connects to themselves to pass the data securely to us in the datacenter. The client's PC is never really inside our network. No change of virus infection cause they are not protected. In a VPN scenario, you could get infected as the pc is really inside you lan broadcasting.
I googled Adito - I have never used it and it looks very cool. I think in most situations, you are right. It is a great free solution and I might throw it in my networking toolbelt but the SSH gateway is great for us which is why we built it. I think I would mostly likely use Adito if I was setting up a connection for just one company's employees or maybe if I was asked to go into a client's network and give them a remote tool for their own employees and not worry about their partners or vendors, etc.
Let me know what you think. In the meantime, I think I might put Adito in my todo to check out next week. Thanks.
Post a Comment