Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Julien PACHET wrote in message <41b9a513$0$9855$:
ssh -R 22:monserveur.dyndns.org:1222 et de laisser le tunnel ouvert
Ce sont les options de -R qui ne sont pas bonnes. C'est dans l'ordre :
- port sur lequel écouter sur la machine cible ;
- hôte à contacter depuis la machine source ;
- port à contacter sur cet hôte.
Ici, on souhaite contacter le serveur ssh de la machine source elle-même, donc les deux dernières options doivent être boulot.domain.tld:22, ou simplement localhost:22. De plus, comme la machine cible a déjà un serveur ssh, le premier argument ne peut pas être 22, et doit d'ailleurs être au delà de 1024 si on n'est pas root.
Donc : -R 1222:localhost:22.
afin ensuite une fois sur la machine monserveur.dyndns.org de faire ssh -D 1222
Pour utiliser un -R, c'est un -p qu'il faut. -D est l'équivalent de -L (comme -R mais à l'envers) pour un forward configurable dynamiquement.
Julien PACHET wrote in message <41b9a513$0$9855$636a15ce@news.free.fr>:
ssh -R 22:monserveur.dyndns.org:1222 user@monserveur.dyndns.org
et de laisser le tunnel ouvert
Ce sont les options de -R qui ne sont pas bonnes. C'est dans l'ordre :
- port sur lequel écouter sur la machine cible ;
- hôte à contacter depuis la machine source ;
- port à contacter sur cet hôte.
Ici, on souhaite contacter le serveur ssh de la machine source elle-même,
donc les deux dernières options doivent être boulot.domain.tld:22, ou
simplement localhost:22. De plus, comme la machine cible a déjà un serveur
ssh, le premier argument ne peut pas être 22, et doit d'ailleurs être au
delà de 1024 si on n'est pas root.
Donc : -R 1222:localhost:22.
afin ensuite une fois sur la machine monserveur.dyndns.org de faire
ssh -D 1222 user@localhost
Pour utiliser un -R, c'est un -p qu'il faut. -D est l'équivalent de -L
(comme -R mais à l'envers) pour un forward configurable dynamiquement.
ssh -R 22:monserveur.dyndns.org:1222 et de laisser le tunnel ouvert
Ce sont les options de -R qui ne sont pas bonnes. C'est dans l'ordre :
- port sur lequel écouter sur la machine cible ;
- hôte à contacter depuis la machine source ;
- port à contacter sur cet hôte.
Ici, on souhaite contacter le serveur ssh de la machine source elle-même, donc les deux dernières options doivent être boulot.domain.tld:22, ou simplement localhost:22. De plus, comme la machine cible a déjà un serveur ssh, le premier argument ne peut pas être 22, et doit d'ailleurs être au delà de 1024 si on n'est pas root.
Donc : -R 1222:localhost:22.
afin ensuite une fois sur la machine monserveur.dyndns.org de faire ssh -D 1222
Pour utiliser un -R, c'est un -p qu'il faut. -D est l'équivalent de -L (comme -R mais à l'envers) pour un forward configurable dynamiquement.
VANHULLEBUS Yvan
Julien PACHET writes:
Bonjour,
[Note de moderation] J'ai hesite a valider ce post, qui est a moitie un probleme de securite, a moitie un probleme de reseau et de "bete" configuration d'outils.
Mon but est de pouvoir me connecter de chez moi à ma machine de bureau qui se trouve sur le LAN de mon entreprise.
Juste pour faire la remarque, ce genre d'acces est potentiellement dangereux pour la securite d'un LAN....
ssh -R 22:monserveur.dyndns.org:1222 et de laisser le tunnel ouvert
C'est en fait ssh -R 1222:localhost:22
afin ensuite une fois sur la machine monserveur.dyndns.org de faire ssh -D 1222
c'est un ssh -p 1222 qu'il faut faire...
mais çà marche pas...
Normal...
Questions: * Est-ce que c'est possible?
Oui.
* Comment peut-on faire?
En lisant correctement la doc et en utilisant les bons arguments...
Oui, je sais je pourrais aussi monter un openvpn entre les 2, mais avant ce soir je n'ai pas le temps :-(
D'un point de vue purement technique, le mieux est encore un tunnel IPSec.
Et d'un point de vue reseau, du TCP encapsule dans du TCP, c'est une catastrophe....
[Note de moderation]
J'ai hesite a valider ce post, qui est a moitie un probleme de
securite, a moitie un probleme de reseau et de "bete" configuration
d'outils.
Mon but est de pouvoir me connecter de chez moi à ma machine de bureau
qui se trouve sur le LAN de mon entreprise.
Juste pour faire la remarque, ce genre d'acces est potentiellement
dangereux pour la securite d'un LAN....
ssh -R 22:monserveur.dyndns.org:1222 user@monserveur.dyndns.org
et de laisser le tunnel ouvert
C'est en fait ssh -R 1222:localhost:22 user@monserveur.dyndns.org
afin ensuite une fois sur la machine monserveur.dyndns.org de faire
ssh -D 1222 user@localhost
c'est un ssh -p 1222 qu'il faut faire...
mais çà marche pas...
Normal...
Questions:
* Est-ce que c'est possible?
Oui.
* Comment peut-on faire?
En lisant correctement la doc et en utilisant les bons arguments...
Oui, je sais je pourrais aussi monter un openvpn entre les 2, mais
avant ce soir je n'ai pas le temps :-(
D'un point de vue purement technique, le mieux est encore un tunnel
IPSec.
Et d'un point de vue reseau, du TCP encapsule dans du TCP, c'est une
catastrophe....
[Note de moderation] J'ai hesite a valider ce post, qui est a moitie un probleme de securite, a moitie un probleme de reseau et de "bete" configuration d'outils.
Mon but est de pouvoir me connecter de chez moi à ma machine de bureau qui se trouve sur le LAN de mon entreprise.
Juste pour faire la remarque, ce genre d'acces est potentiellement dangereux pour la securite d'un LAN....
ssh -R 22:monserveur.dyndns.org:1222 et de laisser le tunnel ouvert
C'est en fait ssh -R 1222:localhost:22
afin ensuite une fois sur la machine monserveur.dyndns.org de faire ssh -D 1222
c'est un ssh -p 1222 qu'il faut faire...
mais çà marche pas...
Normal...
Questions: * Est-ce que c'est possible?
Oui.
* Comment peut-on faire?
En lisant correctement la doc et en utilisant les bons arguments...
Oui, je sais je pourrais aussi monter un openvpn entre les 2, mais avant ce soir je n'ai pas le temps :-(
D'un point de vue purement technique, le mieux est encore un tunnel IPSec.
Et d'un point de vue reseau, du TCP encapsule dans du TCP, c'est une catastrophe....
A +
VANHU.
Nicob
On Fri, 10 Dec 2004 15:48:19 +0000, VANHULLEBUS Yvan wrote:
D'un point de vue purement technique, le mieux est encore un tunnel IPSec.
Ou un tunnel SSL si le routeur ADSL de la maison ne sait pas gérer une NAT "propre". Et puis comme ça, on peut aussi utiliser cet accès depuis un hôtel ou le LAN d'un client ...
Nicob
On Fri, 10 Dec 2004 15:48:19 +0000, VANHULLEBUS Yvan wrote:
D'un point de vue purement technique, le mieux est encore un tunnel IPSec.
Ou un tunnel SSL si le routeur ADSL de la maison ne sait pas gérer une
NAT "propre". Et puis comme ça, on peut aussi utiliser cet accès depuis
un hôtel ou le LAN d'un client ...
On Fri, 10 Dec 2004 15:48:19 +0000, VANHULLEBUS Yvan wrote:
D'un point de vue purement technique, le mieux est encore un tunnel IPSec.
Ou un tunnel SSL si le routeur ADSL de la maison ne sait pas gérer une NAT "propre". Et puis comme ça, on peut aussi utiliser cet accès depuis un hôtel ou le LAN d'un client ...
Nicob
T0t0
"VANHULLEBUS Yvan" wrote in message news:
Oui, je sais je pourrais aussi monter un openvpn entre les 2, mais avant ce soir je n'ai pas le temps :-( D'un point de vue purement technique, le mieux est encore un tunnel
IPSec.
Pour du point à point, OpenVPN est très bien (voir mieux ;-)
Et d'un point de vue reseau, du TCP encapsule dans du TCP, c'est une catastrophe....
OpenVPN marche nativement en UDP et peut aussi fonctionner en TCP.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"VANHULLEBUS Yvan" <vanhu@nospam_free.fr> wrote in message
news:87is7a2m2b.fsf@actarus.zen.inc
Oui, je sais je pourrais aussi monter un openvpn entre les 2, mais
avant ce soir je n'ai pas le temps :-(
D'un point de vue purement technique, le mieux est encore un tunnel
IPSec.
Pour du point à point, OpenVPN est très bien (voir mieux ;-)
Et d'un point de vue reseau, du TCP encapsule dans du TCP, c'est une
catastrophe....
OpenVPN marche nativement en UDP et peut aussi fonctionner en TCP.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Oui, je sais je pourrais aussi monter un openvpn entre les 2, mais avant ce soir je n'ai pas le temps :-( D'un point de vue purement technique, le mieux est encore un tunnel
IPSec.
Pour du point à point, OpenVPN est très bien (voir mieux ;-)
Et d'un point de vue reseau, du TCP encapsule dans du TCP, c'est une catastrophe....
OpenVPN marche nativement en UDP et peut aussi fonctionner en TCP.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Julien PACHET
[Note de moderation] J'ai hesite a valider ce post, qui est a moitie un probleme de securite, a moitie un probleme de reseau et de "bete" configuration d'outils.
Je sais bien, mais étant donné que ce forum parle assez de ssh, tunnels crytés, VPNs, etc, qu'il était visité par des personnes à meme de savoir me répondre, j'ai posté ici. J'ai bien fait: 3 personnes m'ont donné la solution! Je les en remercie. Tu en fais parti.
Juste pour faire la remarque, ce genre d'acces est potentiellement dangereux pour la securite d'un LAN....
Oui, potentiellement: * Il faudrait d'abord se connecter sur ma machine chez moi (bon, ok, c'est certainement possible, rien n'est parfait) * savoir qu'il faut faire un ssh localhost:1222, et connaitre la pass-phrase pour s'y connecter (mot de passe non trivial). * Une fois ensuite sur ma machine du boulot, pour se connecter à la prod, re-passphrase ssh. Cela fait quand meme assez de barrière tout en ne sachant pas ce que l'on va trouver au bout.
En lisant correctement la doc et en utilisant les bons arguments...
La palice: "si les choses avaient été faites correctement, çà marcherait": ben forcement, et c'est bien pourquoi j'ai demandé de l'aide, Ô Être parfait qui fait toujours tout bien sans se tromper... Le forum serait certainement quasiement desert si tout le monde était comme toi :-).
D'un point de vue purement technique, le mieux est encore un tunnel IPSec.
J'ai déja un deamon openvpn qui tourne sur ma machine à la maison, je n'aurai donc pas choisi de monter un 2ème type de vpn... et je n'avais pas le temps de remettre en place un 2ème vpn avec clés SSLs, certificats et tout le bazar...
Et d'un point de vue reseau, du TCP encapsule dans du TCP, c'est une catastrophe....
Pour lancer des commandes shell c'est largement suffisant, mais c'est vrai que suivant les usages, encapsulages d'encapsulages, c'est pas le top...
A +
VANHU.
Malgré mes remarques sur tes critiques (accueillir comme cela un nouveau venu, super!), je te dis merci de m'avoir aidé.
-- Julien
[Note de moderation]
J'ai hesite a valider ce post, qui est a moitie un probleme de
securite, a moitie un probleme de reseau et de "bete" configuration
d'outils.
Je sais bien, mais étant donné que ce forum parle assez de ssh, tunnels
crytés, VPNs, etc, qu'il était visité par des personnes à meme de savoir
me répondre, j'ai posté ici. J'ai bien fait: 3 personnes m'ont donné la
solution! Je les en remercie. Tu en fais parti.
Juste pour faire la remarque, ce genre d'acces est potentiellement
dangereux pour la securite d'un LAN....
Oui, potentiellement:
* Il faudrait d'abord se connecter sur ma machine chez moi (bon, ok,
c'est certainement possible, rien n'est parfait)
* savoir qu'il faut faire un ssh localhost:1222, et connaitre la
pass-phrase pour s'y connecter (mot de passe non trivial).
* Une fois ensuite sur ma machine du boulot, pour se connecter à la
prod, re-passphrase ssh.
Cela fait quand meme assez de barrière tout en ne sachant pas ce que
l'on va trouver au bout.
En lisant correctement la doc et en utilisant les bons arguments...
La palice: "si les choses avaient été faites correctement, çà
marcherait": ben forcement, et c'est bien pourquoi j'ai demandé de
l'aide, Ô Être parfait qui fait toujours tout bien sans se tromper...
Le forum serait certainement quasiement desert si tout le monde était
comme toi :-).
D'un point de vue purement technique, le mieux est encore un tunnel
IPSec.
J'ai déja un deamon openvpn qui tourne sur ma machine à la maison, je
n'aurai donc pas choisi de monter un 2ème type de vpn... et je n'avais
pas le temps de remettre en place un 2ème vpn avec clés SSLs,
certificats et tout le bazar...
Et d'un point de vue reseau, du TCP encapsule dans du TCP, c'est une
catastrophe....
Pour lancer des commandes shell c'est largement suffisant, mais c'est
vrai que suivant les usages, encapsulages d'encapsulages, c'est pas le
top...
A +
VANHU.
Malgré mes remarques sur tes critiques (accueillir comme cela un nouveau
venu, super!), je te dis merci de m'avoir aidé.
[Note de moderation] J'ai hesite a valider ce post, qui est a moitie un probleme de securite, a moitie un probleme de reseau et de "bete" configuration d'outils.
Je sais bien, mais étant donné que ce forum parle assez de ssh, tunnels crytés, VPNs, etc, qu'il était visité par des personnes à meme de savoir me répondre, j'ai posté ici. J'ai bien fait: 3 personnes m'ont donné la solution! Je les en remercie. Tu en fais parti.
Juste pour faire la remarque, ce genre d'acces est potentiellement dangereux pour la securite d'un LAN....
Oui, potentiellement: * Il faudrait d'abord se connecter sur ma machine chez moi (bon, ok, c'est certainement possible, rien n'est parfait) * savoir qu'il faut faire un ssh localhost:1222, et connaitre la pass-phrase pour s'y connecter (mot de passe non trivial). * Une fois ensuite sur ma machine du boulot, pour se connecter à la prod, re-passphrase ssh. Cela fait quand meme assez de barrière tout en ne sachant pas ce que l'on va trouver au bout.
En lisant correctement la doc et en utilisant les bons arguments...
La palice: "si les choses avaient été faites correctement, çà marcherait": ben forcement, et c'est bien pourquoi j'ai demandé de l'aide, Ô Être parfait qui fait toujours tout bien sans se tromper... Le forum serait certainement quasiement desert si tout le monde était comme toi :-).
D'un point de vue purement technique, le mieux est encore un tunnel IPSec.
J'ai déja un deamon openvpn qui tourne sur ma machine à la maison, je n'aurai donc pas choisi de monter un 2ème type de vpn... et je n'avais pas le temps de remettre en place un 2ème vpn avec clés SSLs, certificats et tout le bazar...
Et d'un point de vue reseau, du TCP encapsule dans du TCP, c'est une catastrophe....
Pour lancer des commandes shell c'est largement suffisant, mais c'est vrai que suivant les usages, encapsulages d'encapsulages, c'est pas le top...
A +
VANHU.
Malgré mes remarques sur tes critiques (accueillir comme cela un nouveau venu, super!), je te dis merci de m'avoir aidé.
[Note de moderation] J'ai hesite a valider ce post, 3 personnes m'ont donné la
Tu en fais parti.
J'ai juste un commentaire a faore sur la moderation: Il (Julien) faut savoir que ce n'est pas parceque Julien a eu la reponse ici qu'il a bien fait de poster ici
Juste pour faire la remarque, ce genre d'acces est potentiellement dangereux pour la securite d'un LAN....
Oui, potentiellement: * Il faudrait d'abord se connecter sur ma machine chez moi (bon, ok, c'est certainement possible, rien n'est parfait) * savoir qu'il faut faire un ssh localhost:1222, et connaitre la pass-phrase pour s'y connecter (mot de passe non trivial). * Une fois ensuite sur ma machine du boulot, pour se connecter à la prod, re-passphrase ssh. Cela fait quand meme assez de barrière tout en ne sachant pas ce que l'on va trouver au bout.
C"est pas toujours la peine de "savoir ce que l'on va trouver au bout". Il suffit de pouvoir "entrer", ensuite on exploitera ce qu'on y trouvera. Si il a reussi a entrer discretement, tu pense bien qu'il disposera du temps necessaire pour analyser ce qui se passe... C'est comme si tu arrive a te cacher quelque part dans un entrepot de containers. Tu ne sais pas ce qu'il y a dans les containers, mais en attendant et en surveillant assez longtemps leurs activités tu saura bien ce qu'il y a dedans.
En lisant correctement la doc et en utilisant les bons arguments... Ô Être parfait qui fait toujours tout bien sans se tromper... Le forum
serait certainement quasiement desert si tout le monde était comme toi .
C'est faux. Usenet en general n'est pas une hotline. Un groupe de discussion peut tres bien accueillir des discussions qui sont des vraies discussions et non des appels a l'aide. Usenet n'est pas prevu pour "resoudre les problemes", il a ete prevu pour discuter. -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
[Note de moderation]
J'ai hesite a valider ce post,
3 personnes m'ont donné la
Tu en fais parti.
J'ai juste un commentaire a faore sur la moderation:
Il (Julien) faut savoir que ce n'est pas parceque Julien a eu la reponse
ici qu'il a bien fait de poster ici
Juste pour faire la remarque, ce genre d'acces est potentiellement
dangereux pour la securite d'un LAN....
Oui, potentiellement:
* Il faudrait d'abord se connecter sur ma machine chez moi (bon, ok,
c'est certainement possible, rien n'est parfait) * savoir qu'il faut
faire un ssh localhost:1222, et connaitre la pass-phrase pour s'y
connecter (mot de passe non trivial). * Une fois ensuite sur ma machine
du boulot, pour se connecter à la prod, re-passphrase ssh. Cela fait
quand meme assez de barrière tout en ne sachant pas ce que l'on va
trouver au bout.
C"est pas toujours la peine de "savoir ce que l'on va trouver au bout".
Il suffit de pouvoir "entrer", ensuite on exploitera ce qu'on y trouvera.
Si il a reussi a entrer discretement, tu pense bien qu'il disposera du
temps necessaire pour analyser ce qui se passe... C'est comme si tu arrive
a te cacher quelque part dans un entrepot de containers. Tu ne sais pas ce
qu'il y a dans les containers, mais en attendant et en surveillant assez
longtemps leurs activités tu saura bien ce qu'il y a dedans.
En lisant correctement la doc et en utilisant les bons arguments...
Ô Être parfait qui fait toujours tout bien sans se tromper... Le forum
serait certainement quasiement desert si tout le monde était comme toi .
C'est faux. Usenet en general n'est pas une hotline. Un groupe de
discussion peut tres bien accueillir des discussions qui sont des vraies
discussions et non des appels a l'aide.
Usenet n'est pas prevu pour "resoudre les problemes", il a ete prevu pour
discuter.
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
[Note de moderation] J'ai hesite a valider ce post, 3 personnes m'ont donné la
Tu en fais parti.
J'ai juste un commentaire a faore sur la moderation: Il (Julien) faut savoir que ce n'est pas parceque Julien a eu la reponse ici qu'il a bien fait de poster ici
Juste pour faire la remarque, ce genre d'acces est potentiellement dangereux pour la securite d'un LAN....
Oui, potentiellement: * Il faudrait d'abord se connecter sur ma machine chez moi (bon, ok, c'est certainement possible, rien n'est parfait) * savoir qu'il faut faire un ssh localhost:1222, et connaitre la pass-phrase pour s'y connecter (mot de passe non trivial). * Une fois ensuite sur ma machine du boulot, pour se connecter à la prod, re-passphrase ssh. Cela fait quand meme assez de barrière tout en ne sachant pas ce que l'on va trouver au bout.
C"est pas toujours la peine de "savoir ce que l'on va trouver au bout". Il suffit de pouvoir "entrer", ensuite on exploitera ce qu'on y trouvera. Si il a reussi a entrer discretement, tu pense bien qu'il disposera du temps necessaire pour analyser ce qui se passe... C'est comme si tu arrive a te cacher quelque part dans un entrepot de containers. Tu ne sais pas ce qu'il y a dans les containers, mais en attendant et en surveillant assez longtemps leurs activités tu saura bien ce qu'il y a dedans.
En lisant correctement la doc et en utilisant les bons arguments... Ô Être parfait qui fait toujours tout bien sans se tromper... Le forum
serait certainement quasiement desert si tout le monde était comme toi .
C'est faux. Usenet en general n'est pas une hotline. Un groupe de discussion peut tres bien accueillir des discussions qui sont des vraies discussions et non des appels a l'aide. Usenet n'est pas prevu pour "resoudre les problemes", il a ete prevu pour discuter. -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
Julien PACHET
Ô Être parfait qui fait toujours tout bien sans se tromper... Le forum serait certainement quasiement desert si tout le monde était comme toi .
C'est faux. Usenet en general n'est pas une hotline. Un groupe de discussion peut tres bien accueillir des discussions qui sont des vraies discussions et non des appels a l'aide. Usenet n'est pas prevu pour "resoudre les problemes", il a ete prevu pour discuter.
En effet, un newsgroup est un lieu de discussion. Il sert aussi à aider des utilisateurs qui se pose des questions. Pour ma part * J'ai consulté les man (Anglais et Français au cas ou j'interpreterai les 2 versions différement) de la commande ssh et j'ai cherché si il y avait pas d'autres commandes en relation avec ssh (au cas ou). * J'ai cherché sur Google mais les exemples donnés ne semblais pas adapté à mon cas (ouvrir un tunnel en sens inverse du ssh initial. Cela ne m'a pas aidé, et je n'arrivai toujours pas à mettre en place le système. * J'ai donc posté ici, et de bonnes volontés m'ont donné la solution, qui parallelement pourront peut-être aider d'autres utlisateurs.
Ô Être parfait qui fait toujours tout bien sans se tromper... Le forum
serait certainement quasiement desert si tout le monde était comme toi .
C'est faux. Usenet en general n'est pas une hotline. Un groupe de
discussion peut tres bien accueillir des discussions qui sont des vraies
discussions et non des appels a l'aide.
Usenet n'est pas prevu pour "resoudre les problemes", il a ete prevu pour
discuter.
En effet, un newsgroup est un lieu de discussion. Il sert aussi à aider
des utilisateurs qui se pose des questions.
Pour ma part
* J'ai consulté les man (Anglais et Français au cas ou j'interpreterai
les 2 versions différement) de la commande ssh et j'ai cherché si il y
avait pas d'autres commandes en relation avec ssh (au cas ou).
* J'ai cherché sur Google mais les exemples donnés ne semblais pas
adapté à mon cas (ouvrir un tunnel en sens inverse du ssh initial. Cela
ne m'a pas aidé, et je n'arrivai toujours pas à mettre en place le système.
* J'ai donc posté ici, et de bonnes volontés m'ont donné la solution,
qui parallelement pourront peut-être aider d'autres utlisateurs.
Ô Être parfait qui fait toujours tout bien sans se tromper... Le forum serait certainement quasiement desert si tout le monde était comme toi .
C'est faux. Usenet en general n'est pas une hotline. Un groupe de discussion peut tres bien accueillir des discussions qui sont des vraies discussions et non des appels a l'aide. Usenet n'est pas prevu pour "resoudre les problemes", il a ete prevu pour discuter.
En effet, un newsgroup est un lieu de discussion. Il sert aussi à aider des utilisateurs qui se pose des questions. Pour ma part * J'ai consulté les man (Anglais et Français au cas ou j'interpreterai les 2 versions différement) de la commande ssh et j'ai cherché si il y avait pas d'autres commandes en relation avec ssh (au cas ou). * J'ai cherché sur Google mais les exemples donnés ne semblais pas adapté à mon cas (ouvrir un tunnel en sens inverse du ssh initial. Cela ne m'a pas aidé, et je n'arrivai toujours pas à mettre en place le système. * J'ai donc posté ici, et de bonnes volontés m'ont donné la solution, qui parallelement pourront peut-être aider d'autres utlisateurs.
Jeremy JUST
On 11 Dec 2004 00:16:57 GMT Julien PACHET wrote:
* Il faudrait d'abord se connecter sur ma machine chez moi (bon, ok, c'est certainement possible, rien n'est parfait) * savoir qu'il faut faire un ssh localhost:1222, et connaitre la pass-phrase pour s'y connecter (mot de passe non trivial). * Une fois ensuite sur ma machine du boulot, pour se connecter à la prod, re-passphrase ssh.
Une fois ta machine chez toi compromise, il est possible de savoir tout ce que tu fais. Donc avoir des passphrases sur les autres machines n'offre plus de véritable protection.
Une solution peut être le mot de passe à usage unique (pour peu que la réponse au challenge ne soit pas calculée sur ta machine, mais sur une autre, ou à l'avance sur une machine de l'entreprise).
-- Jérémy JUST
On 11 Dec 2004 00:16:57 GMT
Julien PACHET <julien.pachet@_laposte_._net_> wrote:
* Il faudrait d'abord se connecter sur ma machine chez moi (bon, ok,
c'est certainement possible, rien n'est parfait)
* savoir qu'il faut faire un ssh localhost:1222, et connaitre la
pass-phrase pour s'y connecter (mot de passe non trivial).
* Une fois ensuite sur ma machine du boulot, pour se connecter à la
prod, re-passphrase ssh.
Une fois ta machine chez toi compromise, il est possible de savoir
tout ce que tu fais. Donc avoir des passphrases sur les autres machines
n'offre plus de véritable protection.
Une solution peut être le mot de passe à usage unique (pour peu que la
réponse au challenge ne soit pas calculée sur ta machine, mais sur une
autre, ou à l'avance sur une machine de l'entreprise).
* Il faudrait d'abord se connecter sur ma machine chez moi (bon, ok, c'est certainement possible, rien n'est parfait) * savoir qu'il faut faire un ssh localhost:1222, et connaitre la pass-phrase pour s'y connecter (mot de passe non trivial). * Une fois ensuite sur ma machine du boulot, pour se connecter à la prod, re-passphrase ssh.
Une fois ta machine chez toi compromise, il est possible de savoir tout ce que tu fais. Donc avoir des passphrases sur les autres machines n'offre plus de véritable protection.
Une solution peut être le mot de passe à usage unique (pour peu que la réponse au challenge ne soit pas calculée sur ta machine, mais sur une autre, ou à l'avance sur une machine de l'entreprise).
