Come specificare a quale porta risponde RDP?


5

Devo trovare un modo per forzare RDP(Desktop remoto) a rispondere a una porta specifica anziché a un RHP (Random High Port). Non sto chiedendo come cambiare su quale porta RDP"Ascolta", ma piuttosto il contrario.

Sto tentando di impostare un SSHtunnel sperimentale avanti / indietro tra due sistemi. Sto usando un terzo sistema come punto Pivot per nascondere il mio IP sul tunnel forward. Ma voglio che il sistema in cui sto effettuando il Remoting attraverso il tunnel SSH Forward invii la risposta attraverso un SSHtunnel inverso separato a una porta "Specificata" anziché a un RHP. L'idea di base è che voglio essere in grado di controllare quali porte voglio ascoltare e / o ricevere e non voglio che nulla sia casuale. Detto questo, ecco un'istantanea della mia installazione.

Modifica: tutti gli indirizzi IP nell'immagine sono cambiati, il che lo confonderà in seguito quando leggerai i log che ho modificato nella domanda. I nuovi indirizzi IP sono:

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

inserisci qui la descrizione dell'immagine

Come puoi vedere nell'ultimo passaggio, la mia RDPsessione viene rinviata attraverso il SSHtunnel inverso come lo voglio. Quindi ho due pipe per la mia RDPsessione. Ma lo sta rimandando su un RHP e non riesco a capire come dirlo per inviarlo a una porta specifica, :44444per esempio.

Qualcuno sa come fare questo?

Ho bisogno che questo sia fatto in un modo specifico. Queste sono le porte che devo usare. Ho già impostato Duclawper l'ascolto RDPsu porta 1337anziché 3389. So che questo non è affatto il modo più semplice per farlo.

Ho bisogno della connessione desktop remoto per "apparire" come se provenisse da devilsmilk. Ma voglio duclawinviare la risposta direttamente a kgraves-pcsenza passare devilsmilk. Quindi, per kgraves-pcla RDPsessione viene inviato al localhostquale viene poi trasmesso attraverso sshtunnel attraverso devilsmilkdi duclaw, ma i RDPpacchetti che vengono ricevuti in risposta a questo proposito sono ricevuti direttamente da Duclaw.

I miei comandi sono i seguenti e tutti vengono eseguiti dalla stessa identica CYGWIN sshconsole su kgraves-pctranne la mstscconnessione che ho fatto da un altro CYGWINterminale su 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
$

Connessione desktop remoto stabilita. E come puoi vedere sembra provenire da devilsmilksopra duclaw. Ma secondo kgraves-PCesso sta tornando da Devilsmilk. Quindi quello che in precedenza pensavo stesse accadendo non lo era. Pensavo Duclawstesse rimandando la RDPsessione kgravesattraverso un percorso separato, ma si scopre che non lo era. Non sono sicuro che funzionasse l'ultima volta e che avessi una configurazione diversa o se stavo immaginando cose. Ma ora che ho ottenuto tutto riconfigurato ed eseguito il backup dopo l'esecuzione del mio problema con i miei server SSH, sicuramente non lo fa più.

inserisci qui la descrizione dell'immagine

Questo è in wiresharkcorso kgraves-pcdurante la RDPsessione:

inserisci qui la descrizione dell'immagine

Quindi il mio problema rimane che voglio che Duclaw rispedisca la sessione RDP a Kgraves-pc attraverso un tunnel inverso completamente separato. Questo è ciò di cui ho bisogno per accadere e non riesco a capire come fare.

Non solo ho bisogno duclawdi rispedirlo in un tunnel separato direttamente kgraves-pcsenza passare, devilsmilkma ho anche bisogno di controllare a quale porta effimera a cui lo invia. Voglio che lo invii alla porta :44444anziché a una porta effimera casuale. Si sta usando in :48809modo casuale nella sshstampa dettagliata del debug sopra.

Spero che questo chiarisca, se non ... scusa per averti confuso ancora di più.

Risposte:


3

Richiesta

Ho bisogno della connessione desktop remoto per "apparire" come se provenisse da Devilsmilk. Ma voglio che duclaw rispedisca la risposta direttamente a kgraves-pc senza passare attraverso il diavolo. Quindi a kgraves-pc la sessione RDP viene inviata al localhost che viene quindi inoltrato tramite tunnel ssh attraverso devilsmilk a duclaw, ma i pacchetti RDP che vengono ricevuti in risposta a quella connessione vengono ricevuti direttamente da Duclaw.

Risposta: impossibile per la natura della comunicazione TCP

Non credo sia fattibile, almeno non solo con il tunnel SSH.

Vediamo il flusso di pacchetti desiderato / richiesto:

  1. kgraves-pc avvia la richiesta RDP su localhost: 3333, che è un tunnel per devilsmilk: 6666
  2. devilsmilk: 6666 a sua volta tunnel per duclaw: 1337
  3. duclaw: 1337 pacchetto di risposta RDP inviato a kgraves-pc

Il flusso di pacchetti sopra riportato non avverrà, almeno non in circostanze normali. Diamo al flusso sopra un po 'più di dettagli:

  1. kgraves-pc avvia la richiesta RDP su localhost: 3333, che è un tunnel per devilsmilk: 6666

    A questo punto, il client RDP di kgraves-pc prevede un pacchetto di ritorno proveniente da localhost: 3333, nient'altro.

  2. devilsmilk: 6666 a sua volta tunnel per duclaw: 1337

    A questo punto, per duclaw server RDP, la richiesta proviene da localhost (duclaw se stesso) e risponderà direttamente ad esso.

  3. duclaw: 1337 pacchetto di risposta RDP inviato a kgraves-pc

    Basati su (2) sopra, questo percorso non sta affatto accadendo.

Risposta originale (Non quello che OP desidera)

On kgraves-pc, comando SSH con tunneling per raggiungere il requisito OP.

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

-L 3333:localhost:3389 abilitare RDP di kgraves-pc con devilsmilk con localhost:3333

-L 6666:10.0.10.130:3389 abilitare RDP di kgraves-pc con duclaw localhost:6666

-R 23389:localhost:3389 abilita duclaw RDP su kgraves-pc con devilsmilk:23389


1
OK, aggiungerò le regole `-R per abilitarlo.
John Siu,

1
-Raggiunto e modificato anche il formato di risposta per una lettura più semplice.
John Siu,

1
Penso di ottenerlo dopo aver letto le informazioni aggiornate. Serve un po 'più di tempo per mettere insieme tutto il tunnel.
John Siu,

2
Ho aggiornato la mia risposta. In ripresa, non credo sia fattibile con il tunnel SSH.
John Siu,

1
Il traffico Ducgra <--> Kgraves-PC è intenso o leggero? Se è leggero, può essere trasmesso casualmente o ssh keep-alive o qualcosa del genere.
John Siu,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.