X11, affichage déporté... autres question de béotien
60 réponses
Jacques Perrocheau
Bonjour,
Enhardi par mes nouvelles connaissances en affichage déporté
d'application Xwindow, je me suis dis que je pouvais aussi faire des
tests et me faire la main en X11 déporté entre deux Mac OS 10.3.7 sur
lesquels X11 a été installé. Eh! bien ça ne marche pas...
Après avoir dans xterm tapé la commande magique:
ssh -X toto@LaMachine
puis xlogo ou xclock, j'ai droit à un:
Error: Can't open display:
Ai-je loupé une marche ou est-ce "normal" ? Chacun a bien vu que mes
connaissances en Xwindow étaient "minimales".
Je précise que le X11 de la machine sur laquelle je suis fonctionne
toujours normalement en local et même en distant vers la précédente
machine Linux où je faisais "mes essais".
Merci pour vos avis toujours éclairés ;).
--
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
Mais le xhost + permet d'espionner avec une machine SURE !
par machine "sure" je veux dire "machine où seul des utilisateurs connus et vis à vis desquels ce que je fais dans X11 n'est pas confidentiel peuvent se connecter".
Ben oui mais comment peux tu savoir qu'ils n'ont pas perdu leur mot de passe ou se le sont fait voler.
Les piratages se font souvent par rebonds : je prend l'info de A pour via B toucher C... Ceux que j'ai vu se sont TOUJOURS déroulés par des délégations de confiance comme celle que tu accordes.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> writes:
In article <uxbrbvjbgo.fsf@enseirb.fr>, FiLH <filh@filh.org> wrote:
Mais le xhost + permet d'espionner avec une machine SURE !
par machine "sure" je veux dire "machine où seul des utilisateurs connus
et vis à vis desquels ce que je fais dans X11 n'est pas confidentiel
peuvent se connecter".
Ben oui mais comment peux tu savoir qu'ils n'ont pas perdu leur mot de
passe ou se le sont fait voler.
Les piratages se font souvent par rebonds : je prend l'info de A pour
via B toucher C... Ceux que j'ai vu se sont TOUJOURS déroulés par des
délégations de confiance comme celle que tu accordes.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Mais le xhost + permet d'espionner avec une machine SURE !
par machine "sure" je veux dire "machine où seul des utilisateurs connus et vis à vis desquels ce que je fais dans X11 n'est pas confidentiel peuvent se connecter".
Ben oui mais comment peux tu savoir qu'ils n'ont pas perdu leur mot de passe ou se le sont fait voler.
Les piratages se font souvent par rebonds : je prend l'info de A pour via B toucher C... Ceux que j'ai vu se sont TOUJOURS déroulés par des délégations de confiance comme celle que tu accordes.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
FiLH
Martin Costabel writes:
Ensuite, "ssh -X machine.distante" va réussir.
Devrait, devrait...
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Martin Costabel <costabel@wanadoo.fr> writes:
Ensuite, "ssh -X machine.distante" va réussir.
Devrait, devrait...
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Jacques Perrocheau
In article <41e404dc$0$31781$, YBM wrote:
non, non et triple non ! Il faut laisser ssh et sshd négocier et positionner cette variable, le "10" ne tombe pas du ciel.
cf la page de manuel de ssh :
X11 and TCP forwarding [snip].
ce localhost:10 (ou 11, 12, etc) fait passer le traffic X11 à travers un tunel crypté entre le client ssh et le serveur sshd. Le client ssh utilise kerberos (xauth) pour obtenir les droits d'accès au serveur X local et lui transmet le traffic X11 qu'il reçoit du serveur sshd à travers le tunnel ssh.
Avec xhost +mamachine (qui d'ailleurs ne marche pas avec les configurations sécurisées du serveur X) il y a deux problèmes :
- on autorise *tout* utilisateur de la machine à accéder au serveur X (affichage *et* clavier !) - le traffic X11 se fait en clair à travers le réseau, on peut capturer les évènements du clavier, etc.
ça doit être activé dans sshd_config (X11Forwarding yes) et peut être rendu automatique du côté client (plus besoin de '-X') dans ssh_config (ForwardX11 yes).
Je continue le fil de ma question ici... parce que pour suivre vos débats dans le reste de l'enfilade ce n'est pas évident ;)
Merci pour la solution de mon pb. Cela marche.
Je résume pour les newbies.
Pour faire de l'affichage déporté en tunnel ssh entre deux Mac OS 10.3.x avec X11 installé tel que sorti du carton, il faut effectivement dans le sshd_config de la machine cible mettre:
X11Forwarding yes X11DisplayOffset 10
En fait les décommenter et mettre la première ligne à "yes". J'ai aussi décommenté la deuxième ligne ce qui ne me paraissait pas... "idiot".
Voilà le résultat:
mac-àmoi:~ moi$ ssh -X 's password: Last login: Wed Jan 12 14:14:15 2005 Welcome to Darwin! mac-Lamachinecible:~ toto$ echo $DISPLAY localhost:10.0 mac-Lamachinecible:~ toto$ xlogo& mac-Lamachinecible:~ toto$ xclock&
-- 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 <41e404dc$0$31781$626a14ce@news.free.fr>,
YBM <ybmess@nooos.fr> wrote:
non, non et triple non ! Il faut laisser ssh et sshd négocier et
positionner cette variable, le "10" ne tombe pas du ciel.
cf la page de manuel de ssh :
X11 and TCP forwarding
[snip].
ce localhost:10 (ou 11, 12, etc) fait passer le traffic X11
à travers un tunel crypté entre le client ssh et le serveur
sshd. Le client ssh utilise kerberos (xauth) pour obtenir
les droits d'accès au serveur X local et lui transmet le
traffic X11 qu'il reçoit du serveur sshd à travers le
tunnel ssh.
Avec xhost +mamachine (qui d'ailleurs ne marche pas avec les
configurations sécurisées du serveur X) il y a deux problèmes :
- on autorise *tout* utilisateur de la machine à accéder au
serveur X (affichage *et* clavier !)
- le traffic X11 se fait en clair à travers le réseau, on peut
capturer les évènements du clavier, etc.
ça doit être activé dans sshd_config (X11Forwarding yes) et
peut être rendu automatique du côté client (plus besoin de '-X') dans
ssh_config (ForwardX11 yes).
Je continue le fil de ma question ici... parce que pour suivre vos
débats dans le reste de l'enfilade ce n'est pas évident ;)
Merci pour la solution de mon pb. Cela marche.
Je résume pour les newbies.
Pour faire de l'affichage déporté en tunnel ssh entre deux Mac OS 10.3.x
avec X11 installé tel que sorti du carton, il faut effectivement dans le
sshd_config de la machine cible mettre:
X11Forwarding yes
X11DisplayOffset 10
En fait les décommenter et mettre la première ligne à "yes". J'ai aussi
décommenté la deuxième ligne ce qui ne me paraissait pas... "idiot".
Voilà le résultat:
mac-àmoi:~ moi$ ssh -X toto@mac-Lamachinecible
toto@mac-Lamachinecible's password:
Last login: Wed Jan 12 14:14:15 2005
Welcome to Darwin!
mac-Lamachinecible:~ toto$ echo $DISPLAY
localhost:10.0
mac-Lamachinecible:~ toto$ xlogo&
mac-Lamachinecible:~ toto$ xclock&
--
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
non, non et triple non ! Il faut laisser ssh et sshd négocier et positionner cette variable, le "10" ne tombe pas du ciel.
cf la page de manuel de ssh :
X11 and TCP forwarding [snip].
ce localhost:10 (ou 11, 12, etc) fait passer le traffic X11 à travers un tunel crypté entre le client ssh et le serveur sshd. Le client ssh utilise kerberos (xauth) pour obtenir les droits d'accès au serveur X local et lui transmet le traffic X11 qu'il reçoit du serveur sshd à travers le tunnel ssh.
Avec xhost +mamachine (qui d'ailleurs ne marche pas avec les configurations sécurisées du serveur X) il y a deux problèmes :
- on autorise *tout* utilisateur de la machine à accéder au serveur X (affichage *et* clavier !) - le traffic X11 se fait en clair à travers le réseau, on peut capturer les évènements du clavier, etc.
ça doit être activé dans sshd_config (X11Forwarding yes) et peut être rendu automatique du côté client (plus besoin de '-X') dans ssh_config (ForwardX11 yes).
Je continue le fil de ma question ici... parce que pour suivre vos débats dans le reste de l'enfilade ce n'est pas évident ;)
Merci pour la solution de mon pb. Cela marche.
Je résume pour les newbies.
Pour faire de l'affichage déporté en tunnel ssh entre deux Mac OS 10.3.x avec X11 installé tel que sorti du carton, il faut effectivement dans le sshd_config de la machine cible mettre:
X11Forwarding yes X11DisplayOffset 10
En fait les décommenter et mettre la première ligne à "yes". J'ai aussi décommenté la deuxième ligne ce qui ne me paraissait pas... "idiot".
Voilà le résultat:
mac-àmoi:~ moi$ ssh -X 's password: Last login: Wed Jan 12 14:14:15 2005 Welcome to Darwin! mac-Lamachinecible:~ toto$ echo $DISPLAY localhost:10.0 mac-Lamachinecible:~ toto$ xlogo& mac-Lamachinecible:~ toto$ xclock&
-- 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
Jacques Perrocheau
In article <41e4fdae$0$8013$, Martin Costabel wrote:
Il est peut-être temps pour un petit résumé: Il y a 3 étapes nécessaires et suffisantes pour que ça marche:
;-) Oui, toutafait, j'en ai fait un ici, Message-ID: <cs3anu$j85$
1. Avant de le faire pour la première fois, vérifier que sur la machine distante, le fichier /etc/sshd_config contient la ligne
X11Forwarding yes
Par défaut, il contient
#X11Forwarding no
Donc retirer le "#" et transformer "no" en "yes", ou simplement rajouter la ligne indiquée. On a besoin de droits d'administrateur pour ça.
C'est ce que j'ai fait, j'ai même décommenté la ligne suivante:
X11DisplayOffset 10
Ce qui ne me paraissait pas avoir d'inconvénient.
2. Sur la machine locale, lancer le serveur X11 (X11.app).
3. Dans le shell dans lequel la commande "ssh" sera donnée, vérifier que la variable d'environnement DISPLAY est définie, normalement à ":0". Dans un xterm, c'est le cas automatiquement, dans une fenêtre Terminal.app, on doit le faire soit dans un script de démarrage, soit à la main. Dans bash:
export DISPLAY=:0
Ensuite, "ssh -X machine.distante" va réussir.
Oui, oui voir mon post. :-)))
-- 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 <41e4fdae$0$8013$8fcfb975@news.wanadoo.fr>,
Martin Costabel <costabel@wanadoo.fr> wrote:
Il est peut-être temps pour un petit résumé: Il y a 3 étapes nécessaires
et suffisantes pour que ça marche:
;-) Oui, toutafait, j'en ai fait un ici, Message-ID:
<cs3anu$j85$1@news.univ-rennes1.fr>
1. Avant de le faire pour la première fois, vérifier que sur la machine
distante, le fichier /etc/sshd_config contient la ligne
X11Forwarding yes
Par défaut, il contient
#X11Forwarding no
Donc retirer le "#" et transformer "no" en "yes", ou simplement rajouter
la ligne indiquée. On a besoin de droits d'administrateur pour ça.
C'est ce que j'ai fait, j'ai même décommenté la ligne suivante:
X11DisplayOffset 10
Ce qui ne me paraissait pas avoir d'inconvénient.
2. Sur la machine locale, lancer le serveur X11 (X11.app).
3. Dans le shell dans lequel la commande "ssh" sera donnée, vérifier que
la variable d'environnement DISPLAY est définie, normalement à ":0".
Dans un xterm, c'est le cas automatiquement, dans une fenêtre
Terminal.app, on doit le faire soit dans un script de démarrage, soit à
la main. Dans bash:
export DISPLAY=:0
Ensuite, "ssh -X machine.distante" va réussir.
Oui, oui voir mon post. :-)))
--
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 <41e4fdae$0$8013$, Martin Costabel wrote:
Il est peut-être temps pour un petit résumé: Il y a 3 étapes nécessaires et suffisantes pour que ça marche:
;-) Oui, toutafait, j'en ai fait un ici, Message-ID: <cs3anu$j85$
1. Avant de le faire pour la première fois, vérifier que sur la machine distante, le fichier /etc/sshd_config contient la ligne
X11Forwarding yes
Par défaut, il contient
#X11Forwarding no
Donc retirer le "#" et transformer "no" en "yes", ou simplement rajouter la ligne indiquée. On a besoin de droits d'administrateur pour ça.
C'est ce que j'ai fait, j'ai même décommenté la ligne suivante:
X11DisplayOffset 10
Ce qui ne me paraissait pas avoir d'inconvénient.
2. Sur la machine locale, lancer le serveur X11 (X11.app).
3. Dans le shell dans lequel la commande "ssh" sera donnée, vérifier que la variable d'environnement DISPLAY est définie, normalement à ":0". Dans un xterm, c'est le cas automatiquement, dans une fenêtre Terminal.app, on doit le faire soit dans un script de démarrage, soit à la main. Dans bash:
export DISPLAY=:0
Ensuite, "ssh -X machine.distante" va réussir.
Oui, oui voir mon post. :-)))
-- 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
Saïd wrote:
Ce n'est pas toujours 10.0, donc mieux vaut que tu modifies ton script de login. J'ai ca dans mes scripts (sous zsh):
if [ -z "$DISPLAY" ] then export DISPLAY=:0.0 fi
Est-ce que tu pourais donner les versions de ce test pour tcsh et bash respectivement.. ?
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
Saïd <said@brian.lan> wrote:
Ce n'est pas toujours 10.0, donc mieux vaut que tu modifies ton script de
login. J'ai ca dans mes scripts (sous zsh):
if [ -z "$DISPLAY" ]
then
export DISPLAY=:0.0
fi
Est-ce que tu pourais donner les versions de ce test pour tcsh et bash
respectivement.. ?
--
Jacques PERROCHEAU
________________________________________________________________________
e-mail: mailto:jperrocheau@mac.com
Pour faire de l'affichage déporté en tunnel ssh entre deux Mac OS 10.3.x avec X11 installé tel que sorti du carton,
Et pour faire ça avec une mandrake sur un pc, ç'est pareil ou ça ne marchera pas.
Je ne peux répondre... le Fedora sur PC (un Redhat like parait-il ?) vers lequel je pointe aussi n'a pas été installé par moi.
Déjà, le fil te donne une raison de non fonctionnement et comment il faut configuer pour être "au standard actuel". ;-)
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
laurent.pertois
Ludovic Thébault wrote:
Et pour faire ça avec une mandrake sur un pc, ç'est pareil ou ça ne marchera pas
Il n'y a aucune raison que ça ne marche pas, OpenSSH est le même partout.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Et pour faire ça avec une mandrake sur un pc, ç'est pareil ou ça ne
marchera pas
Il n'y a aucune raison que ça ne marche pas, OpenSSH est le même
partout.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Et pour faire ça avec une mandrake sur un pc, ç'est pareil ou ça ne marchera pas
Il n'y a aucune raison que ça ne marche pas, OpenSSH est le même partout.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Paul Gaborit
À (at) Tue, 11 Jan 2005 18:37:10 +0100, Patrick Stadelmann écrivait (wrote):
Oui, mais dans le cas (le mien en l'occurrence) ou l'on est pas admin sur la machine distant, on ne peut pas changer ce comportement.
Sur des machines normalement configurées, il suffit de faire :
ssh -X
pour que la variable DISPLAY soit correctement positionnée par ssh automatiquement.
*Votre* cas n'a rien à voir avec le cas général ni avec le fait d'être admin ou non : vous avez un environnement fait maison qui casse le bon fonctionnement de 'ssh -X'. À vous de corriger cet environnement maison (en passant si besoin est par votre admin).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Tue, 11 Jan 2005 18:37:10 +0100,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> écrivait (wrote):
Oui, mais dans le cas (le mien en l'occurrence) ou l'on est pas admin
sur la machine distant, on ne peut pas changer ce comportement.
Sur des machines normalement configurées, il suffit de faire :
ssh -X moi@machine
pour que la variable DISPLAY soit correctement positionnée par ssh
automatiquement.
*Votre* cas n'a rien à voir avec le cas général ni avec le fait d'être admin
ou non : vous avez un environnement fait maison qui casse le bon
fonctionnement de 'ssh -X'. À vous de corriger cet environnement maison (en
passant si besoin est par votre admin).
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Tue, 11 Jan 2005 18:37:10 +0100, Patrick Stadelmann écrivait (wrote):
Oui, mais dans le cas (le mien en l'occurrence) ou l'on est pas admin sur la machine distant, on ne peut pas changer ce comportement.
Sur des machines normalement configurées, il suffit de faire :
ssh -X
pour que la variable DISPLAY soit correctement positionnée par ssh automatiquement.
*Votre* cas n'a rien à voir avec le cas général ni avec le fait d'être admin ou non : vous avez un environnement fait maison qui casse le bon fonctionnement de 'ssh -X'. À vous de corriger cet environnement maison (en passant si besoin est par votre admin).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
