Question Comment puis-je corriger une erreur "Impossible d'ouvrir l'écran" lors de l'ouverture d'un programme X après ssh'ing avec le transfert X11 activé?


Après avoir lancé l'application X11 (XQuartz 2.3.6, xorg-server 1.4.2-apple56) sur mon Mac (OS X 10.6.8), ouvrir un terminal en X11 et exécuter xhost +, J'ai alors ssh -Y sur ma machine virtuelle Ubuntu 10.04 (exécutée sur VMware Fusion). Quand je cours gedit .bashrc (par exemple), je reçois:

(gedit:9510): Gtk-WARNING **: cannot open display: 

set | grep DISPLAY ne renvoie rien.

Mais si je ssh -Y dans ma machine Ubuntu 11.04, gedit .bashrc travaux. echo $DISPLAY renvoie "localhost: 10.0".

j'ai essayé export DISPLAY=localhost:10.0 tout en sshed dans ma VM, puis en cours d'exécution gedit .bashrc, mais je reçois:

(gedit:9625): Gtk-WARNING **: cannot open display: localhost:10.0

Qu'est-ce qui pourrait être différent dans la configuration des deux machines Ubuntu différentes qui expliqueraient pourquoi l'une fonctionne et l'autre non?

Mettre à jour: Comme suggéré par Zoredache dans le commentaire ci-dessous, j'ai couru sudo apt-get install xbase-clients, mais je continue d'avoir le même problème.


82
2017-07-13 18:13


origine


La boîte Ubuntu 10.04 dispose-t-elle des outils appropriés pour X11? Installez les clients xbase, s’ils ne sont pas déjà installés. - Zoredache
Je l'ai installé mais j'ai toujours le même problème. (Voir au dessus.) - Daryl Spitzer
Oui. Juste pour être sûr, j'ai redémarré la VM (et reconnecté via SSH par la suite). - Daryl Spitzer
Peut-être essayez de passer l'option -vv à ssh lorsque vous vous connectez, cela affiche des messages de débogage détaillés, vous devriez voir plusieurs commentaires sur le transfert X11 lors de la connexion. - Zoredache
Dans mon cas, il s'agissait simplement de mettre à niveau la version XQuartz de MacOS - Waruna Ranasinghe


Réponses:


Vérifiez le serveur sshd_config (normalement /etc/ssh/sshd_config), et assurez-vous que l'option X11Forwarding est activée avec la ligne

X11Forwarding yes

Si X11Forwarding n'est pas spécifié, la valeur par défaut est non sur les machines Debian disponibles.


31
2017-07-13 18:54



J'ai découvert, après avoir installé une autre machine virtuelle Ubuntu, que je devais à la fois installer les clients xbase et activer X11Forwarding. Mettez à jour votre réponse pour inclure les deux et je l'accepterai. - Daryl Spitzer
Intéressant. Au moins sur la nouvelle installation de 10.04 que j'ai faite ce matin, X11Forwarding était activé par défaut. Les gars d'Ubuntu doivent encore jouer avec les défauts. - Zoredache
@DerfK, dans mon système "X11Forwarding yes" était déjà là je reçois encore une erreur car, (gedit: 8381): Gtk-WARNING **: impossible d'ouvrir l'affichage: dans ces cas - A J
Sur Debian, vous devrez peut-être installer le paquet xauth, puis vous reconnecter. - comte


De xhost +: comment réparer l'erreur "Impossible d'ouvrir l'affichage" lors du lancement de l'interface graphique sur le serveur distant:

Répondre: Vous pouvez corriger l'erreur "Impossible d'ouvrir l'affichage" en suivant la procédure xhost mentionnée dans cet article.

Autoriser les clients à se connecter depuis n'importe quel hôte en utilisant xhost +

Exécutez la commande suivante pour désactiver le contrôle d'accès, par lequel   vous pouvez autoriser les clients à se connecter depuis n'importe quel hôte.

$ xhost +

le contrôle d'accès désactivé, les clients peuvent se connecter depuis n'importe quel hôte

Activer le transfert X11

Lors de l'exécution de ssh, utilisez l'option -X pour activer le transfert X11.

$ ssh username@hostname -X

Activer le transfert sécurisé X11, en utilisant l'option -Y,

$ ssh username@hostname -Y

Ouvrir des applications d'interface graphique dans cet hôte

Après avoir ouvert la connexion ssh à l'hôte distant comme expliqué ci-dessus,   vous pouvez ouvrir n'importe quelle application graphique qui l'ouvrira sans problème.

Si vous obtenez toujours l’erreur "Impossible d’ouvrir l’affichage", définissez   variable comme indiqué ci-dessous.

$ export DISPLAY='IP:0.0'

Remarque: IP est l'adresse IP du poste de travail local où vous souhaitez utiliser l'interface graphique.   application à afficher.


48
2018-02-21 08:47



+1 pour la note IP = est l'adresse IP du poste de travail local où vous souhaitez obtenir l'interface graphique - PCoder
Pour ceux qui ont des problèmes similaires sur OS X, assurez-vous également que XQuartz est installé, sinon aucune de ces corrections ne vous aidera. (La question d'OP montre qu'il a XQuartz, donc c'est plus une note secondaire pour ceux qui ont des problèmes similaires que moi) - Dolan Antenucci
Notez que en cours d'exécution xhost + est très peu sûr et ne doit pas être utilisé! Comme Stefan Rogin l’a mentionné, l’attaquant peut alors se connecter depuis l’hôte à votre XSession, lire tout ce que vous tapez ou même modifier l’écran que vous voyez. - jirislav


J'ai rencontré ce problème lors de la connexion à une machine virtuelle Ubuntu à partir de Mac OS X - il ne semble pas aimer «localhost» dans la variable d’affichage pour une raison quelconque. Donc, définissez l’IP manuellement, comme le suggère harrymc:

export DISPLAY="127.0.0.1:10.0"

Alors les programmes X11 devraient aller bien. Il ne semble pas qu'il soit nécessaire de dire à l'OS que localhost et 127.0.0.1 sont équivalents, mais cela fonctionne au moins.


16
2018-06-29 20:44



Cela a fonctionné pour moi. Toute idée pourquoi localhost ne fonctionnait pas? - Alex
BINGO! J'ai été bloqué par ce problème pendant un certain temps ... Je me suis connecté par SSH et je ne pouvais pas lancer de programmes Gtk (X11 simple, comme "xeyes", cependant). AFFICHAGE était correct. En fait, la résolution de "localhost" n'était pas! Si je définis manuellement DISPLAY = 127.0.0.1: 10.0 ou DISPLAY = :: 1: 10.0, cela fonctionne. L'édition de / etc / hosts semble n'avoir aucun effet; et DNS est correctement configuré ("dig localhost" correclty rapport à la fois 127.0.0.1 et :: 1) Donc, il semble y avoir un bogue dans la résolution DNS pour les connexions X11 dans Gtk (gtk? gdk? glib? other?). - Pablo Saratxaga
Sur une installation Debian pour le Beagle Bone Black, / etc / host n'était pas lisible par quiconque autre que root. Cela a causé les symptômes rapportés ici. Rendre / etc / hosts lisible par tous, et ça a bien fonctionné. - Daniel


J'ai eu ce problème avec mon serveur KOS CentOS, il me manquait le programme "xauth".


13
2017-10-22 07:59



Cela m'a aidé dans mon installation minimale de Debian, merci beaucoup! - binOr


Si vous avez ce problème après quelque temps en courant avec -X arg. ou juste ForwardX11 dans / etc / ssh / ssh_config, puis exécutez $ ssh username@hostname -Y, autoriser transfert de confiance X11, ne sais pas la cause exacte mais je devine avec -X certaines fonctionnalités expirent après un certain temps, probablement pour améliorer la sécurité.

Voici ce que j'ai trouvé en ligne:

Si vous utilisez ssh -X remotemachine, la machine distante est traitée comme une   client non approuvé. Ainsi, votre client local envoie une commande à la télécommande   machine et reçoit la sortie graphique. Si votre commande viole   certains paramètres de sécurité, vous recevrez une erreur à la place.

Mais si vous utilisez ssh -Y remotemachine, la machine distante est traitée comme   client de confiance. Cette dernière option peut ouvrir des problèmes de sécurité. Car   un autre client graphique (X11) peut détecter les données de la machine distante   (faire des captures d'écran, faire du keylogging et d'autres trucs méchants) et c'est même   possible de modifier ces données.

Si vous voulez en savoir plus sur ces choses, je suggère de lire le   La page de manuel Xsecurity ou la spécification d'extension X Security. De plus vous   peut vérifier les options ForwardX11 et ForwardX11Trusted dans votre   / etc / ssh / ssh_config.

sources:


8
2017-10-17 08:06





Lors de l'exécution de UXTERM ou XTERM uniquement

export $DISPLAY 

La variable sera là. Ensuite, configurez-le et exportez-le.


4
2017-07-10 21:26





Juste testé sur mon Mac, d'autres systèmes pourraient être OK:

  1. Autoriser les clients à se connecter depuis n'importe quel hôte en utilisant xhost +

    $ xhost +

  2. Vous devriez avoir un environnement qui supporte l'affichage X11

    [Système Mac] Installez X11 pour mac https://www.xquartz.org/

  3. Vous devez laisser votre serveur ssh-server afficher x11

    mettre à jour /etc/ssh/sshd_config Et mettre X11Forwarding yes, puis redémarrez votre serveur ssh

  4. Vous devez laisser votre session ssh avancer x11 afficher avec -X paramètre

    $ ssh -X utilisateur @ ip

  5. Comment ouvrir l'application X11 dans PyCharm?
    • ouvrir une session ssh prenant en charge l'affichage X11 (n'oubliez pas de conserver cette session)
    • courir echo $DISPLAY dans cette session ssh
    • ensemble DISPLAY variable d'environnement pour votre PyCharm

4
2017-08-30 11:36



Pourquoi est-ce différent ou pourquoi devrait-il être préféré à l'une des autres réponses? S'il vous plaît expliquer si vous le pouvez avec un simple modifier. Tu peux le faire!! - Pimp Juice IT
@ McDonald's Merci, mis à jour avec plus de détails. - Color


J'ai également eu ce problème avec Solaris 10 et j'ai constaté que le listener n'était pas configuré.

svccfg –s /application/x11/x11-server listprop options/tcp_listen
svccfg –s /application/x11/x11-server setprop  options/tcp_listen = true

2
2018-03-18 22:52





J'ai dû mettre dans /etc/ssh/sshd_config le suivant:

X11UseLocalhost no

Plutôt que de le mettre "oui". Étrange si la valeur par défaut est "NON" Utilisateurs utilisant du mastic avec XMing sous Windows. J'utilise ssh directement sur Fedora. Parfois, il commencerait à nous donner

error can't open display localhost

Le redémarrage du serveur résout généralement le problème, mais c'est stupide. A fait ce qui précède, a redémarré le service sshd sur le serveur et presto de nouvelles connexions fonctionnent à nouveau correctement.


2
2017-09-01 01:17





Sur CentOS 6.5, j'ai soudainement perdu l'accès aux programmes X distants après avoir utilisé / etc / hosts. Même symptôme de la variable vide $ DISPLAY (aucune aide pour le définir / l'exporter manuellement).

L'entrée 127.0.0.1 pointant vers le nom d'hôte actuel est nécessaire. en fait, la commande semble également pertinente (mettre en dernier et cela ne fonctionnera pas ...)

[root@poseidon /etc]$ cat hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost
::1     localhost6.localdomain6 localhost6
127.0.0.1 poseidon.mycampus.edu poseidon
1XX.XXX.XXX.208 poseidon.mycampus.edu poseidon

Après avoir réparé cela, xeyes, xclock et les autres jouets de test X fonctionnent à nouveau, donc mon virt-manager est également de retour.


1
2017-07-15 15:13





Je viens de trouver un joli hoquet dans ma configuration qui empêchait le transfert x: Mon pare-feu bloquait toutes les connexions de localhost, empêchant ainsi d'atteindre le tunnel


1
2018-06-10 11:56