On 06-08-2008, Thomas wrote:
> malheureusement, il manque peu de choses Ã*** ultravnc pour permettre au
> client de lancer une connexion vnc inversée très très facilement, mais
> ça manque ...
>

Y a "simple clic" avec ultravnc qui est quand même pas mal.

J'ai fait un petit test qui s'annonce pas mal, où j'arrive Ã*** lancer
ultravnc Ã*** distance sans intervention de l'utilisateur. Pour ça il faut
au préalable lancer un prog résidant sur la machine de l'utilisateur qui
va communiquer avec un serveur. Un cheval de Troie en fait.
Si ça t'intéresse on pourra bosser ensemble la dessus un de ces 4. (ça
sera libre bien entendu, en python).

--
William Dodé - http://flibuste.net
Informaticien Indépendant

In article <g7ca54$30p0$3***biggoron.nerim.net>,
William Dode <wilk***flibuste.net> wrote:

> On 06-08-2008, Thomas wrote:
> > malheureusement, il manque peu de choses Ã*** ultravnc pour permettre au
> > client de lancer une connexion vnc inversée très très facilement, mais
> > ça manque ...
> >
>
> Y a "simple clic" avec ultravnc qui est quand même pas mal.

malheureusement, je n'ai réussi Ã*** le faire marcher ni avec Chicken of
the VNC, ni avec ce que j'ai trouvé sous linux ...

plusieurs personnes ont pourtant demandé il y a qqes années d'avoir une
version d'ultravnc SC plus complète, pour bien respecter le protocole,
quitte Ã*** ce qu'elle soit moins légère ... toujours rien :-(


>
> J'ai fait un petit test qui s'annonce pas mal, où j'arrive Ã*** lancer
> ultravnc Ã*** distance sans intervention de l'utilisateur. Pour ça il faut
> au préalable lancer un prog résidant sur la machine de l'utilisateur qui
> va communiquer avec un serveur. Un cheval de Troie en fait.

je crois que j'ai compris le principe :-)
en fait, tu veux
- ne pas avoir Ã*** t'occuper du routeur coté client
- pouvoir te connecter quand il est pas chez lui
c'est ça ? :-)

fais très gaffe Ã*** la sécurité du serveur alors, parce que si il est
compromis, ton client l'est aussi

t'utilises ssh ou pas ?
si oui, est ce que c'est possible de faire en sorte que l'ordi du client
mette en route un tunnel ssh au démarrage ? (avec putty ?)
(je devine que oui mais je ne sais pas comment, je veux bien un coup de
main pour ça :-) )
si oui, c'est gagné :-)) plus besoin de vnc inversé pour ça :-)
je te donnes les détails si ça t'intéresse :-)


> Si ça t'intéresse on pourra bosser ensemble la dessus un de ces 4. (ça
> sera libre bien entendu, en python).

pour l'instant ça ne m'intéresse pas trop (en principe je dois pouvoir
me débrouiller avec le routeur quand c'est nécessaire),
et puis je ne connais pas le python,
et surtout, pour l'instant j'ai pas encore réussi Ã*** faire fonctionner
vnc dans tous les cas de figure, donc il y a ça qui est largement
prioritaire pour moi pour l'instant :-)

désolé, c'est pas de mauvais coeur :-)


(c'est un peu bizarre Ã*** lire parce que j'ai écrit le 3eme paragraphe
avant le 2eme ;-) )

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/

On 26-08-2008, Thomas wrote:
> In article <g7ca54$30p0$3***biggoron.nerim.net>,
> William Dode <wilk***flibuste.net> wrote:
>
>> On 06-08-2008, Thomas wrote:
>> > malheureusement, il manque peu de choses Ã*** ultravnc pour permettre au
>> > client de lancer une connexion vnc inversée très très facilement, mais
>> > ça manque ...
>> >
>>
>> Y a "simple clic" avec ultravnc qui est quand même pas mal.
>
> malheureusement, je n'ai réussi Ã*** le faire marcher ni avec Chicken of
> the VNC, ni avec ce que j'ai trouvé sous linux ...

généralement quand j'ai besoin d'accéder Ã*** une machine windows j'ai
besoin d'une machine windows de mon côté aussi... Donc j'utilise
virtualbox.

>
> plusieurs personnes ont pourtant demandé il y a qqes années d'avoir une
> version d'ultravnc SC plus complète, pour bien respecter le protocole,
> quitte Ã*** ce qu'elle soit moins légère ... toujours rien :-(
>
>
>>
>> J'ai fait un petit test qui s'annonce pas mal, où j'arrive Ã*** lancer
>> ultravnc Ã*** distance sans intervention de l'utilisateur. Pour ça il faut
>> au préalable lancer un prog résidant sur la machine de l'utilisateur qui
>> va communiquer avec un serveur. Un cheval de Troie en fait.
>
> je crois que j'ai compris le principe :-)
> en fait, tu veux
> - ne pas avoir Ã*** t'occuper du routeur coté client
> - pouvoir te connecter quand il est pas chez lui
> c'est ça ? :-)
>

Exactement

> fais très gaffe Ã*** la sécurité du serveur alors, parce que si il est
> compromis, ton client l'est aussi

C'est pour ça que je veux toucher au moins de chose possible, c'est pas
mon job. Du coup je prévois que le cheval de troie ne puisse faire que
lancer un exécutable donné qui lui va se connecter en reverse chez moi,
ip fixe.

>
> t'utilises ssh ou pas ?
> si oui, est ce que c'est possible de faire en sorte que l'ordi du client
> mette en route un tunnel ssh au démarrage ? (avec putty ?)
> (je devine que oui mais je ne sais pas comment, je veux bien un coup de
> main pour ça :-) )

Oui pourquoi pas puisque le principe est de lancer un exe Ã*** distance.

> si oui, c'est gagné :-)) plus besoin de vnc inversé pour ça :-)
> je te donnes les détails si ça t'intéresse :-)

Tu ne serais pas entrain de réinventer le vpn par hasard ;-) ?

--
William Dodé - http://flibuste.net
Informaticien Indépendant

In article <g90fle$1uon$1***biggoron.nerim.net>,
William Dode <wilk***flibuste.net> wrote:

> On 26-08-2008, Thomas wrote:
> > In article <g7ca54$30p0$3***biggoron.nerim.net>,
> > William Dode <wilk***flibuste.net> wrote:
> >
> >> On 06-08-2008, Thomas wrote:
> >> > malheureusement, il manque peu de choses Ã*** ultravnc pour permettre au
> >> > client de lancer une connexion vnc inversée très très facilement, mais
> >> > ça manque ...
> >> >
> >>
> >> Y a "simple clic" avec ultravnc qui est quand même pas mal.
> >
> > malheureusement, je n'ai réussi Ã*** le faire marcher ni avec Chicken of
> > the VNC, ni avec ce que j'ai trouvé sous linux ...
>
> généralement quand j'ai besoin d'accéder Ã*** une machine windows j'ai
> besoin d'une machine windows de mon côté aussi... Donc j'utilise
> virtualbox.

ah bon
je verrais ça Ã*** l'usage,
en attendant j'essaye de ne pas m'acheter de licence windows tant que
c'est possible

>
> >
> > plusieurs personnes ont pourtant demandé il y a qqes années d'avoir une
> > version d'ultravnc SC plus complète, pour bien respecter le protocole,
> > quitte Ã*** ce qu'elle soit moins légère ... toujours rien :-(
> >
> >
> >>
> >> J'ai fait un petit test qui s'annonce pas mal, où j'arrive Ã*** lancer
> >> ultravnc Ã*** distance sans intervention de l'utilisateur. Pour ça il faut
> >> au préalable lancer un prog résidant sur la machine de l'utilisateur qui
> >> va communiquer avec un serveur. Un cheval de Troie en fait.
> >
> > je crois que j'ai compris le principe :-)
> > en fait, tu veux
> > - ne pas avoir Ã*** t'occuper du routeur coté client
> > - pouvoir te connecter quand il est pas chez lui
> > c'est ça ? :-)
> >
>
> Exactement

ok :-)

>
> > fais très gaffe Ã*** la sécurité du serveur alors, parce que si il est
> > compromis, ton client l'est aussi
>
> C'est pour ça que je veux toucher au moins de chose possible, c'est pas
> mon job. Du coup je prévois que le cheval de troie ne puisse faire que
> lancer un exécutable donné qui lui va se connecter en reverse chez moi,
> ip fixe.

ah oui, si on part du principe qu'un pirate qui contrôle le serveur ne
pourra faire absolument rien d'autre, ta solution est plutôt plus
sécurisée que la mienne

cela dit, il y a un risque lié au fait que c'est un prgm perso qui n'est
donc pas très "éprouvé", par rapport Ã*** ssh

je peux te donner tout ce qu'il faut pour sécuriser (solidement) le
serveur avec ssh, si ça t'intéresse (j'ai pas bien compris si oui ou
non, en fait)
(je te le donne pas d'emblée parce qu'il faut que je le recherche)

il s'agit d'avoir
- vnc chez le client qui écoute
- une connexion ssh en permanence de chez le client sur ton serveur,
avec un tunnel Ã*** l'envers
- quand tu veux te connecter, tu fais une connexion ssh sur ton serveur,
avec un tunnel Ã*** l'endroit
et voilÃ*** :-)

d'ailleurs c'est pas le bon forum, je crois que le bon forum c'est fcs,
donc si tu veux, rdv lÃ*** bas ;-)


>
> >
> > t'utilises ssh ou pas ?
> > si oui, est ce que c'est possible de faire en sorte que l'ordi du client
> > mette en route un tunnel ssh au démarrage ? (avec putty ?)
> > (je devine que oui mais je ne sais pas comment, je veux bien un coup de
> > main pour ça :-) )
>
> Oui pourquoi pas puisque le principe est de lancer un exe Ã*** distance.

lÃ*** il ne faut pas le lancer Ã*** distance mais au démarrage (pour qu'il
soit lÃ*** en permanence)


>
> > si oui, c'est gagné :-)) plus besoin de vnc inversé pour ça :-)
> > je te donnes les détails si ça t'intéresse :-)
>
> Tu ne serais pas entrain de réinventer le vpn par hasard ;-) ?

heu non, c'est juste des tunnels ssh,
tu connais pas ? même pas le principe ?

je te conseille vivement de t'informer :-)
c'est pas tout Ã*** fait aussi souple que le vpn, mais ça permet énormément
de chose comparé au fait que ça ne s'incruste absolument pas dans le
système :-)

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/

On 27-08-2008, Thomas wrote:
>>
>> C'est pour ça que je veux toucher au moins de chose possible, c'est pas
>> mon job. Du coup je prévois que le cheval de troie ne puisse faire que
>> lancer un exécutable donné qui lui va se connecter en reverse chez moi,
>> ip fixe.
>
> ah oui, si on part du principe qu'un pirate qui contrôle le serveur ne
> pourra faire absolument rien d'autre, ta solution est plutôt plus
> sécurisée que la mienne
>
> cela dit, il y a un risque lié au fait que c'est un prgm perso qui n'est
> donc pas très "éprouvé", par rapport Ã*** ssh
>
> je peux te donner tout ce qu'il faut pour sécuriser (solidement) le
> serveur avec ssh, si ça t'intéresse (j'ai pas bien compris si oui ou
> non, en fait)
> (je te le donne pas d'emblée parce qu'il faut que je le recherche)
>
> il s'agit d'avoir
> - vnc chez le client qui écoute
> - une connexion ssh en permanence de chez le client sur ton serveur,
> avec un tunnel Ã*** l'envers
> - quand tu veux te connecter, tu fais une connexion ssh sur ton serveur,
> avec un tunnel Ã*** l'endroit
> et voilÃ*** :-)

Oui pourquoi pas, mais je ne sais pas si c'est beaucoup plus simple ni
plus sécurisé.

>
> d'ailleurs c'est pas le bon forum, je crois que le bon forum c'est fcs,
> donc si tu veux, rdv lÃ*** bas ;-)

Quand je me remettrai concrètement j'irai y faire un tour...


>
>>
>> > si oui, c'est gagné :-)) plus besoin de vnc inversé pour ça :-)
>> > je te donnes les détails si ça t'intéresse :-)
>>
>> Tu ne serais pas entrain de réinventer le vpn par hasard ;-) ?
>
> heu non, c'est juste des tunnels ssh,
> tu connais pas ? même pas le principe ?
>
> je te conseille vivement de t'informer :-)
> c'est pas tout Ã*** fait aussi souple que le vpn

Mais ce que tu décris *est* un vpn !

> , mais ça permet énormément de chose comparé au fait que ça ne
>s'incruste absolument pas dans le système :-)


--
William Dodé - http://flibuste.net
Informaticien Indépendant

In article <g95ms2$30l6$2***biggoron.nerim.net>,
William Dode <wilk***flibuste.net> wrote:

> On 27-08-2008, Thomas wrote:
> >>
> >> C'est pour ça que je veux toucher au moins de chose possible, c'est pas
> >> mon job. Du coup je prévois que le cheval de troie ne puisse faire que
> >> lancer un exécutable donné qui lui va se connecter en reverse chez moi,
> >> ip fixe.
> >
> > ah oui, si on part du principe qu'un pirate qui contrôle le serveur ne
> > pourra faire absolument rien d'autre, ta solution est plutôt plus
> > sécurisée que la mienne
> >
> > cela dit, il y a un risque lié au fait que c'est un prgm perso qui n'est
> > donc pas très "éprouvé", par rapport Ã*** ssh
> >
> > je peux te donner tout ce qu'il faut pour sécuriser (solidement) le
> > serveur avec ssh, si ça t'intéresse (j'ai pas bien compris si oui ou
> > non, en fait)
> > (je te le donne pas d'emblée parce qu'il faut que je le recherche)
> >
> > il s'agit d'avoir
> > - vnc chez le client qui écoute
> > - une connexion ssh en permanence de chez le client sur ton serveur,
> > avec un tunnel Ã*** l'envers
> > - quand tu veux te connecter, tu fais une connexion ssh sur ton serveur,
> > avec un tunnel Ã*** l'endroit
> > et voilÃ*** :-)
>
> Oui pourquoi pas, mais je ne sais pas si c'est beaucoup plus simple ni
> plus sécurisé.

en fait, pour moi c'est beaucoup plus simple parce que je connais bien
ssh (et du coup il n'y a rien Ã*** écrire en plus)

plus sécurisé : je m'étais pas rendu compte au début, mais si tu
maîtrises vraiment très très bien le python et que t'es absolument
certain Ã*** la fois de l'absence de bug dans ton prgm et de l'absence de
faille de sécurité dans le compilateur ou l'interpreteur, y a un point
pour toi, puisque ça ne dépend pas de la sécurité du serveur ... :-)
(le plus de ssh c'est que les tunnels sont très solidement cryptés)

>
> >
> > d'ailleurs c'est pas le bon forum, je crois que le bon forum c'est fcs,
> > donc si tu veux, rdv lÃ*** bas ;-)
>
> Quand je me remettrai concrètement j'irai y faire un tour...

quand tu veux sauf que je regarde pas tout le temps
cela dit en particulier en matière de sécurité c'est très bien d'avoir
des avis différents :-)

>
>
> >
> >>
> >> > si oui, c'est gagné :-)) plus besoin de vnc inversé pour ça :-)
> >> > je te donnes les détails si ça t'intéresse :-)
> >>
> >> Tu ne serais pas entrain de réinventer le vpn par hasard ;-) ?
> >
> > heu non, c'est juste des tunnels ssh,
> > tu connais pas ? même pas le principe ?
> >
> > je te conseille vivement de t'informer :-)

j'ai eu un peu de mal au début, mais maintenant que je connais je ne
m'en passe plus ;-)

> > c'est pas tout Ã*** fait aussi souple que le vpn
>
> Mais ce que tu décris *est* un vpn !

ah ?
pour toi c'est quoi la définition d'un vpn ?

>
> > , mais ça permet énormément de chose comparé au fait que ça ne
> >s'incruste absolument pas dans le système :-)

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/

On 28-08-2008, Thomas wrote:
> In article <g95ms2$30l6$2***biggoron.nerim.net>,
> William Dode <wilk***flibuste.net> wrote:
>
>> On 27-08-2008, Thomas wrote:
>> >>
>> >> C'est pour ça que je veux toucher au moins de chose possible, c'est pas
>> >> mon job. Du coup je prévois que le cheval de troie ne puisse faire que
>> >> lancer un exécutable donné qui lui va se connecter en reverse chez moi,
>> >> ip fixe.
>> >
>> > ah oui, si on part du principe qu'un pirate qui contrôle le serveur ne
>> > pourra faire absolument rien d'autre, ta solution est plutôt plus
>> > sécurisée que la mienne
>> >
>> > cela dit, il y a un risque lié au fait que c'est un prgm perso qui n'est
>> > donc pas très "éprouvé", par rapport Ã*** ssh
>> >
>> > je peux te donner tout ce qu'il faut pour sécuriser (solidement) le
>> > serveur avec ssh, si ça t'intéresse (j'ai pas bien compris si oui ou
>> > non, en fait)
>> > (je te le donne pas d'emblée parce qu'il faut que je le recherche)
>> >
>> > il s'agit d'avoir
>> > - vnc chez le client qui écoute
>> > - une connexion ssh en permanence de chez le client sur ton serveur,
>> > avec un tunnel Ã*** l'envers
>> > - quand tu veux te connecter, tu fais une connexion ssh sur ton serveur,
>> > avec un tunnel Ã*** l'endroit
>> > et voilÃ*** :-)
>>
>> Oui pourquoi pas, mais je ne sais pas si c'est beaucoup plus simple ni
>> plus sécurisé.
>
> en fait, pour moi c'est beaucoup plus simple parce que je connais bien
> ssh (et du coup il n'y a rien Ã*** écrire en plus)
>
> plus sécurisé : je m'étais pas rendu compte au début, mais si tu
> maîtrises vraiment très très bien le python et que t'es absolument
> certain Ã*** la fois de l'absence de bug dans ton prgm et de l'absence de
> faille de sécurité dans le compilateur ou l'interpreteur, y a un point
> pour toi, puisque ça ne dépend pas de la sécurité du serveur ... :-)
> (le plus de ssh c'est que les tunnels sont très solidement cryptés)

Rien n'empêchera mon programme d'être crypté en ssl si besoin ou
d'utiliser un tunnel... C'est surtout le principe qui me semble sûr. De
ne faire qu'une chose, lancer tel exécutable. Par rapport Ã*** un tunnel,
crypté certe, mais qui laisse faire quoi ?
Mais bon, ton idée de tunnel me donne une solution pour résoudre le
problème de celui qui va faire la maintenance et qui n'aurait pas d'ip
publique...

> >
>> >>
>> >> > si oui, c'est gagné :-)) plus besoin de vnc inversé pour ça :-)
>> >> > je te donnes les détails si ça t'intéresse :-)
>> >>
>> >> Tu ne serais pas entrain de réinventer le vpn par hasard ;-) ?
>> >
>> > heu non, c'est juste des tunnels ssh,
>> > tu connais pas ? même pas le principe ?
>> >
>> > je te conseille vivement de t'informer :-)
>
> j'ai eu un peu de mal au début, mais maintenant que je connais je ne
> m'en passe plus ;-)
>
>> > c'est pas tout Ã*** fait aussi souple que le vpn
>>
>> Mais ce que tu décris *est* un vpn !
>
> ah ?
> pour toi c'est quoi la définition d'un vpn ?

Pour tout le monde je crois, c'est un tunnel dans lequel passe tout un
réseau privé.
http://fr.wikipedia.org/wiki/Virtual_Private_Network

--
William Dodé - http://flibuste.net
Informaticien Indépendant

In article <g96n0f$19u$2***biggoron.nerim.net>,
William Dode <wilk***flibuste.net> wrote:

> On 28-08-2008, Thomas wrote:
> > In article <g95ms2$30l6$2***biggoron.nerim.net>,
> > William Dode <wilk***flibuste.net> wrote:
> >
> >> On 27-08-2008, Thomas wrote:
> >> >>
> >> >> C'est pour ça que je veux toucher au moins de chose possible, c'est pas
> >> >> mon job. Du coup je prévois que le cheval de troie ne puisse faire que
> >> >> lancer un exécutable donné qui lui va se connecter en reverse chez moi,
> >> >> ip fixe.
> >> >
> >> > ah oui, si on part du principe qu'un pirate qui contrôle le serveur ne
> >> > pourra faire absolument rien d'autre, ta solution est plutôt plus
> >> > sécurisée que la mienne
> >> >
> >> > cela dit, il y a un risque lié au fait que c'est un prgm perso qui n'est
> >> > donc pas très "éprouvé", par rapport Ã*** ssh
> >> >
> >> > je peux te donner tout ce qu'il faut pour sécuriser (solidement) le
> >> > serveur avec ssh, si ça t'intéresse (j'ai pas bien compris si oui ou
> >> > non, en fait)
> >> > (je te le donne pas d'emblée parce qu'il faut que je le recherche)
> >> >
> >> > il s'agit d'avoir
> >> > - vnc chez le client qui écoute
> >> > - une connexion ssh en permanence de chez le client sur ton serveur,
> >> > avec un tunnel Ã*** l'envers
> >> > - quand tu veux te connecter, tu fais une connexion ssh sur ton serveur,
> >> > avec un tunnel Ã*** l'endroit
> >> > et voilÃ*** :-)
> >>
> >> Oui pourquoi pas, mais je ne sais pas si c'est beaucoup plus simple ni
> >> plus sécurisé.
> >
> > en fait, pour moi c'est beaucoup plus simple parce que je connais bien
> > ssh (et du coup il n'y a rien Ã*** écrire en plus)
> >
> > plus sécurisé : je m'étais pas rendu compte au début, mais si tu
> > maîtrises vraiment très très bien le python et que t'es absolument
> > certain Ã*** la fois de l'absence de bug dans ton prgm et de l'absence de
> > faille de sécurité dans le compilateur ou l'interpreteur, y a un point
> > pour toi, puisque ça ne dépend pas de la sécurité du serveur ... :-)
> > (le plus de ssh c'est que les tunnels sont très solidement cryptés)
>
> Rien n'empêchera mon programme d'être crypté en ssl si besoin ou
> d'utiliser un tunnel... C'est surtout le principe qui me semble sûr. De
> ne faire qu'une chose, lancer tel exécutable. Par rapport Ã*** un tunnel,
> crypté certe, mais qui laisse faire quoi ?

prendre le contrôle via vnc sans mdp

comme je j'ai dit dans mes messages précédents, quand je t'ai proposé
cette solution je n'avais pas réalisé cet aspect sécurité dans ta
solution Ã*** toi :-)

donc j'imaginais que t'étais obligé de toutes façons d'avoir un serveur
dédié Ã*** ça (pas de serveur web dessus),
et que tu t'occupais de la sécurité maximale du serveur
(ce que je pense savoir très bien faire avec ssh)


en fait je crois que je croyais aussi que tu cherchais /une/ solution
pour
- ne pas avoir Ã*** t'occuper du routeur coté client
- pouvoir te connecter quand il est pas chez lui
et j'avais pas compris que t'avais deja un cahier des charges assez
serré sur ce que tu cherchais réellement ;-)
(faut dire que ton msg de départ n'était pas très clair, d'ailleurs je
te l'avais dit)


> Mais bon, ton idée de tunnel me donne une solution pour résoudre le
> problème de celui qui va faire la maintenance et qui n'aurait pas d'ip
> publique...

ok :-)


>
> > >
> >> >>
> >> >> > si oui, c'est gagné :-)) plus besoin de vnc inversé pour ça :-)
> >> >> > je te donnes les détails si ça t'intéresse :-)
> >> >>
> >> >> Tu ne serais pas entrain de réinventer le vpn par hasard ;-) ?
> >> >
> >> > heu non, c'est juste des tunnels ssh,
> >> > tu connais pas ? même pas le principe ?
> >> >
> >> > je te conseille vivement de t'informer :-)
> >
> > j'ai eu un peu de mal au début, mais maintenant que je connais je ne
> > m'en passe plus ;-)
> >
> >> > c'est pas tout Ã*** fait aussi souple que le vpn
> >>
> >> Mais ce que tu décris *est* un vpn !
> >
> > ah ?
> > pour toi c'est quoi la définition d'un vpn ?
>
> Pour tout le monde je crois, c'est un tunnel dans lequel passe tout un
> réseau privé.
> http://fr.wikipedia.org/wiki/Virtual_Private_Network

je viens de voir que ssh permet aussi de faire du vpn
(en fait je l'avais "aperçu" en lisant le man, mais j'ai pas cherché Ã***
comprendre parce que j'avais vu que c'était pas de mon niveau, et du
coup après j'ai oublié)

mais ce que je t'indiquais c'était juste de faire passer *une connexion
TCP* par le tunnel ssh, pas tout un réseau privé

chacun ses avantages et inconvénients :
pour une connexion TCP, l'utilisateur le plus simple suffit, même du
coté qui écoute,
alors que pour un vpn, obligé d'être root des 2 cotés (comme l'indique
le document externe sur ssh) ...

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/