Sur le mac client (mon mac) :
ssh -R 5500:127.0.0.1:5500
Et on tape ça où mon cher Jean-Paul ? Dans le terminal, cotvnc ?
Sur le mac client (mon mac) :
ssh -R 5500:127.0.0.1:5500 user@ip_du_mac_serveur
Et on tape ça où mon cher Jean-Paul ? Dans le terminal, cotvnc ?
Sur le mac client (mon mac) :
ssh -R 5500:127.0.0.1:5500
Et on tape ça où mon cher Jean-Paul ? Dans le terminal, cotvnc ?
Dans le Terminal.
Si tu veux le faire rapidement, fait pomme-shift-K dans le T
Puis :
1)clic sur "Shell sécurisé"
2)clic sur le "+" de droite
tape toute la fin de la commande ci-dessus (tous sauf "ssh")
et fait OK
3) clique sur la nouvelle entrée créée
4) passe le protocole en automatique
5) clique sur "se connecter"
Les fois suivantes, tu n'auras pas besoin de faire le point (2). Donc
juste quelques clics...
Dans le Terminal.
Si tu veux le faire rapidement, fait pomme-shift-K dans le T
Puis :
1)clic sur "Shell sécurisé"
2)clic sur le "+" de droite
tape toute la fin de la commande ci-dessus (tous sauf "ssh")
et fait OK
3) clique sur la nouvelle entrée créée
4) passe le protocole en automatique
5) clique sur "se connecter"
Les fois suivantes, tu n'auras pas besoin de faire le point (2). Donc
juste quelques clics...
Dans le Terminal.
Si tu veux le faire rapidement, fait pomme-shift-K dans le T
Puis :
1)clic sur "Shell sécurisé"
2)clic sur le "+" de droite
tape toute la fin de la commande ci-dessus (tous sauf "ssh")
et fait OK
3) clique sur la nouvelle entrée créée
4) passe le protocole en automatique
5) clique sur "se connecter"
Les fois suivantes, tu n'auras pas besoin de faire le point (2). Donc
juste quelques clics...
Sauf que par cette méthode, je n'ai pas trouvé pour interrompre le
tunnel ssh que faire [control] c dans la fenêtre du Terminal. Je ne
trouve pas cela très smart.
Sauf que par cette méthode, je n'ai pas trouvé pour interrompre le
tunnel ssh que faire [control] c dans la fenêtre du Terminal. Je ne
trouve pas cela très smart.
Sauf que par cette méthode, je n'ai pas trouvé pour interrompre le
tunnel ssh que faire [control] c dans la fenêtre du Terminal. Je ne
trouve pas cela très smart.
Serge Horrent wrote:Sur le mac client (mon mac) :
ssh -R 5500:127.0.0.1:5500
Et on tape ça où mon cher Jean-Paul ? Dans le terminal, cotvnc ?
Dans le Terminal.
Si tu veux le faire rapidement, fait pomme-shift-K dans le T
Puis :
1)clic sur "Shell sécurisé"
2)clic sur le "+" de droite
tape toute la fin de la commande ci-dessus (tous sauf "ssh")
et fait OK
3) clique sur la nouvelle entrée créée
4) passe le protocole en automatique
5) clique sur "se connecter"
Les fois suivantes, tu n'auras pas besoin de faire le point (2). Donc
juste quelques clics...
Pas indispensable par ailleurs de t'embêter avec les clefs. Lors de la
connexion ssh te demanderas le mot de passe. Plus tard tu étudieras la
solution clef (avec sshkeychain, par exemple).
Serge Horrent <minfiu@free.fr.invalid> wrote:
Sur le mac client (mon mac) :
ssh -R 5500:127.0.0.1:5500 user@ip_du_mac_serveur
Et on tape ça où mon cher Jean-Paul ? Dans le terminal, cotvnc ?
Dans le Terminal.
Si tu veux le faire rapidement, fait pomme-shift-K dans le T
Puis :
1)clic sur "Shell sécurisé"
2)clic sur le "+" de droite
tape toute la fin de la commande ci-dessus (tous sauf "ssh")
et fait OK
3) clique sur la nouvelle entrée créée
4) passe le protocole en automatique
5) clique sur "se connecter"
Les fois suivantes, tu n'auras pas besoin de faire le point (2). Donc
juste quelques clics...
Pas indispensable par ailleurs de t'embêter avec les clefs. Lors de la
connexion ssh te demanderas le mot de passe. Plus tard tu étudieras la
solution clef (avec sshkeychain, par exemple).
Serge Horrent wrote:Sur le mac client (mon mac) :
ssh -R 5500:127.0.0.1:5500
Et on tape ça où mon cher Jean-Paul ? Dans le terminal, cotvnc ?
Dans le Terminal.
Si tu veux le faire rapidement, fait pomme-shift-K dans le T
Puis :
1)clic sur "Shell sécurisé"
2)clic sur le "+" de droite
tape toute la fin de la commande ci-dessus (tous sauf "ssh")
et fait OK
3) clique sur la nouvelle entrée créée
4) passe le protocole en automatique
5) clique sur "se connecter"
Les fois suivantes, tu n'auras pas besoin de faire le point (2). Donc
juste quelques clics...
Pas indispensable par ailleurs de t'embêter avec les clefs. Lors de la
connexion ssh te demanderas le mot de passe. Plus tard tu étudieras la
solution clef (avec sshkeychain, par exemple).
Et si tu n'utilises pas cette méthode, tu le termines comment ?...
Un tunnel ssh débouche sur un shell. Or la terminaison normale du shell
se fait quand il trouve le caractère EOF (end of file). Et ceci que le
shell lise un fichier (script) ou qu'il soit en interactif (dans une
fenêtre de Terminal).
Le caractère EOF étant en fait un control-D, c'est avec ce caractère que
tu peux terminer un shell, et même que tu dois normalement le terminer
(car les seuls signaux qu'accepte un shell sont ceux qu'on ne peut
détourner ; donc pour tuer un shell par signal , c'est kill -9)
Or il se trouve que lorsque ssh reçoit la fin de son processus fils
qu'est le shell, il se termine tout à fait normalement. Tu peux vérifier
avec top, après ^D, le process ssh a disparu. Et avec ktrace tu peux
voir que la terminaison est propre :
4467 ssh GIO fd 2 wrote 44 bytes
"Connection to ...... closed.r
"
4467 ssh RET write 44/0x2c
4467 ssh CALL shutdown(0x11,0x2)
4467 ssh RET shutdown 0
4467 ssh CALL close(0x11)
4467 ssh RET close 0
4467 ssh CALL exit(0)
Donc pour terminer un tunnel ssh, tu peux faire control-D.
Par contre ^C chez moi ne donne rien.
Et si tu n'utilises pas cette méthode, tu le termines comment ?...
Un tunnel ssh débouche sur un shell. Or la terminaison normale du shell
se fait quand il trouve le caractère EOF (end of file). Et ceci que le
shell lise un fichier (script) ou qu'il soit en interactif (dans une
fenêtre de Terminal).
Le caractère EOF étant en fait un control-D, c'est avec ce caractère que
tu peux terminer un shell, et même que tu dois normalement le terminer
(car les seuls signaux qu'accepte un shell sont ceux qu'on ne peut
détourner ; donc pour tuer un shell par signal , c'est kill -9)
Or il se trouve que lorsque ssh reçoit la fin de son processus fils
qu'est le shell, il se termine tout à fait normalement. Tu peux vérifier
avec top, après ^D, le process ssh a disparu. Et avec ktrace tu peux
voir que la terminaison est propre :
4467 ssh GIO fd 2 wrote 44 bytes
"Connection to ...... closed.r
"
4467 ssh RET write 44/0x2c
4467 ssh CALL shutdown(0x11,0x2)
4467 ssh RET shutdown 0
4467 ssh CALL close(0x11)
4467 ssh RET close 0
4467 ssh CALL exit(0)
Donc pour terminer un tunnel ssh, tu peux faire control-D.
Par contre ^C chez moi ne donne rien.
Et si tu n'utilises pas cette méthode, tu le termines comment ?...
Un tunnel ssh débouche sur un shell. Or la terminaison normale du shell
se fait quand il trouve le caractère EOF (end of file). Et ceci que le
shell lise un fichier (script) ou qu'il soit en interactif (dans une
fenêtre de Terminal).
Le caractère EOF étant en fait un control-D, c'est avec ce caractère que
tu peux terminer un shell, et même que tu dois normalement le terminer
(car les seuls signaux qu'accepte un shell sont ceux qu'on ne peut
détourner ; donc pour tuer un shell par signal , c'est kill -9)
Or il se trouve que lorsque ssh reçoit la fin de son processus fils
qu'est le shell, il se termine tout à fait normalement. Tu peux vérifier
avec top, après ^D, le process ssh a disparu. Et avec ktrace tu peux
voir que la terminaison est propre :
4467 ssh GIO fd 2 wrote 44 bytes
"Connection to ...... closed.r
"
4467 ssh RET write 44/0x2c
4467 ssh CALL shutdown(0x11,0x2)
4467 ssh RET shutdown 0
4467 ssh CALL close(0x11)
4467 ssh RET close 0
4467 ssh CALL exit(0)
Donc pour terminer un tunnel ssh, tu peux faire control-D.
Par contre ^C chez moi ne donne rien.
Tout s'effectue correctement comme tu le décris. La fenêtre terminal
s'ouvre et il suffit de taper le mot de passe de la machine où est
installé le server.
Cependant, je ne vois bien évidemment pas de différence de
fonctionnement entre l'utilisation de ce fameux tunnel et sans.
D'où les petites demandes de précisions suivantes.
- sur les machines à contrôler (toutes isolées, sans firewall actif),
aucun port à ouvrir, juste activer le service "session à distance" dans
le panneau partage ?
- je n'ai juste qu'à leur faire lancer Vine Server sur leur machine et,
quant à moi, initier la connexion SSH via le terminal par les commande
ou procèdure que tu as décrites ci-dessus ?
- une fois l'assistance terminée, arrêter moi-même leur serveur Vine,
puis stopper ma connexion SSH par un CTRL-D dans mon terminal ?
- pas de ports particuliers à "mapper" sur mon routeur/borne Airport et
je peux supprimer les 5900 et 550-5509 ?
J'ai tout bon ?
Autre petite question. Mon frère (en RE-ADSL chez Wanadoo) n'a pas d'IP
fixe et je l'ai donc inscrit à DynDNS (et installé le client qui va
bien). Je ne dispose pas d'IP pour lui, juste une adresse telle que
xxx.dyndns.org. Dans la commande...
ssh -R 5500:127.0.0.1:5500 , je tape quoi à la
place de ip_du_mac_serveur ?
Tout s'effectue correctement comme tu le décris. La fenêtre terminal
s'ouvre et il suffit de taper le mot de passe de la machine où est
installé le server.
Cependant, je ne vois bien évidemment pas de différence de
fonctionnement entre l'utilisation de ce fameux tunnel et sans.
D'où les petites demandes de précisions suivantes.
- sur les machines à contrôler (toutes isolées, sans firewall actif),
aucun port à ouvrir, juste activer le service "session à distance" dans
le panneau partage ?
- je n'ai juste qu'à leur faire lancer Vine Server sur leur machine et,
quant à moi, initier la connexion SSH via le terminal par les commande
ou procèdure que tu as décrites ci-dessus ?
- une fois l'assistance terminée, arrêter moi-même leur serveur Vine,
puis stopper ma connexion SSH par un CTRL-D dans mon terminal ?
- pas de ports particuliers à "mapper" sur mon routeur/borne Airport et
je peux supprimer les 5900 et 550-5509 ?
J'ai tout bon ?
Autre petite question. Mon frère (en RE-ADSL chez Wanadoo) n'a pas d'IP
fixe et je l'ai donc inscrit à DynDNS (et installé le client qui va
bien). Je ne dispose pas d'IP pour lui, juste une adresse telle que
xxx.dyndns.org. Dans la commande...
ssh -R 5500:127.0.0.1:5500 user@ip_du_mac_serveur, je tape quoi à la
place de ip_du_mac_serveur ?
Tout s'effectue correctement comme tu le décris. La fenêtre terminal
s'ouvre et il suffit de taper le mot de passe de la machine où est
installé le server.
Cependant, je ne vois bien évidemment pas de différence de
fonctionnement entre l'utilisation de ce fameux tunnel et sans.
D'où les petites demandes de précisions suivantes.
- sur les machines à contrôler (toutes isolées, sans firewall actif),
aucun port à ouvrir, juste activer le service "session à distance" dans
le panneau partage ?
- je n'ai juste qu'à leur faire lancer Vine Server sur leur machine et,
quant à moi, initier la connexion SSH via le terminal par les commande
ou procèdure que tu as décrites ci-dessus ?
- une fois l'assistance terminée, arrêter moi-même leur serveur Vine,
puis stopper ma connexion SSH par un CTRL-D dans mon terminal ?
- pas de ports particuliers à "mapper" sur mon routeur/borne Airport et
je peux supprimer les 5900 et 550-5509 ?
J'ai tout bon ?
Autre petite question. Mon frère (en RE-ADSL chez Wanadoo) n'a pas d'IP
fixe et je l'ai donc inscrit à DynDNS (et installé le client qui va
bien). Je ne dispose pas d'IP pour lui, juste une adresse telle que
xxx.dyndns.org. Dans la commande...
ssh -R 5500:127.0.0.1:5500 , je tape quoi à la
place de ip_du_mac_serveur ?
Tout s'effectue correctement comme tu le décris. La fenêtre terminal
s'ouvre et il suffit de taper le mot de passe de la machine où est
installé le server.
Cependant, je ne vois bien évidemment pas de différence de
fonctionnement entre l'utilisation de ce fameux tunnel et sans.
D'où les
petites demandes de précisions suivantes.
- sur les machines à contrôler (toutes isolées, sans firewall actif),
aucun port à ouvrir, juste activer le service "session à distance" dans
le panneau partage ?
- je n'ai juste qu'à leur faire lancer Vine Server sur leur machine
et,
quant à moi, initier la connexion SSH via le terminal par les commande
ou procèdure que tu as décrites ci-dessus ?
- une fois l'assistance terminée, arrêter moi-même leur serveur Vine,
puis stopper ma connexion SSH par un CTRL-D dans mon terminal ?
- pas de ports particuliers à "mapper" sur mon routeur/borne Airport et
je peux supprimer les 5900 et 5500-5509 ?
J'ai tout bon ?
Autre petite question. Mon frère (en RE-ADSL chez Wanadoo) n'a pas d'IP
fixe et je l'ai donc inscrit à DynDNS (et installé le client qui va
bien). Je ne dispose pas d'IP pour lui, juste une adresse telle que
xxx.dyndns.org. Dans la commande...
ssh -R 5500:127.0.0.1:5500 , je tape quoi à la
place de ip_du_mac_serveur ?
Tout s'effectue correctement comme tu le décris. La fenêtre terminal
s'ouvre et il suffit de taper le mot de passe de la machine où est
installé le server.
Cependant, je ne vois bien évidemment pas de différence de
fonctionnement entre l'utilisation de ce fameux tunnel et sans.
D'où les
petites demandes de précisions suivantes.
- sur les machines à contrôler (toutes isolées, sans firewall actif),
aucun port à ouvrir, juste activer le service "session à distance" dans
le panneau partage ?
- je n'ai juste qu'à leur faire lancer Vine Server sur leur machine
et,
quant à moi, initier la connexion SSH via le terminal par les commande
ou procèdure que tu as décrites ci-dessus ?
- une fois l'assistance terminée, arrêter moi-même leur serveur Vine,
puis stopper ma connexion SSH par un CTRL-D dans mon terminal ?
- pas de ports particuliers à "mapper" sur mon routeur/borne Airport et
je peux supprimer les 5900 et 5500-5509 ?
J'ai tout bon ?
Autre petite question. Mon frère (en RE-ADSL chez Wanadoo) n'a pas d'IP
fixe et je l'ai donc inscrit à DynDNS (et installé le client qui va
bien). Je ne dispose pas d'IP pour lui, juste une adresse telle que
xxx.dyndns.org. Dans la commande...
ssh -R 5500:127.0.0.1:5500 user@ip_du_mac_serveur, je tape quoi à la
place de ip_du_mac_serveur ?
Tout s'effectue correctement comme tu le décris. La fenêtre terminal
s'ouvre et il suffit de taper le mot de passe de la machine où est
installé le server.
Cependant, je ne vois bien évidemment pas de différence de
fonctionnement entre l'utilisation de ce fameux tunnel et sans.
D'où les
petites demandes de précisions suivantes.
- sur les machines à contrôler (toutes isolées, sans firewall actif),
aucun port à ouvrir, juste activer le service "session à distance" dans
le panneau partage ?
- je n'ai juste qu'à leur faire lancer Vine Server sur leur machine
et,
quant à moi, initier la connexion SSH via le terminal par les commande
ou procèdure que tu as décrites ci-dessus ?
- une fois l'assistance terminée, arrêter moi-même leur serveur Vine,
puis stopper ma connexion SSH par un CTRL-D dans mon terminal ?
- pas de ports particuliers à "mapper" sur mon routeur/borne Airport et
je peux supprimer les 5900 et 5500-5509 ?
J'ai tout bon ?
Autre petite question. Mon frère (en RE-ADSL chez Wanadoo) n'a pas d'IP
fixe et je l'ai donc inscrit à DynDNS (et installé le client qui va
bien). Je ne dispose pas d'IP pour lui, juste une adresse telle que
xxx.dyndns.org. Dans la commande...
ssh -R 5500:127.0.0.1:5500 , je tape quoi à la
place de ip_du_mac_serveur ?
Serge Horrent wrote:
Tu peux vérifier que ton tunnel est en fonctionnement en faisant dans le
Terminal
Serge Horrent <minfiu@free.fr.invalid> wrote:
Tu peux vérifier que ton tunnel est en fonctionnement en faisant dans le
Terminal
Serge Horrent wrote:
Tu peux vérifier que ton tunnel est en fonctionnement en faisant dans le
Terminal
Jacques t'as répondu en grande partie, mais
1) il utilise -L au lieu de -R pour le ssh
2) il t'as donné les réponses pour le cas où c'est toi qui "appelle"
ton correspondant alors que dans le script que tu vas recevoir ou que tu
as reçu par email je te propose le contraire.
Les réponses que je te donnent correspondent au cas de figure que je te
propose. Celles qu'il t'a donné à l'autre cas de figure
Jacques t'as répondu en grande partie, mais
1) il utilise -L au lieu de -R pour le ssh
2) il t'as donné les réponses pour le cas où c'est toi qui "appelle"
ton correspondant alors que dans le script que tu vas recevoir ou que tu
as reçu par email je te propose le contraire.
Les réponses que je te donnent correspondent au cas de figure que je te
propose. Celles qu'il t'a donné à l'autre cas de figure
Jacques t'as répondu en grande partie, mais
1) il utilise -L au lieu de -R pour le ssh
2) il t'as donné les réponses pour le cas où c'est toi qui "appelle"
ton correspondant alors que dans le script que tu vas recevoir ou que tu
as reçu par email je te propose le contraire.
Les réponses que je te donnent correspondent au cas de figure que je te
propose. Celles qu'il t'a donné à l'autre cas de figure