ç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 ?!
# X Forwarding via SSH
Posté par Sebastian . Évalué à 0.
Regarde du côté du X Forwarding via SSH.
Pas mal de documentation sur le net à ce sujet.
[^] # Re: X Forwarding via SSH
Posté par manatlan (site web personnel) . Évalué à 2.
si je veux faire du VISUEL, j'utilise freenx ça marche parfaitement bien ...
# DISPLAY
Posté par JJD . Évalué à 3.
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
Posté par manatlan (site web personnel) . Évalué à 2.
- 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 ?
[^] # Re: DISPLAY
Posté par Gart Algar . Évalué à -2.
-X Enables X11 forwarding. This can also be specified on a per-host
basis in a configuration file
[^] # Re: DISPLAY
Posté par Philippe Martin . Évalué à 1.
xhost + (pour donner accès à tout le monde)
ou
xhost +nom_machine (pour donner accès à ton poste nom_machine)
[^] # Re: DISPLAY
Posté par manatlan (site web personnel) . Évalué à 2.
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 ?
[^] # Re: DISPLAY
Posté par JJD . Évalué à 1.
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
Posté par manatlan (site web personnel) . Évalué à 1.
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 ...
[^] # Re: DISPLAY
Posté par manatlan (site web personnel) . Évalué à 2.
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 ...
[^] # Re: DISPLAY
Posté par JJD . Évalué à 2.
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
Posté par manatlan (site web personnel) . Évalué à 2.
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)
[^] # Re: DISPLAY
Posté par JJD . Évalué à 1.
> 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
Posté par JJD . Évalué à 1.
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
Posté par manatlan (site web personnel) . Évalué à 1.
> exécuter la commande xhost...
oui, je me disais bien, mais j'avais corrigé par moi meme ;-)
[^] # Re: DISPLAY
Posté par manatlan (site web personnel) . Évalué à 2.
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 ;-( ....
# "chez moi ça marche" !
Posté par netsurfeur . Évalué à 2.
ssh machine
DISPLAY=:0 xterm
et j'ai une fenêtre xterm sur la machine distante !
Peux-tu donner plus de détails ?
- commande(s) exacte(s) que tu lances
- message(s) d'erreur
[^] # Re: "chez moi ça marche" !
Posté par manatlan (site web personnel) . Évalué à 2.
manatlan@ubuntu-box:~$ DISPLAY=:0 xclock
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
Error: Can't open display: :0
[^] # Re: "chez moi ça marche" !
Posté par fearan . Évalué à 1.
sinon moins bourrin que les xhost +localhost
il y a le xauth
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: "chez moi ça marche" !
Posté par JJD . Évalué à 2.
- si on fixe la variable DISPLAY à la valeur :0.0 on ne passe pas par la pile tcp, mais sur un socket Unix. L'option "-nolisten tcp" ne devrait donc pas avoir d'influence (accessoirement cela se règle en général dans les fichiers de configuration de gdm/kdm/xdm et l'option n'est pas complètement débile puisque la plupart du temps les connexions TCP sur le serveur X ne sont pas utilisés et que cela n'empêche pas l'utilisation d'un tunnel SSH).
- le problème peut effectivement venir de l'authentification X11 (xauth), mais c'est assez étrange puisque la commande graphique est lancée en local (dans la session ssh), par le même utilisateur que celui qui a ouvert la session graphique. Les cookies d'authentification devraient donc être accessible de la même façon.
Il faut peut être chercher au niveau des variables d'environnement ou de la configuration de ssh...
JJD
# Question idiote
Posté par Khâpin (site web personnel) . Évalué à 2.
une question peut-être stupide:
le "propriétaire" de la session X est bien le même que celui qui se connecte en ssh (manatlan apparemment)?
Sinon, tu peux faire un
su - logindetacopine
export DISPLAY=:0.0
xhost +local:manatlan
exit
puis ton export DISPLAY=:0.0 xclock va marcher.
Je fais ça pour lancer des applis graphiques pour ma copine par ssh quand elle est loguée, donc chezmoiçamarche.
[^] # Re: Question idiote
Posté par manatlan (site web personnel) . Évalué à 2.
> se connecte en ssh (manatlan apparemment)?
oui, bien evidemment
sinon, merci pour ça : "xhost +local:manatlan"
je ne savais pas qu'on pouvais suffixer le user, c encore mieux
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.