J'ai essayé, ça n'a utiliser ni ssh ni de cryptage SSL.
OK. J'avais activé l'option et tentéd une connexion sur un serveur SFM, (Win2000) la connexion ne dépassait pas le dialogue d'identification. Donc ça semblait tout de même faire quelque chose. En fait, le serveur en question avait des petits problèmes de virus tout à l'heure, maintenant ça fonctionne aussi.
Ça fonctionne, oui, mais est-ce crypté ?
-- Schmurtz
En tout cas, c'est pas encore fonctionnel.
Tu tiens cette info d'où ?
J'ai essayé, ça n'a utiliser ni ssh ni de cryptage SSL.
OK. J'avais activé l'option et tentéd une connexion sur un serveur SFM,
(Win2000) la connexion ne dépassait pas le dialogue d'identification.
Donc ça semblait tout de même faire quelque chose. En fait, le serveur
en question avait des petits problèmes de virus tout à l'heure,
maintenant ça fonctionne aussi.
J'ai essayé, ça n'a utiliser ni ssh ni de cryptage SSL.
OK. J'avais activé l'option et tentéd une connexion sur un serveur SFM, (Win2000) la connexion ne dépassait pas le dialogue d'identification. Donc ça semblait tout de même faire quelque chose. En fait, le serveur en question avait des petits problèmes de virus tout à l'heure, maintenant ça fonctionne aussi.
Ça fonctionne, oui, mais est-ce crypté ?
-- Schmurtz
Patrick Stadelmann
In article <bjjb4n$sdv$, Schmurtz wrote:
Ça fonctionne, oui, mais est-ce crypté ?
Ca, c'est la grande question. Faudrait regarder le contenu des paquets pour voir si c'est le cas.
Patrick -- Patrick Stadelmann
In article <bjjb4n$sdv$17@news.polytechnique.fr>,
Schmurtz <moi@ici.com> wrote:
Ça fonctionne, oui, mais est-ce crypté ?
Ca, c'est la grande question. Faudrait regarder le contenu des paquets
pour voir si c'est le cas.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Ca, c'est la grande question. Faudrait regarder le contenu des paquets pour voir si c'est le cas.
Patrick -- Patrick Stadelmann
Jacques Perrocheau
In article (Dans l'article) , Patrick Stadelmann wrote (écrivait) :
Si l'option est activée et que l'on se connecte à un serveur NT avec les SFM activé, on n'arrive pas à se logguer (après avoir donné son nom et mot de passe, il y a une barre de progression sans fin).
En fait ça fontionne aussi avec SFM, le serveur qui m'a servi de cobaye tout à l'heure avait un problème.
Oui, mais dans ce cas tu n'utilises pas MS UAM 5.0.11 qui dans sa version X prend la main sans laisser le choix comme le faisait la version 9 ?
-- 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
In article (Dans l'article)
<Patrick.Stadelmann-20E479.20574908092003@news.fu-berlin.de>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote (écrivait) :
Si l'option est activée et que l'on se connecte à un serveur NT avec les
SFM activé, on n'arrive pas à se logguer (après avoir donné son nom et
mot de passe, il y a une barre de progression sans fin).
En fait ça fontionne aussi avec SFM, le serveur qui m'a servi de cobaye
tout à l'heure avait un problème.
Oui, mais dans ce cas tu n'utilises pas MS UAM 5.0.11 qui dans sa
version X prend la main sans laisser le choix comme le faisait la
version 9 ?
--
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
In article (Dans l'article) , Patrick Stadelmann wrote (écrivait) :
Si l'option est activée et que l'on se connecte à un serveur NT avec les SFM activé, on n'arrive pas à se logguer (après avoir donné son nom et mot de passe, il y a une barre de progression sans fin).
En fait ça fontionne aussi avec SFM, le serveur qui m'a servi de cobaye tout à l'heure avait un problème.
Oui, mais dans ce cas tu n'utilises pas MS UAM 5.0.11 qui dans sa version X prend la main sans laisser le choix comme le faisait la version 9 ?
-- 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
Patrick Stadelmann
In article <bjkfrv$sd4$, Jacques Perrocheau wrote:
Oui, mais dans ce cas tu n'utilises pas MS UAM 5.0.11 qui dans sa version X prend la main sans laisser le choix comme le faisait la version 9 ?
En effet je n'avais pas MS-UAM activé quand j'ai fait le test.
Patrick -- Patrick Stadelmann
In article <bjkfrv$sd4$1@news.univ-rennes1.fr>,
Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> wrote:
Oui, mais dans ce cas tu n'utilises pas MS UAM 5.0.11 qui dans sa
version X prend la main sans laisser le choix comme le faisait la
version 9 ?
En effet je n'avais pas MS-UAM activé quand j'ai fait le test.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <bjkfrv$sd4$, Jacques Perrocheau wrote:
Oui, mais dans ce cas tu n'utilises pas MS UAM 5.0.11 qui dans sa version X prend la main sans laisser le choix comme le faisait la version 9 ?
En effet je n'avais pas MS-UAM activé quand j'ai fait le test.
Patrick -- Patrick Stadelmann
Jacques Perrocheau
In article , Patrick Stadelmann wrote:
In article <bjjb4n$sdv$, Schmurtz wrote:
Ça fonctionne, oui, mais est-ce crypté ?
Ca, c'est la grande question. Faudrait regarder le contenu des paquets pour voir si c'est le cas.
Si je coche cette option et je monte un volume AppleShare d'une machine sous OS X 10.2.6, je récupére une entrée dans le fichier ~/.ssh/known_host. AMA, pas de confusion possible j'ai fait la manip avec une machine où le nom AppleTalk est différent du nom IP. J'ai d'ailleurs une autre entrée pour le nom IP et numéro IP dans la liste.
Qu'est-ce qui est crypté exactement... tout ou le mot de passe seulement ? that's the question.
-- 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
In article
<Patrick.Stadelmann-FA3363.22025508092003@news.fu-berlin.de>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
In article <bjjb4n$sdv$17@news.polytechnique.fr>,
Schmurtz <moi@ici.com> wrote:
Ça fonctionne, oui, mais est-ce crypté ?
Ca, c'est la grande question. Faudrait regarder le contenu des paquets
pour voir si c'est le cas.
Si je coche cette option et je monte un volume AppleShare d'une machine
sous OS X 10.2.6, je récupére une entrée dans le fichier
~/.ssh/known_host. AMA, pas de confusion possible j'ai fait la manip
avec une machine où le nom AppleTalk est différent du nom IP. J'ai
d'ailleurs une autre entrée pour le nom IP et numéro IP dans la liste.
Qu'est-ce qui est crypté exactement... tout ou le mot de passe
seulement ? that's the question.
--
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
Ca, c'est la grande question. Faudrait regarder le contenu des paquets pour voir si c'est le cas.
Si je coche cette option et je monte un volume AppleShare d'une machine sous OS X 10.2.6, je récupére une entrée dans le fichier ~/.ssh/known_host. AMA, pas de confusion possible j'ai fait la manip avec une machine où le nom AppleTalk est différent du nom IP. J'ai d'ailleurs une autre entrée pour le nom IP et numéro IP dans la liste.
Qu'est-ce qui est crypté exactement... tout ou le mot de passe seulement ? that's the question.
-- 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
jperrocheau
Patrick Stadelmann wrote:
Qu'est-ce qui est crypté exactement... tout ou le mot de passe seulement ? that's the question.
Logiquement, ça devrait être tout (vu que le mot de passe l'est déjà en temps normal). Je vais regarder en détail à l'occasion.
Si je coche cette option et je monte un volume AppleShare d'une machine sous OS X 10.2.6, je récupére une entrée dans le fichier ~/.ssh/known_host. AMA, pas de confusion possible j'ai fait la manip avec une machine où le nom AppleTalk est différent du nom IP. J'ai d'ailleurs une autre entrée pour le nom IP et numéro IP dans la liste.
Je serais peut-être moins affirmatif, parce que sur cette machine, le nom RendezVous est identique au nom AppleTalk. Mais ce qui est surprenant c'est que dans l'entrée du fichier known_host, le numéro IP n'est pas repris, or il me semble bien, RendezVous est fondé sur TCP/IP... non ?
-- Jacques PERROCHEAU ______________________________________________________________ e-mail: mailto:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Qu'est-ce qui est crypté exactement... tout ou le mot de passe
seulement ? that's the question.
Logiquement, ça devrait être tout (vu que le mot de passe l'est déjà en
temps normal). Je vais regarder en détail à l'occasion.
Si je coche cette option et je monte un volume AppleShare d'une machine
sous OS X 10.2.6, je récupére une entrée dans le fichier
~/.ssh/known_host. AMA, pas de confusion possible j'ai fait la manip
avec une machine où le nom AppleTalk est différent du nom IP. J'ai
d'ailleurs une autre entrée pour le nom IP et numéro IP dans la liste.
Je serais peut-être moins affirmatif, parce que sur cette machine, le
nom RendezVous est identique au nom AppleTalk. Mais ce qui est
surprenant c'est que dans l'entrée du fichier known_host, le numéro IP
n'est pas repris, or il me semble bien, RendezVous est fondé sur
TCP/IP... non ?
--
Jacques PERROCHEAU
______________________________________________________________
e-mail: mailto:jperrocheau@mac.com
Qu'est-ce qui est crypté exactement... tout ou le mot de passe seulement ? that's the question.
Logiquement, ça devrait être tout (vu que le mot de passe l'est déjà en temps normal). Je vais regarder en détail à l'occasion.
Si je coche cette option et je monte un volume AppleShare d'une machine sous OS X 10.2.6, je récupére une entrée dans le fichier ~/.ssh/known_host. AMA, pas de confusion possible j'ai fait la manip avec une machine où le nom AppleTalk est différent du nom IP. J'ai d'ailleurs une autre entrée pour le nom IP et numéro IP dans la liste.
Je serais peut-être moins affirmatif, parce que sur cette machine, le nom RendezVous est identique au nom AppleTalk. Mais ce qui est surprenant c'est que dans l'entrée du fichier known_host, le numéro IP n'est pas repris, or il me semble bien, RendezVous est fondé sur TCP/IP... non ?
-- Jacques PERROCHEAU ______________________________________________________________ e-mail: mailto:
Schmurtz
Si je coche cette option et je monte un volume AppleShare d'une machine sous OS X 10.2.6, je récupére une entrée dans le fichier ~/.ssh/known_host. AMA, pas de confusion possible j'ai fait la manip avec une machine où le nom AppleTalk est différent du nom IP. J'ai d'ailleurs une autre entrée pour le nom IP et numéro IP dans la liste.
Je vais réessayer alors, en écoutant le traffic tcp pour vérifier que c'est bien crypté. Il suffit de faire un "tcpdump tcp" pour tout d'abord voir quels ports sont utilisés (afpovertcp et ssh normalement, soit 548 et 22) puis ensuite un "tcmpdump -X -s 1000 tcp port xx or tcp port xx or " pour n'écouter que les ports xx. Si c'est crypté, on ne voit rien, si ça ne l'est pas, on voit au moins les noms des dossiers et fichiers.
Je serais peut-être moins affirmatif, parce que sur cette machine, le nom RendezVous est identique au nom AppleTalk. Mais ce qui est surprenant c'est que dans l'entrée du fichier known_host, le numéro IP n'est pas repris, or il me semble bien, RendezVous est fondé sur TCP/IP... non ?
Si AppleShare utilise ssh, il n'y a aucune raison que ce soit AppleShare qui écrit dns le fichier know_host, c'est sûrement ssh qui s'en occupe.
-- Schmurtz
Si je coche cette option et je monte un volume AppleShare d'une machine
sous OS X 10.2.6, je récupére une entrée dans le fichier
~/.ssh/known_host. AMA, pas de confusion possible j'ai fait la manip
avec une machine où le nom AppleTalk est différent du nom IP. J'ai
d'ailleurs une autre entrée pour le nom IP et numéro IP dans la liste.
Je vais réessayer alors, en écoutant le traffic tcp pour vérifier que
c'est bien crypté. Il suffit de faire un "tcpdump tcp" pour tout d'abord
voir quels ports sont utilisés (afpovertcp et ssh normalement, soit 548
et 22) puis ensuite un "tcmpdump -X -s 1000 tcp port xx or tcp port xx
or " pour n'écouter que les ports xx. Si c'est crypté, on ne voit rien,
si ça ne l'est pas, on voit au moins les noms des dossiers et fichiers.
Je serais peut-être moins affirmatif, parce que sur cette machine, le
nom RendezVous est identique au nom AppleTalk. Mais ce qui est
surprenant c'est que dans l'entrée du fichier known_host, le numéro IP
n'est pas repris, or il me semble bien, RendezVous est fondé sur
TCP/IP... non ?
Si AppleShare utilise ssh, il n'y a aucune raison que ce soit AppleShare
qui écrit dns le fichier know_host, c'est sûrement ssh qui s'en occupe.
Si je coche cette option et je monte un volume AppleShare d'une machine sous OS X 10.2.6, je récupére une entrée dans le fichier ~/.ssh/known_host. AMA, pas de confusion possible j'ai fait la manip avec une machine où le nom AppleTalk est différent du nom IP. J'ai d'ailleurs une autre entrée pour le nom IP et numéro IP dans la liste.
Je vais réessayer alors, en écoutant le traffic tcp pour vérifier que c'est bien crypté. Il suffit de faire un "tcpdump tcp" pour tout d'abord voir quels ports sont utilisés (afpovertcp et ssh normalement, soit 548 et 22) puis ensuite un "tcmpdump -X -s 1000 tcp port xx or tcp port xx or " pour n'écouter que les ports xx. Si c'est crypté, on ne voit rien, si ça ne l'est pas, on voit au moins les noms des dossiers et fichiers.
Je serais peut-être moins affirmatif, parce que sur cette machine, le nom RendezVous est identique au nom AppleTalk. Mais ce qui est surprenant c'est que dans l'entrée du fichier known_host, le numéro IP n'est pas repris, or il me semble bien, RendezVous est fondé sur TCP/IP... non ?
Si AppleShare utilise ssh, il n'y a aucune raison que ce soit AppleShare qui écrit dns le fichier know_host, c'est sûrement ssh qui s'en occupe.
