Linux.debutant : SSH, lancer des applications X distantes, sans X
Posté par manatlan (Jabber id, page perso, ) le 02 décembre 2005
ça parait bête, mais je n'y arrive pas ...
Quand je démarre mon ordi à la maison, il se connecte directement dans la session de mon user ... "toto" ...
De l'exterieur, je m'y connecte via SSH ...à travers le compte "toto" ...
Je peux killer les applis X11 qui sont déjà lancées dans la session précédente ! (avec killall)
Mais je n'arrive pas à lancer une application X11 en utilisant SSH ... ça doit être possible ?! Je ne veux pas déporter le display ! je voudrai qu'elle se lance, comme si j'étais en local sur mon poste ...
Tant pis si je vois rien, (je peux controller son execution dans les process)
J'ai essayé avec différents "export display" mais sans y arriver ... ça doit être possible non ?!
Quand je démarre mon ordi à la maison, il se connecte directement dans la session de mon user ... "toto" ...
De l'exterieur, je m'y connecte via SSH ...à travers le compte "toto" ...
Je peux killer les applis X11 qui sont déjà lancées dans la session précédente ! (avec killall)
Mais je n'arrive pas à lancer une application X11 en utilisant SSH ... ça doit être possible ?! Je ne veux pas déporter le display ! je voudrai qu'elle se lance, comme si j'étais en local sur mon poste ...
Tant pis si je vois rien, (je peux controller son execution dans les process)
J'ai essayé avec différents "export display" mais sans y arriver ... ça doit être possible non ?!
> Lire le message (22 commentaires, moyenne: 1,5).
Vous avez demandé le commentaire #655472.
Run by 
Cette page a été générée par Templeet en 0.0722s (dont 0.0063 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
DISPLAY
Salut,
Il n'y a pas vraiment de raison que ça ne marche à condition de respecter certaines règles :
- il faut que sur ta machine à la maison toto ait une session graphique active.
- ensuite tu te connectes en SSH, sous le user toto, et tu tapes "export DISPLAY=:0.0".
- à partir de là tu dois pouvoir lancer des applications graphiques simplement en tapant les commandes qui vont bien, mais évidemment tu ne verras rien.
Une autre solution, peut être plus conviviale, serait l'utilisation d'un serveur VNC explortant le DISPLAY courant (X0vnc-server, vino, krfb ou d'autes en fonction de ta distrib et de ton environnement de bureau). Le client VNC existe sur à peu près toutes les plates-formes (linux, Windows, PalmOS, Amiga, MacOS, ...) et la connexion peut se faire via un tunnel SSH. Tu aurais alors l'énorme avantage de te retrouver avec ton bureau complet dans une fenêtre, et donc de voir ce qui se passe.
A+
JJD
[^]Re: DISPLAY
- il faut que sur ta machine à la maison toto ait une session graphique active.
- ensuite tu te connectes en SSH, sous le user toto, et tu tapes "export DISPLAY=:0.0".
et non ;-( ... justement, ça marche pas ...
manatlan@ubuntu-box:~$ export DISPLAY=:0.0
manatlan@ubuntu-box:~$ xclock
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
Error: Can't open display: :0.0
j'aimerai que ça marche ... une soluce ?
manatlan.com
[+] [^]Re: DISPLAY
man ssh :
-X Enables X11 forwarding. This can also be specified on a per-host
basis in a configuration file
Ubuntu is an ancient african word meaning : "I can't configure Debian"
[^]Re: DISPLAY
Sur ton poste à la maison, essaies avec :
xhost + (pour donner accès à tout le monde)
ou
xhost +nom_machine (pour donner accès à ton poste nom_machine)
[^]Re: DISPLAY
Sur ton poste à la maison, essaies avec :
xhost + (pour donner accès à tout le monde)
oui, mais ça, je peux pas le faire en ssh, non ? car là je suis distant de ma maison ...
sinon, j'essaierai bien ...
aussi ne faut il pas utiliser xauth plutot que "host +" non ?
manatlan.com
[^]Re: DISPLAY
Je pense effectivement qu'il faut oublier les histoires de xhost (tu essaies de lancer les applis localement) et de "ssh -X" (puisque tu as clairement expliqué dans ta question que ce n'est pas ce que tu voulais).
Il est en revanche fort possible que le problème vienne de xauth ou d'une configuration particulière de ssh/sshd (mais là je ne vois pas trop ce qui pourrait clocher).
Quelques pistes tout de même :
- dans ta session SSH, est-ce que la variable XAUTHORITY existe ?
- si oui, que vaut-elle ?
- si tu fixes la valeur de cette variable à ~toto/.Xauthority , il y a-t-il toujours le même problème ?
- que donne la commande "xauth list" dans la session ssh et en local?
- ... (si quelqu'un a des idées)
JJD
[^]Re: DISPLAY
malheureusement, je ne suis plus au boulot (heuresement aussi ;-)
je ne peux plus tenter via putty/ssh
mais je tente en local, avec un "ssh localhost"
le résultat est quasi-identique ...
un simple "DISPLAY=:0 xclock" renvoi la même erreur ...
mais si en local, dans un terminal, je fais un "xhost +"
après en SSH, ça marche .... !
"xhost +" est asse violent, y a t il moyen de n'autoriser que son user ?
sinon, pour répondre à tes questions :
dans mon "SSH local", il n'y a pas de variable XAUTHORITY
xauth list me renvoi la liste des cookies suivantes :
ubuntu-box/unix:0 MIT-MAGIC-COOKIE-1 972456e27d1091a86b0aa7285e962a122e5ab0c
localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 972e7d0945a6861b2aa07285e962a122e5ab0c
localhost.localdomain:0 MIT-MAGIC-COOKIE-1 972e7d023911a86baa7285e962a12211e5ab0c
shm67-2-XX-XX-XX-XX.fbx.proxad.net:0 MIT-MAGIC-COOKIE-1 972e7d01239a86baa7283215e962a122e5ab0c
j'ai maquillé les trucs qu'il me semblait dangereux à publier dans un forum ...
manatlan.com
[^]Re: DISPLAY
je veux bien tenter ça
xhost +nom_machine
mais je ne connais pas le nom de la machine, ni son ip
je passe mon ssh à travers des proxy, etc ...
je prefererai adder un user ... "toto" a toujours avoir le droit d'ouvrir sous x ... ce serait plus cohérent ...
je suis en train de me tapper la doc xauth ... mais les cookies mit, ça me dépasse ...
manatlan.com
[^]Re: DISPLAY
Si la variable DISPLAY vaut :0.0, je continue de penser qu'un "xhost +client_ssh" ne servira à pas grand chose : la connexion au serveur X ne se fait pas en TCP, et certainement pas depuis l'adresse IP du client SSH (ou du proxy).
Un "xhost +" est à proscire absolument : c'est un énorme trou de sécurité !
En revanche, il y a peut être un compromis en utilisant simplement un "xhost +LOCAL:" : tu n'autorises ainsi que les utilisateurs locaux à utiliser le serveur X :0.0 (n'oublie pas de faire un "xhost -" avant).
Mais tout cela n'explique pas pourquoi l'authentification xauth ne fonctionne pas...
JJD
[^]Re: DISPLAY
oui, "xauth" me semble étrange ...
je voulais tenter, la technique de s'adder en ssh dans xauth, comme ici : http://lists.debian.org/debian-user-french/2002/07/msg00178.(...)
mais en ssh, la commande xauth me renvi systématiquement :
xauth: error in locking authority file /home/manatlan/.Xauthority
au sujet du "xhost +local:"
tu n'autorises ainsi que les utilisateurs locaux
ça voudra dire que seul les utilisateurs (ceux déclarés dans /home) pourront se connecter, d'où qu'ils proviennent ...
ou ça veut dire que seuls les utilisateur en localhost pourront accéder au display ?
evidemment, si c la premère réponse, c absolument parfait, et ce que je voulais ...
(question subsidiare, dans quel fichier est le plus propice pour recevoir les commandes : "xhost -; xhost +local:", que je modifi de suite ma config, pour que dans le futur je puisse lancer mes xclock à distances via ssh)
manatlan.com
[^]Re: DISPLAY
>ça voudra dire que seul les utilisateurs (ceux déclarés dans /home)
> pourront se connecter, d'où qu'ils proviennent ...
> ou ça veut dire que seuls les utilisateur en localhost pourront
> accéder au display ?
Heuuuuu, je comprends pas tout...
Mais bon, en résumé, cela signifie que tous les utilisateurs qui peuvent accéder à ton serveur X en le désignant par ":0.0" pourront l'utiliser. Cela exclue les connexions TCP, où le DISPLAY vaut <adresse_ip_ou_nom>:0.0, ainsi que les connexions sur 127.0.0.1:0.0.
Le serveur X sera accessible uniquement en local, c'est à dire par les personnes ayant ouvert une session sur la machine, quel que soit le moyen pour ouvrir cette session (gdm/xdm/kdm, logon dans la console en local, connexion distante en telnet/ssh.rlogin, ...).
En clair, ça veut dire qu'il faut que tu fasses confiance aux personnes susceptibles de se connecter sur ta machine (toutes celles qui possèdent un user/mot de passe), car elles pourront toutes lancer des applications qui utiliserons ton display (pour afficher des choses, mais également pour observer tout ce qui s'y passe).
>quel fichier est le plus propice pour recevoir les commandes
Si tu veux que les commandes xhost soient exécutés à chaque fois que tu te logues, tu peux les mettre dans ~/.bash_profile (ou ~/.profile) ou dans ~/.bashrc (le premie est utilisé sur un shell de login intercatif, le deuxième -normalement- dans les autes cas). Mais cela signifie que tu autorises les connexions locales au serveur X dès que tu te connectes. Tu peux aussi, pour lancer tes xclock, utiliser un script du genre :
#!/bin/bash
xhost -
xhost +LOCAL:
xclock
xhost -LOCAL:
et tu appelles ce script en lieu et place de xclock.
Mais je voudrais bien savoir ce que tu vas faire de toutes ces horloges sur ton écran ;-)
A+
JJD
[^]Re: DISPLAY
Je me réponds rapidement à moi même avant de me afire incendier...
J'ai raconté des conneries à la fin de mon post précédent : si tu n'a pas accès au display, tu vas avoir du mal à exécuter la commande xhost...
La seule possibilité me semble donc d'exécuter xhost lors de l'ouverture de ta session graphique (petit script lancé au démarrage de gnome/kde/xfce ou du WM utilisé).
JJD
[^]Re: DISPLAY
> si tu n'a pas accès au display, tu vas avoir du mal à
> exécuter la commande xhost...
oui, je me disais bien, mais j'avais corrigé par moi meme ;-)
manatlan.com
[^]Re: DISPLAY
Mais je voudrais bien savoir ce que tu vas faire de toutes ces horloges sur ton écran ;-)
quand ma copine, de la maison, m'appelle au bureau pour me demander l'heure, je lui dit de démarrer l'ordi.
Et du bureau, je lance alors mon proxy NTLM, je me connecte via SSH, et je lui lance xclock ...
tout simplement ... ;-)
en fait, je cherche à pouvoir lancer des applis X ou non X sur mon ordi à la maison, à partir du bureau ... (quand je part le matin au boulot, dès fois j'oubli de lancer des trucs)
avant le prob ne se posait pas trop, je passais par freenx, j'ouvrai une session, je demarrai mes applis, et je laissais la sessions en suspend ... (et quand je rentrai le soir, je tuais la session freenx)
depuis mon passage en breezy, je n'arrive plus à ouvrir une session sur mon compte principal (j'y arrive sans prob sur d'autres comptes ?!) (si qqu'un a une idée pourkoi ça marche pas, suis prenneur )
du coup, il fallait trouver un autre moyen ....
parr ssh, à coup de xhost, ça devrait aussi le faire ... (avec le coup du +local:)
lundi, je vais tenter le vnc par ssh ...(comme tu préconisais) ... j'y avais même pas penser (?!?) ... mais je doute que ça boost autant qu'avec freenx ... ;-( ...et freenx épatait énormément mes collègues ;-( ... vnc ça le fera pas ;-( ....
manatlan.com