Musisz znaleźć sposób, aby RDP mógł oddzwonić do lokalnego słuchacza na określonym porcie efemerycznym za pomocą tunelu Reverse SSH

2

Odnosi się to do poprzedniego pytania, które było całkowicie za długie i mylące ze względu na moje ciągłe aktualizacje i zmiany, i powiedziano mi, żeby go o to poprosić. Więc sprzątam to i zadaję bardziej bezpośrednie pytanie.

Po pierwsze, jest to teoretyczne eksperymentowanie, które muszę wykonać, aby dowiedzieć się, jak działają tunele ssh do przodu i do tyłu, a szczególnie, aby móc przez cały czas utrzymywać pełną kontrolę nad tym, gdzie jestem w sieci i ukrywać kroki. Mój trener dał mi to zadanie, ale on wierzy, że sam to wymyślę bez żadnej pomocy.

Muszę wymyślić sposób na wymuszenie RDP (Remote Desktop), aby odpowiedzieć na określony port Zamiast RHP (Random High Port). Nie pytam, jak zmienić port RDP „Słucha”, ale raczej odwrotnie.

Próbuję skonfigurować eksperymentalny Forward / Reverse SSH Tunel między dwoma systemami. Używam trzeciego systemu jako punktu przestawnego, aby ukryć moje IP w tunelu do przodu. Ale chcę, aby system, do którego wracam, przeszedł przez Forward SSH Tunnel, aby wysłać odpowiedź przez oddzielny bieg wsteczny SSH tunelować do portu „Specified” zamiast RHP. Podstawową ideą jest to, że chcę mieć możliwość kontrolowania, które porty chcę słuchać i odbierać, i nie chcę, aby cokolwiek było losowe.

To są moje trzy maszyny. Devilsmilk jest punktem zwrotnym, na którym znajduje się klient kgraves i wracam do pracy duclaw.

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

Więc chcę mieć dwie fajki dla mojej RDP sesja. Jeden na przód, a drugi na odwrót. Ale nie chcę go odsyłać na RHP. Nie wiem, jak powiedzieć mu, żeby wysłał go do określonego portu, powiedzmy :44444 na przykład.

Czy ktoś wie jak to zrobić?

Potrzebuję tego w określony sposób. To są porty I Mieć używać. Już skonfigurowałem Duclaw słuchać RDP na porcie 1337 zamiast 3389. Wiem, że w żaden sposób nie jest to najłatwiejszy sposób.

Potrzebuję połączenia pulpitu zdalnego, aby „pojawiło się” tak, jakby pochodziło z devilsmilk co już się dzieje zgodnie z wireshark. Ale ja chcę duclaw aby wysłać odpowiedź bezpośrednio do kgraves bez przechodzenia devilsmilk. Tak kgraves RDP sesja jest wysyłana do localhost który jest następnie przesyłany przez ssh tunel przez devilsmilk do duclaw, ale RDP pakiety odbierane w odpowiedzi na to połączenie są odbierane bezpośrednio z Duclaw. Obecnie odpowiedź wraca na RHP devilsmilk

Moje polecenia są następujące i wszystkie są wykonywane dokładnie od tego samego CYGWIN ssh konsola włączona kgraves Z wyjątkiem mstsc połączenie, które zrobiłem z innym CYGWIN terminal włączony kgraves Dodałem podział linii dla przełącznika: 

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
$

Połączenie pulpitu zdalnego z localhost: 3333 zostało pomyślnie ustanowione. Jak widać, wygląda to tak, jakby pochodziło z devilsmilk na duclaw. Ale według kgraves wraca z Devilsmilk.

To jest migawka wireshark działający na księcia podczas RDP sesja:

enter image description here

To jest migawka wireshark kontynuować kgraves podczas RDP sesja:

enter image description here

Pozostaje więc mój problem, że chcę, aby Duclaw wysłał sesję RDP z powrotem do Kgraves-pc przez całkowicie oddzielny tunel odwrotny. Właśnie to muszę się wydarzyć i nie mogę się dowiedzieć, jak to zrobić.

Nie tylko potrzebuję duclaw aby wysłać go z powrotem w oddzielnym tunelu prosto do kgraves bez przechodzenia devilsmilk, ale muszę też kontrolować, do którego portu efemerycznego wysyła. Chcę go wysłać do portu :44444 zamiast losowego portu efemerycznego. Używa :48809 losowo w szczegółowym debugowaniu ssh wydrukować powyżej.

We wczesnych etapach użytkownik John Siu poinformował mnie, że ze względu na charakter komunikacji TCP nie jest to możliwe. Bo kgraves oczekuje połączenia z localhost, ponieważ zostało ustanowione za pomocą localhost. Więc musi być sposób na duclaw wysłać sesję do kgraves ale przekazać, aby wyglądało, jakby pochodziło z localhost może?

Ale mój trener powiedział mi, że ze względu na naturę RFC dla 127.0.0.1 (Localhost) trójdrożny uścisk dłoni TCP nigdy nie opuszcza warstwy 4 modelu OSI i ma wbudowane pewne „funkcje”, które wykluczają wymóg synchronizacji, synchronizacji i potwierdzenia przy podłączaniu do 127.0.0.1. Dlatego TCP nie jest zgodny z tymi samymi regułami po podłączeniu do localhost. Powiedział, że gdybyś mógł napisać program typu „wireshark”, żeby powąchać w warstwie 4 i obserwować połączenie, zobaczyłbyś, o czym mówi.

Do tej pory otrzymałem następujące możliwe odpowiedzi dla użytkownika Johna Siu.

1.) Aby zrobić to, o co pytasz, jedyną metodą, jaką mogę sobie wyobrazić, jest napisanie niestandardowego proxy rdp i uruchomienie go zarówno na kgraves-pc, jak i duclaw.

2.) Powiedziano mi również, że może istnieć jakiś wirus, którego mogę użyć, który w zasadzie drwi z proxy rdp, o którym mówił John Siu. W moim wirtualnym laboratorium mogę używać złośliwego oprogramowania / wirusa, którego chcę użyć do wykorzystania tych systemów. Więc wszystko jest możliwe.

Jakakolwiek dalsza pomoc byłaby najbardziej ceniona! Dziękuję wszystkim za Twój wkład!

Mam nadzieję, że to ma sens, jeśli nie ... przepraszam, że cię pomieszałem!

EDYCJA 1: Udało mi się odtworzyć to, co początkowo widziałem, co sprawiło, że uwierzyłem, że ten tunel odwrotny miał początkowo miejsce. Możesz zobaczyć z wireshark ruch (ruch na górze jest z Duclaw a ruch na dnie jest z kgraves ) to, co John wyjaśnił poniżej, jest dokładnie tym, co się dzieje. Teraz, gdy ta tajemnica została rozwiązana, wciąż muszę dowiedzieć się, jak uzyskać wywołanie RDP do określonego portu zamiast portu losowego.

enter image description here

remote-desktop  port  ssh-tunnel  exploit  reverse-tunnel 
— Kentgrav
źródło
Zamierzam rozwiązać następującą tajemnicę: ... BUT On Kgraves-PC I had SSH traffic coming straight from Duclaw at 10.0.10.130. How would I be seeing traffic from Duclaw on Kgraves-PC then? ... Ale nie widać tego w twoim wireshark, czy nadal widzisz to lub zmienił się adres IP?
— John Siu
Już tego nie widzę. Na kgraves Widzę ruch SSH pochodzący z devilsmilk. Mógłbym przysiąc, że początkowo ustawiłem to tak, że widzę, że to pochodzi duclaw ale już tego nie widzę. Nie wiem, co zrobiłem inaczej. A może wyobrażałem sobie rzeczy.
— Kentgrav
1
Właściwie była szansa, może ze względu na kolejność wydawania ssh. Ale nadal jest w tunelu ssh. Odpowiem na to. Musisz umieścić to na rysunku, więc może 30 minut.
— John Siu
1
To, co chcesz zrobić, nie będzie możliwe bez specjalnego oprogramowania dostosowanego do Twoich potrzeb. A co twój trener powiedział ci o TCP na localhost jest NIEPRAWIDŁOWY. Pomyśl o tym: TCP nie ma żadnej wiedzy na temat adresów IP, co dzieje się w warstwie 3, więc jak może zrobić coś specjalnego na podstawie adresu IP? Och, a wireshark robi dokładnie to, o czym wspominasz w opisie programu typu „wireshark”, aby sniffować warstwę 4.
— heavyd
Wspaniale, zajrzę do tego ciężkiego. Zajmę się także całym TCP na nieporozumieniu localhost. Zapewniam cię, że ten facet wie o czym mówi. Więc to, co prawdopodobnie się wydarzyło, to niezrozumienie tego, co próbował mi powiedzieć, a miss przekazał to. Otrzymam wyjaśnienie. Dzięki za wkład.
— Kentgrav

Odpowiedzi:

1

Aby zrobić to, o co prosisz, mogę myśleć tylko o następującej drodze

enter image description here

  • C = Klient (oprogramowanie klienckie rdp, telnet itp.)
  • S = serwer (oprogramowanie serwera rdp, telnet itp.)
  • Czerwone i zielone są oddzielnym połączeniem TCP / IP.

Custom Proxy 1 

(Blue)  Listen to a local port to wait for client software connection
(Red)   Forward incoming packet from C to Custom Proxy 2 public port
(Green) Listen to a public port, forward incoming packet from Custom Proxy 2 to C (via Blue)

Custom Proxy 2 

(Red)   Listen to public port for incoming packet from Custom Proxy 1
(Blue)  Establish connection with S, forward incoming packet from Custom Proxy 1 to S
(Green) Forward incoming packet from S to Custom Proxy 1 public port

PS: Skup się na Telnet, RDP, który używa tylko jednego połączenia tcp. FTP jest znacznie trudniejszy, ponieważ używa dodatkowego połączenia tcp z losowym portem do przesyłania danych (plików).

— John Siu
źródło
Dzięki wielkie! Sprawdzę to w przyszłym tygodniu. Doceń całą swoją pomoc.
— Kentgrav
FTP ... Twój trener naprawdę lubi króliki ...
— John Siu
1

To jest odpowiedź na „tajemnicę” z poprzedniego komentarza

... ALE Na Kgraves-PC miałem ruch SSH prosto z Duclaw o 10.0.10.120. Jak wtedy widziałbym ruch z Duclaw na Kgraves-PC? ...

Opowieści o trzech tunelach

  1. Czerwony kgraves-pc: 3333 do devilsmilk: 6666 

    kgraves-pc $ ssh -vg -L 3333:localhost:6666 misfitred@devilsmilk(10.0.10.121)

  2. Zielony devilsmilk: 6666 do duclaw: 1337 

    devilsmilk $ ssh -vg -L 6666:localhost:1337 kgraves@duclaw(10.0.10.120)

  3. niebieski kgraves-pc: 3333 do (duclaw) do devilsmilk: 6666 

    duclaw     $ ssh -vg -R 3333:devilsmilk:6666 kgraves@kgraves(10.0.10.113)

Map Of 3 Tunnels

kgraves-pc$ $ mstsc /v:localhost:3333 /f

Red Story Line

Jeśli używany jest czerwony tunel, pakiet SSH (RDP) będzie podążał w tę iz powrotem w następujący sposób 

kgraves-pc <--(Red)--> devilsmilk <--(Green)--> duclaw(RDP server end point)

To jest to, co zostało pokazane w zrzucie ekranu OP wireshark.

Blue Story Line

Jeśli używany jest niebieski tunel, pakiet SSH (RDP) będzie podążał w tę iz powrotem w następujący sposób 

kgraves-pc <--(Blue-ssh)--> duclaw(en-route) <--(Blue-non-ssh)--> devilsmilk <--(Green)--> duclaw(RDP server end point)

W tym przypadku to wygląda jak kgraves-pc i duclaw mają bezpośrednie połączenie SSH-RDP w wireshark, ale nie.

— John Siu
źródło
Przy okazji dzięki za tę odpowiedź, teraz sprawdzam kilka rzeczy. Cały dzień jestem zajęty.
— Kentgrav
To ma sens i mogłem go odtworzyć! Dziękujemy za rozwiązanie tej tajemnicy! W tym momencie wracam tam, gdzie zacząłem w poniedziałek, ale wiele się nauczyłem po drodze. Teraz wciąż muszę dowiedzieć się, jak uzyskać wywołanie RDP do określonego portu.
— Kentgrav
1
Nie jestem pewien, czy tunel ssh jest właściwym podejściem do twoich prawdziwych potrzeb. Funkcja tunelu ssh działa jak normalny tcp / ip. Wrzucę dziś dodatkową odpowiedź (kilka godzin) z rysunkiem koncepcyjnym tego, czego właściwie szukasz. Ale musisz znaleźć rzeczywisty „program”, który to potrafi.
— John Siu
Mój trener powiedział mi, że prowadzi mnie przez króliczą dziurę i chociaż to, co próbuję osiągnąć, jest możliwe. Jest poza zakresem tego, czego próbuje mnie nauczyć w chwili, gdy wysyła dane przez jeden tunel, ale odbiera go przez inny tunel lub gdy odbiorca jest całkowicie innym hostem. Powiedział mi więc, że zrobię to samo za pomocą FTP lub Telnet zamiast RDP, więc zrobię to i oznaczę twoją odpowiedź jako poprawną na razie, ponieważ pomógłeś wyjaśnić wiele pytań dotyczących całego procesu. Doceniam to.
— Kentgrav
Jak obiecałem, dodatkowa odpowiedź z rysunkiem koncepcyjnym: D
— John Siu
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.