Forum Linux.débutant SSH, lancer des applications X distantes, sans X

Posté par  (site web personnel) .
Étiquettes : aucune
0
2
déc.
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 ?!
  • # X Forwarding via SSH

    Posté par  . Évalué à 0.

    Bonjour,

    Regarde du côté du X Forwarding via SSH.
    Pas mal de documentation sur le net à ce sujet.
  • # DISPLAY

    Posté par  . Évalué à 3.

    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

      Posté par  (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  . Évalué à -2.

        man ssh :
        -X Enables X11 forwarding. This can also be specified on a per-host
        basis in a configuration file
      • [^] # Re: DISPLAY

        Posté par  . Évalué à 1.

        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

          Posté par  (site web personnel) . Évalué à 2.

          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 ?
          • [^] # Re: DISPLAY

            Posté par  . Évalué à 1.

            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

              Posté par  (site web personnel) . Évalué à 1.

              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 ...
        • [^] # Re: DISPLAY

          Posté par  (site web personnel) . Évalué à 2.

          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 ...
          • [^] # Re: DISPLAY

            Posté par  . Évalué à 2.

            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

              Posté par  (site web personnel) . Évalué à 2.

              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)
              • [^] # Re: DISPLAY

                Posté par  . Évalué à 1.

                >ç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

                  Posté par  . Évalué à 1.

                  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

                    Posté par  (site web personnel) . Évalué à 1.

                    > 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 ;-)
                • [^] # Re: DISPLAY

                  Posté par  (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  . Évalué à 2.

    Petit test avec xterm :
    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  (site web personnel) . Évalué à 2.

      non, toujours pas mieux :

      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  . Évalué à 1.

        les debian ont par défaut une option complétement débile au serveur X : le no listen tcp... je ne sais pas ou ca se configure mais ca peut être ça...

        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  . Évalué à 2.

          Oui, mais non justement :
          - 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  (site web personnel) . Évalué à 2.

    Bonsoir (ou bonjour):

    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  (site web personnel) . Évalué à 2.

      > le "propriétaire" de la session X est bien le même que celui qui
      > 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.