Question Besoin de trouver un moyen pour RDP de rappeler à un écouteur local sur un port Ephemeral spécifié via un tunnel SSH inversé


Cela se rapporte à une question précédente qui devenait complètement trop longue et confuse en raison de mes mises à jour et modifications constantes et on m'a demandé de le demander. Donc, je le nettoie et pose une question plus directe.

Tout d’abord, c’est une expérimentation théorique que je dois faire pour apprendre comment fonctionnent les tunnels ssh et inversement, en particulier pour pouvoir contrôler à tout moment où je suis sur le réseau et cacher mes pas tout au long du processus. Mon entraîneur m'a donné cette tâche, mais il espère que je le découvrirai sans aide de sa part.

Je dois trouver un moyen de forcer RDP(Remote Desktop) pour répondre à un port spécifique au lieu d'un RHP (Random High Port). Je ne demande pas comment changer ce port RDP "Écoute", mais plutôt le contraire.

Je tente de mettre en place un avant / arrière expérimental SSH Tunnel entre deux systèmes. J'utilise un troisième système comme point pivot pour masquer mon adresse IP sur le tunnel avant. Mais je veux que le système dans lequel je passe à travers le tunnel SSH Forward envoie la réponse via un retour séparé SSH tunnel vers un port "spécifié" au lieu d'un RHP. L'idée de base est que je veux pouvoir contrôler quels ports je veux écouter et / ou recevoir, et je ne veux pas que quelque chose soit aléatoire.

Ce sont mes trois machines. Devilsmilk est le point pivot, le client est sur kgraves et je remote dans duclaw.

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

Donc, je veux avoir deux tuyaux pour mon RDP session. Un pour l'avant et l'autre pour l'inverse. Mais je ne veux pas le renvoyer sur un RHP. Je ne sais pas comment lui dire de l'envoyer à un port spécifique, par exemple :44444 par exemple.

Est-ce que quelqu'un sait comment faire ça?

J'ai besoin de cela d'une manière spécifique. Ce sont les ports I Avoir utiliser. J'ai déjà mis en place Duclaw à écouter RDP sur le port 1337 au lieu de 3389. Je sais que ce n’est en aucun cas la façon la plus simple de faire cela.

J'ai besoin que la connexion du bureau à distance apparaisse comme si elle venait de devilsmilk ce qui se passe déjà selon wireshark. Mais je veux duclaw envoyer la réponse directement à kgraves sans passer par devilsmilk. De manière à kgraves la RDP la session est envoyée au localhost qui est ensuite transmis via ssh tunnel à travers devilsmilk à duclaw, mais le RDP les paquets reçus en réponse à cette connexion sont reçus directement de Duclaw. Actuellement, la réponse revient sur un RHP via devilsmilk

Mes commandes sont les suivantes et toutes sont effectuées à partir du même CYGWIN  ssh console sur kgraves sauf pour le mstsc connexion que j'ai faite d'un autre CYGWIN terminal sur kgravesJ'ai ajouté un saut de ligne pour le commutateur:

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
$

Connexion Bureau à distance à localhost: 3333 a été établie avec succès. Et comme vous pouvez le voir, il semble provenir de devilsmilk sur duclaw. Mais selon kgraves il revient de Devilsmilk.

Ceci est un instantané de wireshark courir sur le duclaw pendant la RDP session:

enter image description here

Ceci est un instantané de wireshark courir sur kgraves pendant le RDP session:

enter image description here

Mon problème reste donc que je veux que Duclaw renvoie la session RDP à Kgraves-pc via un tunnel inversé entièrement séparé. C'est ce que je dois faire et je ne peux pas comprendre comment faire.

Non seulement j'ai besoin duclaw pour le renvoyer dans un tunnel séparé directement à kgraves sans passer par devilsmilk, mais j'ai aussi besoin de contrôler à quel port éphémère il l'envoie. Je veux qu'il l'envoie au port :44444 au lieu d'un port éphémère aléatoire. Il utilise :48809 au hasard dans le débogage verbeux ssh imprimer ci-dessus.

Au début, il m'a été expliqué par l'utilisateur John Siu, en raison de la nature de la communication TCP, ce n'est pas possible. Car kgraves attend une connexion à partir de localhost depuis sa création avec localhost. Il doit donc y avoir un moyen de duclaw envoyer la session à kgraves mais l'avoir transmis comme s'il venait de localhost peut être?

Mais mon entraîneur m'a dit que, parce que la nature de la RFC pour 127.0.0.1 (Localhost), la poignée de main à trois voies de TCP ne laissait jamais la couche 4 du modèle OSI et qu’elle comportait des «fonctionnalités» syn, syn-ack, condition requise pour la connexion à 127.0.0.1. Par conséquent, TCP ne suit pas exactement les mêmes règles lorsqu'il est connecté à localhost. Il a dit que si vous pouviez écrire un programme de type "wireshark" pour détecter la couche 4 et observer la connexion, vous verriez de quoi il parle.

On m'a donné les réponses possibles suivantes, jusqu'à présent, à l'utilisateur John Siu.

1.) Pour faire ce que vous demandez, la seule méthode à laquelle je puisse penser est d’écrire un proxy rdp personnalisé et de l’exécuter à la fois sur kgraves-pc et sur duclaw.

2.) On m'a également dit que je pouvais utiliser une sorte de virus qui se moque du proxy rdp dont parlait John Siu. Dans mon laboratoire virtuel, je peux utiliser les logiciels malveillants / virus que je souhaite utiliser pour exploiter ces systèmes. Donc, tout est possible.

Toute aide supplémentaire serait très appréciée! Merci à tous pour vos contributions!

J'espère que cela a du sens, sinon ... désolé de vous avoir confondu!

EDIT # 1: J'ai été capable de recréer ce que je voyais au départ qui me faisait croire que ce tunnel était en train de se passer au départ. Vous pouvez voir de la wireshark trafic (le trafic sur le dessus est de Duclaw et le trafic sur le bas est de kgraves) que ce que John a expliqué ci-dessous est exactement ce qui se passe. Maintenant que ce mystère est résolu, je dois encore trouver comment faire en sorte que RDP rappelle un port spécifique au lieu d'un port aléatoire.

enter image description here


2
2018-01-31 13:42


origine


J'ai l'intention de résoudre le mystère suivant: ... 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? ... Mais il ne s'affiche pas dans votre restreinte, est-ce que vous voyez toujours cela ou l’IP a changé? - John Siu
Je ne le vois plus. Sur kgraves Je vois du trafic SSH venant de devilsmilk. J'aurais pu jurer quand je l'ai initialement installé que je le voyais venir de duclaw mais je ne le vois plus maintenant. Pas sûr de ce que j'ai fait différemment. Ou peut-être que j'imaginais des choses. - Kentgrav
En fait, il y avait une chance, peut-être à cause de la commande de votre ssh. Mais tout se passe toujours dans le tunnel ssh. Je vais poster une réponse à cela. Je dois le mettre en dessin, donc peut-être 30min. - John Siu
Ce que vous voulez faire ne pourra pas être fait sans un logiciel personnalisé pour répondre à vos besoins spécifiques. Et ce que votre formateur vous a dit à propos de TCP sur localhost est WRONG. Pensez-y: TCP n'a aucune connaissance des adresses IP, ce qui se passe à la couche 3, alors comment pourrait-il faire quelque chose de spécial basé sur une adresse IP? Oh, et wireshark fait exactement ce que vous mentionnez dans la description d'un programme de type "wireshark" pour détecter la couche 4. - heavyd
Génial, je vais regarder dans le ciel. Je vais aussi regarder l'ensemble du TCP sur l'incompréhension de localhost. Je vous assure que ce gars sait de quoi il parle. Donc, ce qui est probablement arrivé, c'est que j'ai mal compris ce qu'il essayait de me dire et que ça me manquait. Je vais avoir des éclaircissements. Merci pour votre contribution. - Kentgrav


Réponses:


Pour faire ce que vous demandez, je ne peux que penser à la manière suivante

enter image description here

  • C = Client (logiciel client de rdp, telnet, etc.)
  • S = Serveur (logiciel serveur de rdp, telnet, etc.)
  • Le rouge et le vert sont des connexions TCP / IP distinctes.

Custome 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)

Custome 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: Focus sur Telnet, RDP, qui utilise uniquement une connexion TCP. FTP est beaucoup plus difficile car il utilise une connexion TCP supplémentaire avec un port aléatoire pour le transfert de données (fichiers).


1
2018-02-01 20:01



Merci beaucoup homme! Je vais tester cela la semaine prochaine. Appréciez toute votre aide. - Kentgrav
FTP .. votre entraîneur aime vraiment les trous de lapin ... - John Siu


C'est pour répondre à un "mystère" d'un commentaire précédent

... MAIS Sur Kgraves-PC, le trafic SSH venait directement de Duclaw au 10.0.10.120. Comment verrais-je le trafic de Duclaw sur Kgraves-PC alors? ...

Contes de trois tunnels

  1. rouge kgraves-pc: 3333 à devilsmilk: 6666

    kgraves-pc $ ssh -vg -L 3333:localhost:6666 misfitred@devilsmilk(10.0.10.121)
    
  2. vert le démon: 6666 au dupaw: 1337

    devilsmilk $ ssh -vg -L 6666:localhost:1337 kgraves@duclaw(10.0.10.120)
    
  3. Bleu kgraves-pc: 3333 à (duclaw) à 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

Ligne d'histoire rouge

Si tunnel rouge est utilisé, le paquet SSH (RDP) suivra de la manière suivante

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

C'est ce qui est montré dans la capture d'écran OP wireshark.

Blue Story Line

Si le tunnel bleu est utilisé, le paquet SSH (RDP) suivra de la manière suivante

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

Dans ce cas, il ressembler kgraves-pc et duclaw ont une connexion directe SSH-RDP dans wireshark, mais pas.


1
2018-01-31 16:54



Au fait merci pour cette réponse, je vérifie quelques choses avec elle maintenant. Je suis occupé toute la journée. - Kentgrav
Cela fait beaucoup de sens et j'ai pu le recréer! Merci d'avoir résolu ce mystère! Donc, à ce stade, je suis de retour où j'ai commencé lundi, mais j'ai beaucoup appris en cours de route lol. Maintenant, je dois encore trouver comment récupérer RDP sur un port spécifié. - Kentgrav
Je ne suis pas sûr que ssh tunnel soit une approche correcte pour vos besoins réels. La fonction de tunnel ssh fonctionne comme TCP / IP normal. Je lancerai une réponse supplémentaire plus tard (quelques heures) ce soir avec un dessin conceptuel de ce que vous cherchez correctement. Mais vous devrez trouver le "programme" actuel capable de le faire. - John Siu
Mon entraîneur m'a dit essentiellement qu'il me conduisait dans un trou de lapin et que ce que j'essayais d'accomplir ici était possible. Il est hors de portée de ce qu'il essaie de m'apprendre pour le moment, c'est-à-dire envoyer des données par un tunnel, mais les recevoir par un autre tunnel ou faire en sorte que le destinataire soit un autre hôte. Donc, il m'a dit de faire la même chose en utilisant FTP ou Telnet au lieu de RDP, donc je vais lui donner une chance et marquer votre réponse comme étant la bonne réponse pour le moment car vous avez aidé à clarifier beaucoup de questions concernant ce processus entier. Je vous en suis reconnaissant. - Kentgrav
Comme promis, une réponse supplémentaire avec un dessin conceptuel: D - John Siu