Pour la machine cliente :
soit un WinXP avec Cygwin+Package X ( les application X fonctionnent
très bien ).
soit un powerbook sous MacOS X 10.4.11 ( les applications X
fonctionnent très bien avec le serveur XDarwin ).
depuis l'une des machines clientes, je me connecte
ssh XX.XX.XX.XX -l user -X
export DISPLAY=localhost:10.0
xeyes &
X connection to localhost:10.0 broken (explicit kill or server shutdown).
alors j'essaie une autre méthode
xhost +localhost
Pour la machine cliente :
soit un WinXP avec Cygwin+Package X ( les application X fonctionnent
très bien ).
soit un powerbook sous MacOS X 10.4.11 ( les applications X
fonctionnent très bien avec le serveur XDarwin ).
depuis l'une des machines clientes, je me connecte
ssh XX.XX.XX.XX -l user -X
export DISPLAY=localhost:10.0
xeyes &
X connection to localhost:10.0 broken (explicit kill or server shutdown).
alors j'essaie une autre méthode
xhost +localhost
Pour la machine cliente :
soit un WinXP avec Cygwin+Package X ( les application X fonctionnent
très bien ).
soit un powerbook sous MacOS X 10.4.11 ( les applications X
fonctionnent très bien avec le serveur XDarwin ).
depuis l'une des machines clientes, je me connecte
ssh XX.XX.XX.XX -l user -X
export DISPLAY=localhost:10.0
xeyes &
X connection to localhost:10.0 broken (explicit kill or server shutdown).
alors j'essaie une autre méthode
xhost +localhost
À (at) Thu, 05 Mar 2009 16:08:40 +0100,
Jeannot Lelapin écrivait (wrote):Pour la machine cliente :
soit un WinXP avec Cygwin+Package X ( les application X fonctionnent
très bien ).
soit un powerbook sous MacOS X 10.4.11 ( les applications X
fonctionnent très bien avec le serveur XDarwin ).
depuis l'une des machines clientes, je me connecte
ssh XX.XX.XX.XX -l user -X
export DISPLAY=localhost:10.0
xeyes &
X connection to localhost:10.0 broken (explicit kill or server shutdown).
Si vous utilisez l'option -X (voire même -Y) de ssh, il ne *faut* pas
définir DISPLAY. C'est fait automagiquement par ssh (si tout se passe
bien). Si ça ne marche pas, essayez un 'ssh' en mode verbeux (de un à
trois '-v') pour essayer de comprendre quelle étape échoue.alors j'essaie une autre méthode
xhost +localhost
Si vous êtes sur un réseau complètement sécurisé, vous pouvez
évidemment utiliser 'xhost' mais dans ce cas, inutile de s'embêter
avec 'shh' puisque les échanges entre client et serveur X ne seront
pas chiffrés. Si votre réseau n'est pas complètement sécurisé, 'xhost'
est à proscrire.
À (at) Thu, 05 Mar 2009 16:08:40 +0100,
Jeannot Lelapin <jeannot.lelapin@free.fr> écrivait (wrote):
Pour la machine cliente :
soit un WinXP avec Cygwin+Package X ( les application X fonctionnent
très bien ).
soit un powerbook sous MacOS X 10.4.11 ( les applications X
fonctionnent très bien avec le serveur XDarwin ).
depuis l'une des machines clientes, je me connecte
ssh XX.XX.XX.XX -l user -X
export DISPLAY=localhost:10.0
xeyes &
X connection to localhost:10.0 broken (explicit kill or server shutdown).
Si vous utilisez l'option -X (voire même -Y) de ssh, il ne *faut* pas
définir DISPLAY. C'est fait automagiquement par ssh (si tout se passe
bien). Si ça ne marche pas, essayez un 'ssh' en mode verbeux (de un à
trois '-v') pour essayer de comprendre quelle étape échoue.
alors j'essaie une autre méthode
xhost +localhost
Si vous êtes sur un réseau complètement sécurisé, vous pouvez
évidemment utiliser 'xhost' mais dans ce cas, inutile de s'embêter
avec 'shh' puisque les échanges entre client et serveur X ne seront
pas chiffrés. Si votre réseau n'est pas complètement sécurisé, 'xhost'
est à proscrire.
À (at) Thu, 05 Mar 2009 16:08:40 +0100,
Jeannot Lelapin écrivait (wrote):Pour la machine cliente :
soit un WinXP avec Cygwin+Package X ( les application X fonctionnent
très bien ).
soit un powerbook sous MacOS X 10.4.11 ( les applications X
fonctionnent très bien avec le serveur XDarwin ).
depuis l'une des machines clientes, je me connecte
ssh XX.XX.XX.XX -l user -X
export DISPLAY=localhost:10.0
xeyes &
X connection to localhost:10.0 broken (explicit kill or server shutdown).
Si vous utilisez l'option -X (voire même -Y) de ssh, il ne *faut* pas
définir DISPLAY. C'est fait automagiquement par ssh (si tout se passe
bien). Si ça ne marche pas, essayez un 'ssh' en mode verbeux (de un à
trois '-v') pour essayer de comprendre quelle étape échoue.alors j'essaie une autre méthode
xhost +localhost
Si vous êtes sur un réseau complètement sécurisé, vous pouvez
évidemment utiliser 'xhost' mais dans ce cas, inutile de s'embêter
avec 'shh' puisque les échanges entre client et serveur X ne seront
pas chiffrés. Si votre réseau n'est pas complètement sécurisé, 'xhost'
est à proscrire.
si j'utilise seulement l'option -X pour la connection ssh : ssh
69.55.234.25 -l user -X
et que je lance xeyes & : voici le résultat :
==> Error: Can't open display:
je viens de lancer ssh 69.55.234.25 -l user -Y -vvv c'est assez
verbeux, tout se passe bien, je ne vois pas d'erreur ( je n'ai pas
non plus toutes les compétences ), ni sur un forward ni sur quoi que
ce soit.
Une fois connecté sur le serveur, si je lance les mêmes commandes, je
n'ai aucun message de debug de la part de sshd. C'est moche.
si j'utilise seulement l'option -X pour la connection ssh : ssh
69.55.234.25 -l user -X
et que je lance xeyes & : voici le résultat :
==> Error: Can't open display:
je viens de lancer ssh 69.55.234.25 -l user -Y -vvv c'est assez
verbeux, tout se passe bien, je ne vois pas d'erreur ( je n'ai pas
non plus toutes les compétences ), ni sur un forward ni sur quoi que
ce soit.
Une fois connecté sur le serveur, si je lance les mêmes commandes, je
n'ai aucun message de debug de la part de sshd. C'est moche.
si j'utilise seulement l'option -X pour la connection ssh : ssh
69.55.234.25 -l user -X
et que je lance xeyes & : voici le résultat :
==> Error: Can't open display:
je viens de lancer ssh 69.55.234.25 -l user -Y -vvv c'est assez
verbeux, tout se passe bien, je ne vois pas d'erreur ( je n'ai pas
non plus toutes les compétences ), ni sur un forward ni sur quoi que
ce soit.
Une fois connecté sur le serveur, si je lance les mêmes commandes, je
n'ai aucun message de debug de la part de sshd. C'est moche.
À (at) Thu, 05 Mar 2009 18:41:10 +0100,
Jeannot Lelapin écrivait (wrote):si j'utilise seulement l'option -X pour la connection ssh : ssh
69.55.234.25 -l user -X
et que je lance xeyes & : voici le résultat :
==> Error: Can't open display:
Donc le X11 forwarding ne fonctionne pas. Inutile de tester avec '-Y'
qui ne change que le niveau de confiance que le serveur X11 accorde
aux clients.
je viens de lancer ssh 69.55.234.25 -l user -Y -vvv c'est assez
verbeux, tout se passe bien, je ne vois pas d'erreur ( je n'ai pas
non plus toutes les compétences ), ni sur un forward ni sur quoi que
ce soit.
Le niveau 2 de debug (avec -vv) devrait suffire. À un moment, il doit
y avoir un ou plusieurs messages concernant X11. Sur une connexion ssh
avec un X11 forwarding qui se passe bien, voici une sortie typique ;
debug2: x11_get_proto: /usr/bin/X11/xauth list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
C'est à ce niveau qu'on doit pouvoir détecter une différence...
Une fois connecté sur le serveur, si je lance les mêmes commandes, je
n'ai aucun message de debug de la part de sshd. C'est moche.
Je ne comprends pas ce que vous voulez dire par "sur le serveur, si je
lance les mêmes commandes".
P.S. : ne suivez certainement pas la recommandation qui vous a été
donnée sur le newsgroup BSD anglophone consistant à activer l'écoute
de serveur X11 sur tcp. Comme l'utilisation de 'xhost', ça ne sert à
rien et c'est un trou de sécurité potentiel.
P.S. 2 : évitez de poster plusieurs fois le même message sur
différents newsgroups (le multiposting). Préférez le crossposting avec
un follow-up adapté...
À (at) Thu, 05 Mar 2009 18:41:10 +0100,
Jeannot Lelapin <jeannot.lelapin@free.fr> écrivait (wrote):
si j'utilise seulement l'option -X pour la connection ssh : ssh
69.55.234.25 -l user -X
et que je lance xeyes & : voici le résultat :
==> Error: Can't open display:
Donc le X11 forwarding ne fonctionne pas. Inutile de tester avec '-Y'
qui ne change que le niveau de confiance que le serveur X11 accorde
aux clients.
je viens de lancer ssh 69.55.234.25 -l user -Y -vvv c'est assez
verbeux, tout se passe bien, je ne vois pas d'erreur ( je n'ai pas
non plus toutes les compétences ), ni sur un forward ni sur quoi que
ce soit.
Le niveau 2 de debug (avec -vv) devrait suffire. À un moment, il doit
y avoir un ou plusieurs messages concernant X11. Sur une connexion ssh
avec un X11 forwarding qui se passe bien, voici une sortie typique ;
debug2: x11_get_proto: /usr/bin/X11/xauth list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
C'est à ce niveau qu'on doit pouvoir détecter une différence...
Une fois connecté sur le serveur, si je lance les mêmes commandes, je
n'ai aucun message de debug de la part de sshd. C'est moche.
Je ne comprends pas ce que vous voulez dire par "sur le serveur, si je
lance les mêmes commandes".
P.S. : ne suivez certainement pas la recommandation qui vous a été
donnée sur le newsgroup BSD anglophone consistant à activer l'écoute
de serveur X11 sur tcp. Comme l'utilisation de 'xhost', ça ne sert à
rien et c'est un trou de sécurité potentiel.
P.S. 2 : évitez de poster plusieurs fois le même message sur
différents newsgroups (le multiposting). Préférez le crossposting avec
un follow-up adapté...
À (at) Thu, 05 Mar 2009 18:41:10 +0100,
Jeannot Lelapin écrivait (wrote):si j'utilise seulement l'option -X pour la connection ssh : ssh
69.55.234.25 -l user -X
et que je lance xeyes & : voici le résultat :
==> Error: Can't open display:
Donc le X11 forwarding ne fonctionne pas. Inutile de tester avec '-Y'
qui ne change que le niveau de confiance que le serveur X11 accorde
aux clients.
je viens de lancer ssh 69.55.234.25 -l user -Y -vvv c'est assez
verbeux, tout se passe bien, je ne vois pas d'erreur ( je n'ai pas
non plus toutes les compétences ), ni sur un forward ni sur quoi que
ce soit.
Le niveau 2 de debug (avec -vv) devrait suffire. À un moment, il doit
y avoir un ou plusieurs messages concernant X11. Sur une connexion ssh
avec un X11 forwarding qui se passe bien, voici une sortie typique ;
debug2: x11_get_proto: /usr/bin/X11/xauth list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
C'est à ce niveau qu'on doit pouvoir détecter une différence...
Une fois connecté sur le serveur, si je lance les mêmes commandes, je
n'ai aucun message de debug de la part de sshd. C'est moche.
Je ne comprends pas ce que vous voulez dire par "sur le serveur, si je
lance les mêmes commandes".
P.S. : ne suivez certainement pas la recommandation qui vous a été
donnée sur le newsgroup BSD anglophone consistant à activer l'écoute
de serveur X11 sur tcp. Comme l'utilisation de 'xhost', ça ne sert à
rien et c'est un trou de sécurité potentiel.
P.S. 2 : évitez de poster plusieurs fois le même message sur
différents newsgroups (le multiposting). Préférez le crossposting avec
un follow-up adapté...
Il n'a aucune ligne correspondant à X11. Rien, nada.
Le programme /usr/bin/X11/xauth est exécutée sur la machine distante (
tourant sous FreeBSD ) ou sur ma machine locale ( PowerBook sous MacOS
)?
Désolé, pour moi le serveur est la machine distante ( sous FreeBSD ),
alors que c'est sur ma machine locale ( Powerbook sous MacOs ) que
tourne le fameux server X XDarwin.
J'ai compris qu'il ne fallait pas enlever l'option -nolisten tcp ( de
toute façon, je ne l'ai jamais trouvé dans les fichiers de
configuration du XDarwin ).
Et xhost, je ne m'en servirai plus mais en désespoir de cause depuis
une semaine, je commençais à essayer tout et n'importe quoi.
P.S. 2 : évitez de poster plusieurs fois le même message sur
différents newsgroups (le multiposting). Préférez le crossposting avec
un follow-up adapté...
Est-ce réglo de faire un message à destination de plusieurs newsgroup
? Il y a longtemps, on m'avait reproché un message à destination de
plusieurs newsgroup, alors je n'avais plus recommencer. Mais mon sujet
touche à peu à tout, c'est pour cette raison que j'ai demandé un peu
partout.
Il n'a aucune ligne correspondant à X11. Rien, nada.
Le programme /usr/bin/X11/xauth est exécutée sur la machine distante (
tourant sous FreeBSD ) ou sur ma machine locale ( PowerBook sous MacOS
)?
Désolé, pour moi le serveur est la machine distante ( sous FreeBSD ),
alors que c'est sur ma machine locale ( Powerbook sous MacOs ) que
tourne le fameux server X XDarwin.
J'ai compris qu'il ne fallait pas enlever l'option -nolisten tcp ( de
toute façon, je ne l'ai jamais trouvé dans les fichiers de
configuration du XDarwin ).
Et xhost, je ne m'en servirai plus mais en désespoir de cause depuis
une semaine, je commençais à essayer tout et n'importe quoi.
P.S. 2 : évitez de poster plusieurs fois le même message sur
différents newsgroups (le multiposting). Préférez le crossposting avec
un follow-up adapté...
Est-ce réglo de faire un message à destination de plusieurs newsgroup
? Il y a longtemps, on m'avait reproché un message à destination de
plusieurs newsgroup, alors je n'avais plus recommencer. Mais mon sujet
touche à peu à tout, c'est pour cette raison que j'ai demandé un peu
partout.
Il n'a aucune ligne correspondant à X11. Rien, nada.
Le programme /usr/bin/X11/xauth est exécutée sur la machine distante (
tourant sous FreeBSD ) ou sur ma machine locale ( PowerBook sous MacOS
)?
Désolé, pour moi le serveur est la machine distante ( sous FreeBSD ),
alors que c'est sur ma machine locale ( Powerbook sous MacOs ) que
tourne le fameux server X XDarwin.
J'ai compris qu'il ne fallait pas enlever l'option -nolisten tcp ( de
toute façon, je ne l'ai jamais trouvé dans les fichiers de
configuration du XDarwin ).
Et xhost, je ne m'en servirai plus mais en désespoir de cause depuis
une semaine, je commençais à essayer tout et n'importe quoi.
P.S. 2 : évitez de poster plusieurs fois le même message sur
différents newsgroups (le multiposting). Préférez le crossposting avec
un follow-up adapté...
Est-ce réglo de faire un message à destination de plusieurs newsgroup
? Il y a longtemps, on m'avait reproché un message à destination de
plusieurs newsgroup, alors je n'avais plus recommencer. Mais mon sujet
touche à peu à tout, c'est pour cette raison que j'ai demandé un peu
partout.
À (at) Thu, 05 Mar 2009 22:39:08 +0100,
Jeannot Lelapin écrivait (wrote):Il n'a aucune ligne correspondant à X11. Rien, nada.
Le programme /usr/bin/X11/xauth est exécutée sur la machine distante (
tourant sous FreeBSD ) ou sur ma machine locale ( PowerBook sous MacOS
)?
La commande 'xauth' est exécutée du côté du serveur X11 pour récupérer
le MAGIC-COOKIE permettant de s'identifier.
Il faut tester sur votre serveur X11 si la commande suivante retourne
quelque chose :
% xauth list $DISPLAY
Si ce n'est pas le cas ou, pire, si la commande n'existe pas, c'est
une raison de l'échec du X11 forwarding.
Je pense aussi à un autre problème potentiel encore plus
basique. Votre variable DISPLAY est-elle définie dans le terminal
depuis lequel vous essayez de lancer le 'ssh -X' ?
À (at) Thu, 05 Mar 2009 22:39:08 +0100,
Jeannot Lelapin <jeannot.lelapin@free.fr> écrivait (wrote):
Il n'a aucune ligne correspondant à X11. Rien, nada.
Le programme /usr/bin/X11/xauth est exécutée sur la machine distante (
tourant sous FreeBSD ) ou sur ma machine locale ( PowerBook sous MacOS
)?
La commande 'xauth' est exécutée du côté du serveur X11 pour récupérer
le MAGIC-COOKIE permettant de s'identifier.
Il faut tester sur votre serveur X11 si la commande suivante retourne
quelque chose :
% xauth list $DISPLAY
Si ce n'est pas le cas ou, pire, si la commande n'existe pas, c'est
une raison de l'échec du X11 forwarding.
Je pense aussi à un autre problème potentiel encore plus
basique. Votre variable DISPLAY est-elle définie dans le terminal
depuis lequel vous essayez de lancer le 'ssh -X' ?
À (at) Thu, 05 Mar 2009 22:39:08 +0100,
Jeannot Lelapin écrivait (wrote):Il n'a aucune ligne correspondant à X11. Rien, nada.
Le programme /usr/bin/X11/xauth est exécutée sur la machine distante (
tourant sous FreeBSD ) ou sur ma machine locale ( PowerBook sous MacOS
)?
La commande 'xauth' est exécutée du côté du serveur X11 pour récupérer
le MAGIC-COOKIE permettant de s'identifier.
Il faut tester sur votre serveur X11 si la commande suivante retourne
quelque chose :
% xauth list $DISPLAY
Si ce n'est pas le cas ou, pire, si la commande n'existe pas, c'est
une raison de l'échec du X11 forwarding.
Je pense aussi à un autre problème potentiel encore plus
basique. Votre variable DISPLAY est-elle définie dans le terminal
depuis lequel vous essayez de lancer le 'ssh -X' ?
Bonjour et encore merci,
Enorme boulette, le DISPLAY n'est pas défini dans le terminal Macos
dans lequel je lance le ssh
une fois connecté sur FreeBSD.IP
echo $DISPLAY
localhost:10.0
Ouf, on avance !!
mais
xeyes &
==>>
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from FreeBSD.IP 58277
debug2: fd 7 setting O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
$ debug2: X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.
debug2: X11 rejected 1 i0/o0
Ce serait une erreur de protocole ? mais lequel et qui sert à quoi ?
Bonjour et encore merci,
Enorme boulette, le DISPLAY n'est pas défini dans le terminal Macos
dans lequel je lance le ssh
une fois connecté sur FreeBSD.IP
echo $DISPLAY
localhost:10.0
Ouf, on avance !!
mais
xeyes &
==>>
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from FreeBSD.IP 58277
debug2: fd 7 setting O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
$ debug2: X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.
debug2: X11 rejected 1 i0/o0
Ce serait une erreur de protocole ? mais lequel et qui sert à quoi ?
Bonjour et encore merci,
Enorme boulette, le DISPLAY n'est pas défini dans le terminal Macos
dans lequel je lance le ssh
une fois connecté sur FreeBSD.IP
echo $DISPLAY
localhost:10.0
Ouf, on avance !!
mais
xeyes &
==>>
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from FreeBSD.IP 58277
debug2: fd 7 setting O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
$ debug2: X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.
debug2: X11 rejected 1 i0/o0
Ce serait une erreur de protocole ? mais lequel et qui sert à quoi ?
Si je me souviens bien, dans XDarwin, il faut aller dans les
préférences activer les 'authentification' (je me souviens plus
exactement des termes) puis relancer XDarwin...
Si je me souviens bien, dans XDarwin, il faut aller dans les
préférences activer les 'authentification' (je me souviens plus
exactement des termes) puis relancer XDarwin...
Si je me souviens bien, dans XDarwin, il faut aller dans les
préférences activer les 'authentification' (je me souviens plus
exactement des termes) puis relancer XDarwin...
À (at) Fri, 06 Mar 2009 14:29:49 +0100,
Paul Gaborit écrivait (wrote):Si je me souviens bien, dans XDarwin, il faut aller dans les
préférences activer les 'authentification' (je me souviens plus
exactement des termes) puis relancer XDarwin...
Et c'est une mauvaise piste (je viens d'essayer et ici, ça marche avec
ou sans l'authentication de XDarwin...
À (at) Fri, 06 Mar 2009 14:29:49 +0100,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):
Si je me souviens bien, dans XDarwin, il faut aller dans les
préférences activer les 'authentification' (je me souviens plus
exactement des termes) puis relancer XDarwin...
Et c'est une mauvaise piste (je viens d'essayer et ici, ça marche avec
ou sans l'authentication de XDarwin...
À (at) Fri, 06 Mar 2009 14:29:49 +0100,
Paul Gaborit écrivait (wrote):Si je me souviens bien, dans XDarwin, il faut aller dans les
préférences activer les 'authentification' (je me souviens plus
exactement des termes) puis relancer XDarwin...
Et c'est une mauvaise piste (je viens d'essayer et ici, ça marche avec
ou sans l'authentication de XDarwin...