Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I need to figure out a way to force RDP(Remote Desktop) to respond to a specific port Instead of a RHP(Random High Port). I am not asking how to change what port RDP "Listens" on, but rather the opposite.

I am attempting to set up an experimental Forward/Reverse SSH Tunnel between two systems. I am using a third system as a Pivot point to hide my IP on the forward tunnel. But I want the system I am Remoting into through the Forward SSH Tunnel to send the response through a separate reverse SSH tunnel to a "Specified" port instead of a RHP. The basic idea is I want to be able to control what ports I want listening and or receiving, and I don't want anything to be random. With that said here is a snapshot of my set up.

Edit: All the IP addresses in the image have changed which will make it confusing later on when you read the logs I edited into the question. The new IP addresses are:

  • KGRAVES - 10.0.10.113
  • DEVILSMILK - 10.0.10.121
  • DUCLAW - 10.0.10.120

enter image description here

As you can tell on the last step my RDP session is being sent back through the Reverse SSH Tunnel like I want it. So I have two pipes for my RDP session. But it is sending it back on a RHP and I can't figure out how to tell it to send it to a specific port, say :44444 for example.

Does anyone know how to do this?

I need this done a specific way. These are the ports I Have to use. I have already set up Duclaw to listen for RDP on port 1337 instead of 3389. I know that this isn't by any means the easiest way to do this.

I need the remote desktop connection to "appear" as if it is coming from devilsmilk. But I want duclaw to send the response directly back to kgraves-pc without going through devilsmilk. So to kgraves-pc the RDP session is being sent to the localhost which is then forwarded via ssh tunnel through devilsmilk to duclaw, but the RDP packets that are being received in response to that connection are received directly from Duclaw.

My commands are as follows and all of them are performed from the exact same CYGWIN ssh console on kgraves-pc except for the mstsc connection which I did from another CYGWIN terminal on kgraves-pc:

CNO\kgraves@KGRAVES ~
$ ssh -vg -L 3333:localhost:6666 misfitred@devilsmilk
OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to devilsmilk [10.0.10.121] port 22.
debug1: Connection established.
debug1: identity file /home/kgraves/.ssh/id_rsa type 1
debug1: identity file /home/kgraves/.ssh/id_rsa-cert type -1
debug1: identity file /home/kgraves/.ssh/id_dsa type -1
debug1: identity file /home/kgraves/.ssh/id_dsa-cert type -1
debug1: identity file /home/kgraves/.ssh/id_ecdsa type -1
debug1: identity file /home/kgraves/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
key_read: uudecode devilsmilk ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwVZRlnAgPRPxTx           cbTPALg5XPpOnAMhJabQ3Dv/7a95eqe5l7XnKRciYQZ41B61DRgXCzC/M9ObknMR79zG0mkSl+jQTGJ7           klol7nw0+U1dNFknv4fOn+YGAsqECclWEow3OK5xRcla5eBekRGWjrZ7Wbs4F3FeKGQNqU/OuGvdSaQb           3nqgLPGTZfRhNtykQvpNzXw5cjO7XvM0BBv9di4JblLx9Fk3iq2KwdgWmK9uFDPYjU1gkHR8hk+bns1t           16KFcyDKnzhR1CblU6JT/wlBtnFa11no1UJBEHC2UQy8trwkMU6NqUt0X+D/XqW5F6+uWNc/dY97CCky           9HdfWNGQ==
 failed
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA b5:d6:eb:64:50:2f:40:04:32:10:bb:4f:a8:d3:f5:37
key_read: uudecode devilsmilk ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwVZRlnAgPRPxTx           cbTPALg5XPpOnAMhJabQ3Dv/7a95eqe5l7XnKRciYQZ41B61DRgXCzC/M9ObknMR79zG0mkSl+jQTGJ7           klol7nw0+U1dNFknv4fOn+YGAsqECclWEow3OK5xRcla5eBekRGWjrZ7Wbs4F3FeKGQNqU/OuGvdSaQb           3nqgLPGTZfRhNtykQvpNzXw5cjO7XvM0BBv9di4JblLx9Fk3iq2KwdgWmK9uFDPYjU1gkHR8hk+bns1t           16KFcyDKnzhR1CblU6JT/wlBtnFa11no1UJBEHC2UQy8trwkMU6NqUt0X+D/XqW5F6+uWNc/dY97CCky           9HdfWNGQ==
 failed
The authenticity of host 'devilsmilk (10.0.10.121)' can't be established.
RSA key fingerprint is b5:d6:eb:64:50:2f:40:04:32:10:bb:4f:a8:d3:f5:37.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'devilsmilk' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kgraves/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Trying private key: /home/kgraves/.ssh/id_dsa
debug1: Trying private key: /home/kgraves/.ssh/id_ecdsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to devilsmilk ([10.0.10.121]:22).
debug1: Local connections to *:3333 forwarded to remote address localhost:6666
debug1: Local forwarding listening on :: port 3333.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 0.0.0.0 port 3333.
debug1: channel 1: new [port listener]
debug1: channel 2: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Last login: Wed Jan 30 16:13:02 2013 from kgraves.cno.local
[misfitred@devilsmilk ~]$ ssh -vg -L 6666:localhost:1337 kgraves@duclaw
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to duclaw [10.0.10.120] port 22.
debug1: Connection established.
debug1: identity file /home/misfitred/.ssh/id_rsa type 1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'duclaw' is known and matches the RSA host key.
debug1: Found key in /home/misfitred/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: publickey
debug1: Offering public key: /home/misfitred/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: password
kgraves@duclaw's password:
debug1: Authentication succeeded (password).
debug1: Local connections to *:6666 forwarded to remote address localhost:1337
debug1: Local forwarding listening on 0.0.0.0 port 6666.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on :: port 6666.
debug1: channel 1: new [port listener]
debug1: channel 2: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Wed Jan 30 15:55:29 2013 from devilsmilk.cno.local
"tty" option detected in CYGWIN environment variable.
CYGWIN=tty is no longer supported.  Please remove it from your
CYGWIN environment variable and use a terminal emulator like mintty,
xterm, or rxvt.

kgraves@DUCLAW ~
$ ssh -vg -R 3333:devilsmilk:6666 kgraves@kgraves
OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to kgraves [10.0.10.113] port 22.
debug1: Connection established.
debug1: identity file /home/kgraves/.ssh/id_rsa type 1
debug1: identity file /home/kgraves/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA de:1c:37:d7:84:0b:f8:f9:5e:da:11:49:57:4f:b8:f1
debug1: Host 'kgraves' is known and matches the ECDSA host key.
debug1: Found key in /home/kgraves/.ssh/known_hosts:3
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kgraves/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interacti           ve
debug1: Next authentication method: password
kgraves@kgraves's password:
debug1: Authentication succeeded (password).
Authenticated to kgraves ([10.0.10.113]:22).
debug1: Remote connections from LOCALHOST:3333 forwarded to local address devils           milk:6666
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: remote forward failure for: listen 3333, connect devilsmilk:6666
Warning: remote port forwarding failed for listen port 3333
debug1: All remote forwarding requests processed
Last login: Wed Jan 30 16:21:12 2013 from duclaw.cno.local
"tty" option detected in CYGWIN environment variable.
CYGWIN=tty is no longer supported.  Please remove it from your
CYGWIN environment variable and use a terminal emulator like mintty,
xterm, or rxvt.
_____________________________________________________________________________
##From separate CYGWIN Terminal##
CNO\kgraves@KGRAVES ~
$ mstsc /v:localhost:3333 /f

CNO\kgraves@KGRAVES ~
$
_____________________________________________________________________________

kgraves@KGRAVES ~
$ debug1: Connection to port 3333 forwarding to localhost port 6666 requested.
debug1: channel 4: new [direct-tcpip]
debug1: Connection to port 6666 forwarding to localhost port 1337 requested.
debug1: channel 4: new [direct-tcpip]
debug1: channel 4: free: direct-tcpip: listening port 3333 for localhost port 66                          66, connect from ::1 port 49496, nchannels 5
debug1: channel 4: free: direct-tcpip: listening port 6666 for localhost port 13                          37, connect from 127.0.0.1 port 48808, nchannels 5
debug1: Connection to port 3333 forwarding to localhost port 6666 requested.
debug1: channel 4: new [direct-tcpip]
debug1: Connection to port 6666 forwarding to localhost port 1337 requested.
debug1: channel 4: new [direct-tcpip]
$ debug1: channel 3: free: direct-tcpip: listening port 3333 for localhost port 6666, conne               ct from ::1 port 49495, nchannels 5
debug1: channel 3: free: direct-tcpip: listening port 6666 for localhost port 1337, connect                from 127.0.0.1 port 48807, nchannels 5
$

Remote Desktop Connection Established. And as you can see it looks as if it is coming from devilsmilk on duclaw. But according to kgraves-PC it is coming back from Devilsmilk. So what I previously thought was happening actually wasn't. I thought Duclaw was sending the RDP session back to kgraves through a separate path but it turns out it wasn't. I'm not sure if it was working last time and I had a different set up or if I was imagining things. But now that I got it all reconfigured and back up and running after my issue with my ssh servers it is definitely not doing that anymore.

enter image description here

This is wireshark running on kgraves-pc during the RDP session:

enter image description here

So my problem still remains that I want Duclaw to send the RDP session back to Kgraves-pc through a entirely separate reverse tunnel. That is what I need to happen and can't figure out how to do.

Not only do I need duclaw to send it back in a separate tunnel straight to kgraves-pc without going through devilsmilk but I also need to control what Ephemeral port it sends it to. I want it to send it to port :44444 instead of a random ephemeral port. It is using :48809 randomly in the verbose debug ssh print out above.

Hopefully this clears it up, if not...sorry for confusing you even more.

share|improve this question
add comment

1 Answer 1

up vote 3 down vote accepted

Request

I need the remote desktop connection to "appear" as if it is coming from devilsmilk. But I want duclaw to send the response directly back to kgraves-pc without going through devilsmilk. So to kgraves-pc the RDP session is being sent to the localhost which is then forwarded via ssh tunnel through devilsmilk to duclaw, but the RDP packets that are being received in response to that connection are received directly from Duclaw.

Answer - No doable due to nature of TCP communication

I do not think that is doable, at least not with ssh tunnel only.

Lets look at the packet flow wanted/requested:

  1. kgraves-pc start RDP request to localhost:3333, which is a tunnel to devilsmilk:6666
  2. devilsmilk:6666 in turn tunnel to duclaw:1337
  3. duclaw:1337 RDP reply packet send to kgraves-pc

The above packet flow will not happen, at least not under normal circumstances. Lets give the above flow a bit more details:

  1. kgraves-pc start RDP request to localhost:3333, which is a tunnel to devilsmilk:6666

    At this point, kgraves-pc RDP client expect return packet coming from localhost:3333, nothing else.

  2. devilsmilk:6666 in turn tunnel to duclaw:1337

    At this point, to duclaw RDP server, the request is from localhost(duclaw ifself), and it will reply directly to it.

  3. duclaw:1337 RDP reply packet send to kgraves-pc

    Base on (2) above, this path is not happening at all.

Original Answer (Not what OP want)

On kgraves-pc, SSH command with tunnelling to achieve OP requirement.

ssh user@devilsmilk -L 3333:localhost:3389 -L 6666:10.0.10.130:3389 -R 23389:localhost:3389

-L 3333:localhost:3389 enable kgraves-pc RDP to devilsmilk with localhost:3333

-L 6666:10.0.10.130:3389 enable kgraves-pc RDP to duclaw with localhost:6666

-R 23389:localhost:3389 enable duclaw RDP to kgraves-pc with devilsmilk:23389

share|improve this answer
1  
OK, I will add the `-R rules to enable that. –  John Siu Jan 29 '13 at 20:16
1  
-R added and also modified the answer format for easier reading. –  John Siu Jan 29 '13 at 20:31
1  
I think I am getting it after reading the updated info. Need a bit more time to put all the tunnel together. –  John Siu Jan 29 '13 at 21:25
2  
I updated my answer. In shot, I don't think it is doable with ssh tunnel. –  John Siu Jan 29 '13 at 22:59
1  
Is Duclaw<-->Kgraves-PC traffic heavy or light? If it is light, it can be random broadcast or ssh keep-alive or something. –  John Siu Jan 30 '13 at 13:22
show 20 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.