Hi all,
I'm trying have an alternative way of connecting into a Corporate network. Mostly in case the VPN down as I cannot also change the security policy.
I want to expose windows RDP over ssh tunnel.
I have 3 hosts in my scenario
1- Host a : Windows 2k8 has no internet access just only an outbound connection on Port 22 TCP .
2-Host b: AIX 5.3 has an ssh server running on it and can initiate outbound TCP connections to any host on the internet.
3-Host C : Solaris 10 has a public static IP and an SSH listening for incoming connections.
All I want is to expose RDP on Host A to Host C which is outside my corporate network How can I do this any Idea will be a great assist.
You can do a tunnel on ssh as a port forwarder, where it listens somewhere for the RDP client tcp connection and forwards it to the target desktop port 3389 (or whatever port you reconfigure to. For instance you can ssh localhost on a firewall host and make tcp port 3389 listen there and forward connections to the windows box port 3389.
If the ssh encryption is not a concern, there is a program tcpRelay.c that can listen of be an inetd child and forward to any given port, even allowing configuration of specific host access permissions and different destinations, as a general firewall tcp proxy.
@DGPickett Thanks for your reply more explanation required please
What I meant is to forward RDP on host A to host C through host B as a man in the middle.
Host A has no access to any other host except host B trough SSH connection via putty or plink or any ssh client and Host B has virtually ability to connect to any host outside my corporate network I want to forward RDP from host A though host B to be visible from host C.
I want the exact recipe in details if applicable Encryption is a big matter in my scenario .
Semantics cn cloud the issue. Every PC with RDP is a server, and the support dude has the client. The tcp client sends the first packet SYN, and if there is a listening socket, that replies with the second, reply packet SYN ACK. An ssh tunnel listens on one end of the ssh session host pair on some specified port, as a server, and forwards connections to the opposite end host to a new client socket connected to the host and port specified. So, ssh is the obvious tool, as long as one end is visible to each end. If you ssh localhost, the two middle hosts can be the same host.
Suppose on host A you "ssh -L 3389:C:3389 B", forwarding A:3389 to new client connections on B (high port) to port 3389 C, which is the target PC to be serviced port 3389. When your tech points his RDP client host D to A:3389, it will really be talking to the target PC RDP service. The RDP client D connects a socket on D:high-port to A:3389, A sends via ssh client app inside ssh connection to sshd server on B, which makes a new socket, connects it to C:3389, and everyone shuffles data flow both ways.
Security rules sometimes prevernt -L, but sometimes -R is legal, where the listening server part of the tunnel is on the sshd server end, and the new client sockets originate on the ssh client app.
Often, the problem is really simpler, and all that is not needed. A firewall E in the middle may able to see both C and D even though they cannot see each other, like if C is on the internet and D is on a 10. unroutable address. Using NAT or tcpRelay, it can listen for D and connect to C.
Now, if you want a dynamic service where many PCs can be the target, something like a web service could set up the forwarder or tunnel to the indicated host. For security, it is nice if there is a timeout and some filtering of incoming connections, so only D can temporarily get that connection to C:3389.