OVH Cloud OVH Cloud

Tunnel SSH où est l'erreur ?

17 réponses
Avatar
Pierre
Sur un réseau local je dispose d'un Mac sous OS X sur lequel j'ai activé
:
- Session à distance
- Apple Remote Access Client

1/ Sur ce même réseau local je dispose d'un firewall sur lequel j'ai
redirigé les ports (3283 et 5900) d'Apple Remote Access de telle façon
que je puisse piloter le Mac sous OS depuis un autre Mac situé à
l'extérieur du réseau local (via Internet)
Tout cela fonctionne bien, le mac externe indique l'adresse IP publique
du firewall et zou il se retrouv

2/ j'ai en suite voulu faire la même chose en utilisant un tunnel ssh
entre mon mac externe et le Mac du réseau local afin d'y faire circuler
la connexion Apple Remote Access.

Sur le Firewall, j'ai uniquement redirigé le port 22 vers le Mac interne.
Depuis l'application terminal du Mac externe, j'ai tapé la commande
suivante :

ssh -N user@adresse_public_du_firewall -L 3283:127.0.0.1:3283 -L
5900:127.0.0.1:5900

La connexion SSH s'effectue sans pb (demande de mot de passe, ...). Mais
parfois, j'ai un message du style :
bind: Address already in use
dont je ne sais pas comment me débarasser. Mais bon ce n'est pas le plus
gros pb.

Là où ça se complique, c'est lorsque je veux à l'aide d'"Apple Remote
Desktop Admin" situé sur le poste externe atteindre le poste Mac du
réseau local.

Quelle adresse IP dois-je indiquer dans ARD admin ?
J'ai essayé de saisir tout simplement 127.0.0.1 ! mais ARD admin établi
une connexion sur lui même (c'est à dire sur le poste sur lequel il est
installé et non pas sur le Mac du réseau local distant).

Qu'est-ce que j'ai oublié de faire ?

7 réponses

1 2
Avatar
laurent.pertois
Jacques Perrocheau wrote:

OK, donc mon habitude, utiliser une redirection sur un port au dessus de
1024 est "recommendable". La protection me semble "intelligente" pour
éviter de polluer...


Oui, enfin, tout dépend de ce que tu cherches et si tu as la possibilité
de fournir un numéro de port différent dans ton appli. De plus, en
ouvrant un port sur ta machine, d'autres peuvent l'utiliser pour voyager
à travers le tunnel, changer de port peut se révéler génant ou
sécurisant.

Ce que je ne comprends pas c'est l'affirmation de Pierre, qui dit être
obligé de faire cela par root, alors qu'il ne s'occupe que du 3283 et du
5900.


Pas compris non plus.

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Avatar
Pierre
In article <cmaq7n$hsj$,
Jacques Perrocheau wrote:

Ce que je ne comprends pas c'est l'affirmation de Pierre, qui dit être
obligé de faire cela par root, alors qu'il ne s'occupe que du 3283 et du
5900.


1 correctif et 1 question :

Correctif :
-----------

Effectivement vous avez tout à fait raison et j'apporte ici un correctif
à ma précédente affirmation.
Il n'est pas nécessaire d'être sous root pour les ports supérieurs à
1024 (ce qui est le cas pour ARD : port 3283 et 5900)

Mon affirmation était un peu rapide, et je dois reconnaître que j'avais
fait tellement de tests divers et variés que je ne devais plus savoir où
j'en étais. Mea culpa !

Pour ce qui est du message : Bind : address alreay in use, il signifie
que j'ai des process SSH non terminés sur mon poste. Pour les faire
disparaitre, il suffit de faire :
ps ax | grep ssh
puis un kill sur les process concernés
en suite on peut à nouveau entrer une commande ssh

Question :
-----------

J'ai bien compris l'interet et le mode opératoire des tunnels ssh locaux
et je recherche maintenant une explication claire sur l'interet des
tunnels SSH distants. l'un d'entre vous aurait-il un exemple de
situation concrète qui pourrait justifier l'utilisation d'un tunnel SSH
distant (ou remote) ?

j'ai bien vu des explications sur différents sites et notamment le site
de 'ssh tunnel manager' (http://projects.tynsoe.org/fr/stm/doc.php) mais
je ne vois pas la différence avec la redirection de port local dans son
exemple. Idem sur le site :
http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Port_Fo
rwarding.html

Je ne comprends pas l'interet ni le les flux et le sens des translations
de ports.

Merci

Avatar
Jacques Perrocheau
In article ,
Pierre wrote:

Question :
-----------

J'ai bien compris l'interet et le mode opératoire des tunnels ssh locaux
et je recherche maintenant une explication claire sur l'interet des
tunnels SSH distants. l'un d'entre vous aurait-il un exemple de
situation concrète qui pourrait justifier l'utilisation d'un tunnel SSH
distant (ou remote) ?

j'ai bien vu des explications sur différents sites et notamment le site
de 'ssh tunnel manager' (http://projects.tynsoe.org/fr/stm/doc.php) mais
je ne vois pas la différence avec la redirection de port local dans son
exemple. Idem sur le site :
http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Port_Fo
rwarding.html


Effectivement, les deux explications sont sûrement limpides uniquement
pour quelqu'un qui a déjà compris.... ;)

Les deux pèchent par défaut de désignation des "objets" en présence.


Je ne comprends pas l'intrt ni le les flux et le sens des translations
de ports.


Bon je te livre ce que j'ai compris, comme cela j'espère amorcer la
discussion.

Dans le premier cas "local redirection" tu crées toute la "cuisine ssh"
à partir du poste client qui te servira à atteindre un service sur
machine par un tunnel ssh tournant sur une machine "directement
accessible". La manip se fait à deux "intervenants" si le service
atteindre est sur la même machine (portredirig:localhost:portnormal) ou
à trois si tu veux atteindre une autre machine du même LAN distant que
le serveur ssh ((portredirig:numroIPdutroisièmelarron:portnormal).

Dans le deuxième cas "remote redirection", si j'ai bien compris, on
prépare la "cuisine ssh" sur une machine qui a un accès "normal" à une
machine d'un LAN derrière un firewall ou d'un service NAT, pour
permettre à un troisième larron "extérieur" ou plus de se connecter à la
machine planquée dans le LAN et qui ne peut être atteinte directement.
Ce qui dans les explications citées est qualifié d'inverse... à la
méthode précédente, je trouve que c'est un peu court ;)

Bon si j'ai tout faux vous me le dites, je crois que cela fera avancer
smilblick...

--
Jacques PERROCHEAU
Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510
Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex
Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74

Avatar
Grrrr
On Fri, 05 Nov 2004 11:15:33 +0100, Jacques Perrocheau wrote:

In article ,
Pierre wrote:

Question :
-----------

J'ai bien compris l'interet et le mode opératoire des tunnels ssh locaux
et je recherche maintenant une explication claire sur l'interet des
tunnels SSH distants. l'un d'entre vous aurait-il un exemple de
situation concrète qui pourrait justifier l'utilisation d'un tunnel SSH
distant (ou remote) ?
[...]


Je ne comprends pas l'intrt ni le les flux et le sens des translations
de ports.


Bon je te livre ce que j'ai compris, comme cela j'espère amorcer la
discussion.


En fait, c'est très simple.
Dans le cas d'une redirection locale, tu rediriges un service local pour
le rendre disponible à une machine distante à travers un tunnel ssh.
Exemple: j'ai un serveur toto en local qui écoute sur le port 1234.
Je le redirige vers la machine "ailleurs" sur le port 4321.
Ensuite, toute application ou utilisateur de la machine "ailleurs" qui se
connecte sur cette machine sur le port 4321 se connecte en fait, via le
tunnel ssh, sur le serveur toto de ma machine sur le port 1234.

La redirection distante, c'est l'inverse:
le serveur toto est sur la machine distante sur le port 1234. Je crée un
tunnel ssh qui m'ouvre le port local 4321 et établit un tunnel vers le
serveur distant toto. Ainsi, mes applis locales peuvent se connecter en
local sur le port 4321 pour atteindre serveur en question via le tunnel.

En fait, tu l'as dit, ça peut être un peu plus compliqué puisque le
serveur peut également être sur une troisième machine accessible par le
réseau local (dans le cas de la redirection locale) ou le réseau de la
machine distante (dans le cas de la redirection "remote"), mais ces cas ne
changent rien aux principes de base.


Avatar
Pierre
In article ,
Grrrr wrote:

On Fri, 05 Nov 2004 11:15:33 +0100, Jacques Perrocheau wrote:

In article ,
Pierre wrote:

Question :
-----------

J'ai bien compris l'interet et le mode opratoire des tunnels ssh locaux
et je recherche maintenant une explication claire sur l'interet des
tunnels SSH distants. l'un d'entre vous aurait-il un exemple de
situation concrète qui pourrait justifier l'utilisation d'un tunnel SSH
distant (ou remote) ?
[...]


Je ne comprends pas l'intrt ni le les flux et le sens des translations
de ports.


Bon je te livre ce que j'ai compris, comme cela j'espère amorcer la
discussion.


En fait, c'est très simple.
Dans le cas d'une redirection locale, tu rediriges un service local pour
le rendre disponible une machine distante travers un tunnel ssh.
Exemple: j'ai un serveur toto en local qui coute sur le port 1234.
Je le redirige vers la machine "ailleurs" sur le port 4321.
Ensuite, toute application ou utilisateur de la machine "ailleurs" qui se
connecte sur cette machine sur le port 4321 se connecte en fait, via le
tunnel ssh, sur le serveur toto de ma machine sur le port 1234.

La redirection distante, c'est l'inverse:
le serveur toto est sur la machine distante sur le port 1234. Je cre un
tunnel ssh qui m'ouvre le port local 4321 et tablit un tunnel vers le
serveur distant toto. Ainsi, mes applis locales peuvent se connecter en
local sur le port 4321 pour atteindre serveur en question via le tunnel.

En fait, tu l'as dit, a peut tre un peu plus compliqu puisque le
serveur peut galement tre sur une troisième machine accessible par le
rseau local (dans le cas de la redirection locale) ou le rseau de la
machine distante (dans le cas de la redirection "remote"), mais ces cas ne
changent rien aux principes de base.


Je suis vraiment navre mais ce n'est toujours pas clair pour moi. Peut
etre suis-je complètement bouché. Ce qui me trouble ce sont les
références employées pour parler des machines (distante, locale, ...)
tout cela dépend du lieu o l'on se trouve.

Puis-je me permettre de proposer les dénominations suivantes:

1/ Soit une entreprise disposant d'un réseau informatique local. Sur ce
réseau on trouve :
- Un serveur Unix : appelons-le 'Serveur' dans la suite de
l'explication. On supposera qu'un utilisateur 'joe' disposant du mot de
passe 'xxx' a ete defini sur ce serveur. L'adresse IP locale de ce poste
est : 192.168.1.100

- Un modem-routeur ADSL relie le reseau informatique local de
l'entreprise a Internet. On suppose qu'une adresse ip fixe publique est
associee a cette connexion Internet. Appelons-la 'Adresse_IP_Publique'.
ce routeur est capable de rediriger le port 22 (SSH) des demandes de
connexion provenant d'internet vers le 'Serveur' Unix situe sur le
reseau local de l'entreprise. Applelons-le 'routeur' dans le reste de
l'explication. L'adresse IP locale de ce poste est : 192.168.1.150

- Un poste utilisateur sur lequel se trouve l'application VNC qui
accepte les connexions IP sur le port 5900 afin que ce poste puisse etre
contolé par un autre poste pour de la maintenance. Appelons-le poste
'Utilisateur' dans la suite cette explication. L'adresse IP locale de ce
poste est : 192.168.1.200

2/ Soit un poste isole fonctionnant sous Mac OS X situe l'exterieur des
locaux de l'entreprise (par exemple dans l'appartement d'un des salaries
de cette entreprise) et connecte a internet par une connexion ADSL avec
IP dynamique. Appelons-le 'Appartement' dans la suite de cette
explication.

Tunnel SSH local :
-----------------
j'utilise un tunnel SSH de type 'local' lorsque le poste 'Appartement'
souhaite piloter via VNC le poste 'Utilisateur'. La commande SSH saisir
sur le poste 'Appartement' est :

ssh -N -L 5900:192.168.1.200:5900

Ainsi un tunnel SSH est etabli entre le poste 'Appartement' et le
'Serveur' (via la redirection de port 22 faite sur le routeur). Le
serveur redirige ensuite toutes les demandes d'accès concernant le port
5900 en provenance de 'Appartement' sur la machine 'Utilisateur'

Pour ce faire le poste 'Appartement' doit saisir 127.0.0.1 dans VNC pour
pouvoir atteindre le poste 'Utilisateur'

Voila donc ce que j'ai compris de l'utilisation des tunnels SSH de type
local.

Maintenant il me reste comprendre celui des tunnels SSH 'remote' et la
c'est une autre histoire car je n'ai encore rien compris (snif)

Tunnel SSH remote :
------------------

Vous me dites que le tunnel SSH remote c'est le contraire du local. Dans
mon exemple ci-dessus, c'est quoi le contraire ? :
qui veut acceder quoi ? Est-ce le poste 'Utilisateur' qui veut
accder au poste 'Appartement' ?
qui doit taper la commande SSH -R ?
quelles conditions doivent etre remplies pour pouvoir faire cela ?

Merci d'avance pour votre aide.



Avatar
Jacques Perrocheau
In article ,
Pierre wrote:

Je suis vraiment navre mais ce n'est toujours pas clair pour moi. Peut
etre suis-je complètement bouché. Ce qui me trouble ce sont les
références employées pour parler des machines (distante, locale, ...)
tout cela dépend du lieu o l'on se trouve.


Oui, toutafait...

Puis-je me permettre de proposer les dénominations suivantes:


N'as-tu pas lu mon post ? ;-) Message-ID:
<cmfjs5$ec8$


1/ Soit une entreprise disposant d'un réseau informatique local. Sur ce
réseau on trouve :
- Un serveur Unix : appelons-le 'Serveur' dans la suite de
l'explication. On supposera qu'un utilisateur 'joe' disposant du mot de
passe 'xxx' a ete defini sur ce serveur. L'adresse IP locale de ce poste
est : 192.168.1.100

- Un modem-routeur ADSL relie le reseau informatique local de
l'entreprise a Internet. On suppose qu'une adresse ip fixe publique est
associee a cette connexion Internet. Appelons-la 'Adresse_IP_Publique'.
ce routeur est capable de rediriger le port 22 (SSH) des demandes de
connexion provenant d'internet vers le 'Serveur' Unix situe sur le
reseau local de l'entreprise. Applelons-le 'routeur' dans le reste de
l'explication. L'adresse IP locale de ce poste est : 192.168.1.150

- Un poste utilisateur sur lequel se trouve l'application VNC qui
accepte les connexions IP sur le port 5900 afin que ce poste puisse etre
contolé par un autre poste pour de la maintenance. Appelons-le poste
'Utilisateur' dans la suite cette explication. L'adresse IP locale de ce
poste est : 192.168.1.200

2/ Soit un poste isole fonctionnant sous Mac OS X situe l'exterieur des
locaux de l'entreprise (par exemple dans l'appartement d'un des salaries
de cette entreprise) et connecte a internet par une connexion ADSL avec
IP dynamique. Appelons-le 'Appartement' dans la suite de cette
explication.

Tunnel SSH local :
-----------------
j'utilise un tunnel SSH de type 'local' lorsque le poste 'Appartement'
souhaite piloter via VNC le poste 'Utilisateur'. La commande SSH saisir
sur le poste 'Appartement' est :

ssh -N -L 5900:192.168.1.200:5900

Ainsi un tunnel SSH est etabli entre le poste 'Appartement' et le
'Serveur' (via la redirection de port 22 faite sur le routeur). Le
serveur redirige ensuite toutes les demandes d'accès concernant le port
5900 en provenance de 'Appartement' sur la machine 'Utilisateur'

Pour ce faire le poste 'Appartement' doit saisir 127.0.0.1 dans VNC pour
pouvoir atteindre le poste 'Utilisateur'

Voila donc ce que j'ai compris de l'utilisation des tunnels SSH de type
local.


Vouif... en ajoutant que la manip peut être faite aussi à trois, (c'est
toujours plus fun ;-)). Le service ssh n'a pas à être obligatoirement
situé sur la machine dont on souhaites atteindre le service par ce
tunnel ssh.

C'est à dire dans ssh -N -L
5900:192.168.1.200:5900 on met un autre numéro IP que celui de la
machine 'Utilisateur'. Mais il faut bien évidemment garder la
redirection du protocole ssh et son port standard 22 toujours vers la
machine qui fait tourner le service ssh en l'occurence 'Utilisateur'
dans ta "nomenclature".


Maintenant il me reste comprendre celui des tunnels SSH 'remote' et la
c'est une autre histoire car je n'ai encore rien compris (snif)

Tunnel SSH remote :
------------------

Vous me dites que le tunnel SSH remote c'est le contraire du local.


Ouep, c'est là que tout le monde se défile... c'est simple c'est le
contraire que diable ;-).


Dans mon exemple ci-dessus, c'est quoi le contraire ? :

qui veut acceder quoi ?


Un poste extérieur 'Appartement' vers un service derrière un firewall
(ce que tu appelles pas très bien poste 'Utilisateur') par
l'intermédiaire d'un "troisième laron" qui lui a accès à ce service
"directement", si j'ai bien compris. et qui n'est pas derrière le
firewall.

Est-ce le poste 'Utilisateur' qui veut accéder au poste 'Appartement' ?


Non.

qui doit taper la commande SSH -R ?


Le troisième larron.

La cuisine ssh n'est pas "initiée" par le poste client 'Appartement'
dans ce cas. Le poste client 'Appartement" dans ce cas pointe vers cette
machine 'troisième larron' avec la bonne méthode (http, ftp, afp,
vnc,...) et le port indiqué pour atteindre le "serveur planqué".

le fait que le tunnel est "initié" "plutôt côté serveur" qui peut faire
dire de manière pas très claire que c'est le contraire de la méthode
"local".

quelles conditions doivent etre remplies pour pouvoir faire cela ?


Je crois que j'ai tout dit.

Bon je crois qu'on va mieux comprendre la raison du "contraire" dans le
premier cas "redirection locale": A partir d'une machine "extérieure" on
peut atteindre toutes les machines "planquées" d'un LAN, dans la
"redirection remote" n'importe quelle machine "extérieure" peut
atteindre une machine "planquée".

Des contradicteurs... ? si je dis de conneries il faut me corriger... Je
ne demande pas pour autant que vous me mettiez une note... ;)

--
Jacques PERROCHEAU
Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510
Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex
Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74

Avatar
Schmurtz
Pierre wrote:

Tunnel SSH remote :
------------------

Vous me dites que le tunnel SSH remote c'est le contraire du local. Dans
mon exemple ci-dessus, c'est quoi le contraire ? :
qui veut acceder quoi ? Est-ce le poste 'Utilisateur' qui veut
accder au poste 'Appartement' ?
qui doit taper la commande SSH -R ?
quelles conditions doivent etre remplies pour pouvoir faire cela ?


C'est comme du local, mais dans l'autre sens. C'est à dire qu'au lieu
d'ouvrir un tunnel dans le sens local>distant, ça ouvre un tunnel dans
le sens distant>local. En général, ça sert à rien : c'est les tunnels
"locaux" qui servent le plus.

Imaginons deux machines Astérix et Obélix. Comme moi je suis Idéfix, je
suis assis à côté d'Obélix. Je lance alors la commande suivant dans mon
terminal :

obelix> ssh -N -R 1234:localhost:5678

J'ai alors mis en place un tunnel ssh entre asterix et obelix qui fait
la chose suivante : toutes les connexions effectués sur asterix:1234
provenant d'asterix sont redirigées vers obelix:5678 (et semblent venir
d'obelix). Pour que cela marche, il suffit d'avoir un accès ssh depuis
obelix vers asterix.

La commande suivante aurait ouvert un tunnel dans l'autre sens :

obelix> ssh -N -L 1234:localhost:5678

c'est-à-dire : toutes les connexions effectués sur obelix:1234 provenant
d'obelix sont redirigées vers asterix:5678 (et semblent venir
d'asterix). Les conditions de fonctionnement sont les mêmes : accès ssh
depuis obelix vers asterix.

Les tunnels SSH sont quelque chose d'assez complexes. Il suffit (et
c'est bien là le problème) de savoir exactement comment ça marche pour
les comprendre.

--
Schmurtz

1 2