Ssh - Ouvrir une fenêtre sur un affichage distant X (pourquoi "ne peut pas ouvrir l'affichage") ?

Il était une fois,

DISPLAY=:0.0 totem /path/to/movie.avi

après ssh sur mon bureau depuis mon ordinateur portable, totem jouerait movie.avi sur mon bureau.

Maintenant, il donne l'erreur :

No protocol specified
Cannot open display:

J'ai réinstallé Debian squeeze lorsqu'il est devenu stable sur les deux ordinateurs, et je suppose que j'ai cassé la configuration.

J'ai cherché sur Google à ce sujet et je ne peux pas comprendre ce que je suis censé faire.

(VLC a une interface HTTP qui fonctionne, mais ce n'est pas aussi pratique que ssh.)

Le même problème se pose lorsque j'essaie de l'exécuter à partir d'une tâche cron.

Réponse acceptée :

_{(Adapté de Linux :wmctrl ne peut pas ouvrir l'affichage lorsque la session est lancée via ssh+screen)}

AFFICHAGE et AUTORITÉ

Un programme X a besoin de deux informations pour se connecter à un affichage X.

• Il a besoin de l'adresse de l'affichage, qui est généralement :0 lorsque vous êtes connecté localement ou :10 , :11 , etc. lorsque vous êtes connecté à distance (mais le nombre peut changer en fonction du nombre de connexions X actives). L'adresse de l'afficheur est normalement indiquée dans le DISPLAY variable d'environnement.

• Il a besoin du mot de passe pour l'affichage. X mots de passe d'affichage sont appelés cookies magiques . Les cookies magiques ne sont pas spécifiés directement :ils sont toujours stockés dans des fichiers d'autorité X, qui sont une collection d'enregistrements de la forme "affichage :42 a le cookie 123456 ”. Le fichier d'autorité X est normalement indiqué dans le XAUTHORITY variables d'environnement. Si $XAUTHORITY n'est pas défini, les programmes utilisent ~/.Xauthority .

Vous essayez d'agir sur les fenêtres qui s'affichent sur votre bureau. Si vous êtes la seule personne à utiliser votre ordinateur de bureau, il est très probable que le nom d'affichage soit :0 . Trouver l'emplacement du fichier d'autorité X est plus difficile, car avec gdm tel que configuré sous Debian squeeze ou Ubuntu 10.04, il se trouve dans un fichier avec un nom généré aléatoirement. (Vous n'aviez aucun problème auparavant car les versions antérieures de gdm utilisaient le paramètre par défaut, c'est-à-dire les cookies stockés dans ~/.Xauthority .)

Obtenir les valeurs des variables

Voici quelques façons d'obtenir les valeurs de DISPLAY et XAUTHORITY :

• Vous pouvez systématiquement démarrer une session screen depuis votre bureau, peut-être automatiquement dans vos scripts de connexion (depuis ~/.profile; mais ne le faites que si vous vous connectez sous X :testez si DISPLAY est défini sur une valeur commençant par : (qui devrait couvrir tous les cas que vous êtes susceptible de rencontrer)). Dans ~/.profile :

  case $DISPLAY in
    :*) screen -S local -d -m;;
  esac
  

  Puis, dans la session ssh :

  screen -d -r local
  

• Vous pouvez également enregistrer les valeurs de DISPLAY et XAUTHORITY dans un fichier et rappeler les valeurs. Dans ~/.profile :

  case $DISPLAY in
    :*) export | grep -E '(^| )(DISPLAY|XAUTHORITY)=' >~/.local-display-setup.sh;;
  esac
  

  Dans la session ssh :

  . ~/.local-display-setup.sh
  screen
  

• Vous pourriez détecter les valeurs de DISPLAY et XAUTHORITY à partir d'un processus en cours d'exécution. C'est plus difficile à automatiser. Vous devez déterminer le PID d'un processus connecté à l'affichage sur lequel vous souhaitez travailler, puis obtenir les variables d'environnement à partir de /proc/$pid/environ (eval export $(</proc/$pid/environ tr \0 \n | grep -E '^(DISPLAY|XAUTHORITY)=') ¹).

Connexe :Existe-t-il des fréquences radio ouvertes/sans restriction qui sont gratuites pour toute utilisation ?

Copier les cookies

Une autre approche (suite à une suggestion d'Arrowmaster) est de ne pas essayer d'obtenir la valeur de $XAUTHORITY dans la session ssh, mais à la place pour que la session X copie ses cookies dans ~/.Xauthority . Étant donné que les cookies sont générés à chaque fois que vous vous connectez, ce n'est pas un problème si vous conservez des valeurs obsolètes dans ~/.Xauthority .

Il peut y avoir un problème de sécurité si votre répertoire personnel est accessible via NFS ou un autre système de fichiers réseau permettant aux administrateurs distants d'afficher son contenu. Ils auraient toujours besoin de se connecter à votre machine d'une manière ou d'une autre, à moins que vous n'ayez activé les connexions X TCP (Debian les a désactivées par défaut). Donc, pour la plupart des gens, cela ne s'applique pas (pas de NFS) ou n'est pas un problème (pas de connexions X TCP).

Pour copier les cookies lorsque vous vous connectez à votre session de bureau X, ajoutez les lignes suivantes à ~/.xprofile ou ~/.profile (ou un autre script lu lorsque vous vous connectez) :

case $DISPLAY:$XAUTHORITY in
  :*:?*)
    # DISPLAY is set and points to a local display, and XAUTHORITY is
    # set, so merge the contents of `$XAUTHORITY` into ~/.Xauthority.
    XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
esac

¹ _{En principe, cela manque de guillemets appropriés, mais dans ce cas spécifique $DISPLAY et $XAUTHORITY ne contiendra aucun métacaractère shell.}