Como especificar a qual porta o RDP responde?

5

Eu preciso descobrir uma maneira de forçar RDP (Área de Trabalho Remota) a responder a uma porta específica Em vez de um RHP (Random High Port). Não estou perguntando como alterar a porta RDP "Listens", mas sim o contrário.

Estou tentando configurar um túnel experimental Avançar / Reverter SSH entre dois sistemas. Eu estou usando um terceiro sistema como um ponto de Pivot para esconder meu IP no túnel para a frente. Mas quero que o sistema em que estou Remoting através do túnel SSH Forward envie a resposta através de um túnel SSH reverso separado para uma porta "Especificada" em vez de um RHP. A idéia básica é que eu quero ser capaz de controlar quais portas eu quero ouvir e receber, e eu não quero que nada seja aleatório. Com isso dito, aqui está uma foto da minha configuração.

Editar: Todos os endereços IP da imagem foram alterados, o que tornará confuso mais tarde, quando você ler os registros que eu editei na pergunta. Os novos endereços IP são:

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

Comovocêpodevernaúltimaetapa,minhaRDPsessionestásendoenviadadevoltapelotúnelSSHreverso,comoeuquero.EntãoeutenhodoiscanaisparaminhasessãoRDP.MaseleestáenviandodevoltaparaumRHPenãoconsigodescobrircomodizerparaenviá-loparaumaportaespecífica,digamos:44444,porexemplo.

Alguémsabecomofazerisso?

Euprecisodissofeitodeumamaneiraespecífica.Estassãoasportasqueeutenhoparausar.EujáconfigureiDuclawparaouvirRDPnaporta1337emvezde3389.Seiqueissonãoéamaneiramaisfácildefazerisso.

Euprecisoqueaconexãodaáreadetrabalhoremotaseja"exibida" como se fosse proveniente de devilsmilk . Mas quero que duclaw envie a resposta diretamente de volta para kgraves-pc sem passar por devilsmilk . Então para kgraves-pc a RDP session está sendo enviada para o localhost que é então encaminhado via ssh tunnel através de devilsmilk to duclaw , mas os pacotes RDP que estão sendo recebidos em resposta a isso conexão são recebidas diretamente de Duclaw .

Meus comandos são os seguintes e todos eles são executados no mesmo console CYGWIN ssh em kgraves-pc , exceto pela conexão mstsc que fiz de outro terminal CYGWIN em 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 [email protected]
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 [email protected]
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 [email protected]
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
$

Conexão de área de trabalho remota estabelecida. E, como você pode ver, parece que está vindo de devilsmilk on duclaw . Mas de acordo com kgraves-PC está voltando de Devilsmilk . Então, o que eu pensava que estava acontecendo na verdade não era. Eu pensei que Duclaw estava enviando a sessão RDP de volta para kgraves através de um caminho separado, mas acontece que não foi. Eu não tenho certeza se estava funcionando da última vez e eu tinha uma configuração diferente ou se eu estava imaginando coisas. Mas agora que eu consegui tudo reconfigurado e voltando e rodando depois do meu problema com meus servidores ssh, ele definitivamente não está mais fazendo isso.

Issoéwiresharkemexecuçãoemkgraves-pcduranteasessãoRDP:

Portanto, meu problema ainda é que eu quero que Duclaw envie a sessão RDP de volta para o Kgraves-pc através de um túnel reverso totalmente separado. Isso é o que preciso acontecer e não consigo descobrir como fazer.

Não só preciso de duclaw para enviá-lo de volta em um túnel separado diretamente para kgraves-pc sem passar por devilsmilk , mas também preciso controlar para qual porta efêmera ele será enviado. Eu quero enviá-lo para a porta :44444 em vez de uma porta efêmera aleatória. Ele está usando :48809 aleatoriamente na depuração detalhada ssh impressa acima.

Espero que isso ajude, se não ... desculpe por confundi-lo ainda mais.

    
por Kentgrav 29.01.2013 / 17:30

1 resposta

3

Solicitar

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.

Resposta - Não é possível devido à natureza da comunicação TCP

Eu não acho que isso seja possível, pelo menos não apenas com o túnel ssh.

Vamos ver o fluxo de pacotes desejado / solicitado:

  1. kgraves-pc inicia o pedido de RDP para localhost: 3333, que é um túnel para devilsmilk: 6666
  2. devilsmilk: 6666 por sua vez túnel para duclaw: 1337
  3. duclaw: 1337 pacote de resposta RDP enviar para kgraves-pc

O fluxo de pacotes acima não acontecerá, pelo menos não em circunstâncias normais. Vamos dar um pouco mais de detalhes ao fluxo acima:

  1. kgraves-pc inicia a solicitação RDP para localhost: 3333, que é um túnel para devilsmilk: 6666

    Neste ponto, o cliente RDP do kgraves-pc espera que o pacote de retorno seja proveniente do host local: 3333, nada mais.

  2. devilsmilk: 6666 por sua vez túnel para duclaw: 1337

    Neste ponto, para duclaw servidor RDP, o pedido é de localhost (duclaw ifself), e ele irá responder diretamente a ele.

  3. duclaw: 1337 pacote de resposta RDP enviar para kgraves-pc

    Base em (2) acima, esse caminho não está acontecendo.

Resposta original (não o que OP deseja)

Em kgraves-pc , comando SSH com tunelamento para atingir o requisito OP.

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

-L 3333:localhost:3389 habilita o RPM do kgraves-pc para devilsmilk com localhost:3333

-L 6666:10.0.10.130:3389 habilita o RPM do kgraves-pc para fazer o duclaw com localhost:6666

-R 23389:localhost:3389 habilitar o duclaw RDP para kgraves-pc com devilsmilk:23389

    
por 29.01.2013 / 17:56