web-dev-qa-db-fra.com

Comment corriger une erreur "Impossible d'ouvrir l'affichage" lors de l'ouverture d'un programme X après ssh 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), ouvert un terminal sous X11 et exécuté xhost +, j'ai ssh -Y sur mon Ubuntu 10.04 VM (s'exécutant sur VMware Fusion). Lorsque je lance 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 fonctionne. echo $DISPLAY renvoie "localhost: 10.0".

J'ai essayé export DISPLAY=localhost:10.0 alors que sshed était installé dans mon VM puis j'exécutais 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 qui expliquerait pourquoi l'une fonctionne et l'autre pas?

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

sshdisplayxorggtk
98
Daryl Spitzer

Vérifiez le sshd_config du serveur (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 no sur les machines Debian disponibles pour vérification.

39
DerfK

De xhost +: Comment corriger l'erreur “Impossible d'ouvrir l'affichage” lors du lancement de l'interface graphique sur le serveur distant :

Answer : Vous pouvez corriger l'erreur «impossible d'ouvrir l'affichage» en suivant la procédure xhost mentionnée dans cet article.

Autorise les clients à se connecter depuis n'importe quel hôte à l'aide de xhost +

Exécutez la commande suivante pour désactiver le contrôle d'accès, grâce auquel vous pouvez autoriser les clients à se connecter à partir de n'importe quel hôte.

$ xhost +

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

Activer le transfert X11

Lorsque vous utilisez ssh, utilisez l’option -X pour activer le transfert X11.

$ ssh username@hostname -X

Activer le transfert X11 de confiance en utilisant l’option -Y,

$ ssh username@hostname -Y

Ouvrez les applications graphiques sur 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 la variable DISPLAY comme indiqué ci-dessous.

$ export DISPLAY='IP:0.0'

Remarque: IP correspond à l’adresse IP du poste de travail local sur lequel vous souhaitez afficher l’application graphique.

54
harrymc

J'ai eu ce problème lors de la connexion à une Ubuntu VM à partir de Mac OS X également - il ne semble pas que "localhost" apparaisse dans la variable display pour une raison quelconque. Donc, définissez l’adresse IP manuellement, comme le suggère harrymc:

export DISPLAY="127.0.0.1:10.0"

Alors les programmes X11 devraient aller. Il ne semble pas nécessaire d’indiquer au système d’exploitation que localhost et 127.0.0.1 sont équivalents, mais cela fonctionne au moins.

17
spinup

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

13
Joril

Si vous avez ce problème après un certain temps lors de l'exécution avec -X arg. ou simplement ForwardX11 dans/etc/ssh/ssh_config, puis exécutez $ ssh username@hostname -Y pour activer transfert X11 de confiance , je ne connais pas la cause exacte, mais je suppose qu'avec -X certaines fonctionnalités expirent après un certain temps, probablement pour augmenter la sécurité.

Voici ce que j'ai trouvé en ligne:

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

Mais si vous utilisez ssh -Y remotemachine, la machine distante est traitée comme un client approuvé. Cette dernière option peut ouvrir des problèmes de sécurité. Parce qu'un autre client graphique (X11) pourrait renifler des données de la machine distante (faire des captures d'écran, faire du keylogging et autres choses désagréables) et il est même possible de modifier ces données.

Si vous souhaitez en savoir plus sur ces éléments, nous vous conseillons de lire la page de manuel Xsecurity ou la spécification d’extension X Security. De plus, vous pouvez vérifier les options ForwardX11 et ForwardX11Trusted dans votre/etc/ssh/ssh_config.

sources:

9
Stefan Rogin

Juste testé sur mon Mac, d'autres systèmes pourraient bien fonctionner :

  1. Autoriser les clients à se connecter depuis n'importe quel hôte à l'aide de xhost +

    $ xhost +

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

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

  3. Vous devriez laisser votre serveur ssh-server transmettre x11 afficher

    mettez à jour /etc/ssh/sshd_config et définissez X11Forwarding yes, puis redémarrez votre serveur ssh

  4. Vous devriez laisser votre session ssh transmettre x11 s’afficher avec le paramètre -X

    $ ssh -X utilisateur @ ip

  5. Comment ouvrir l'application X11 dans PyCharm?
    • ouvrir une session SSH qui supporte l'affichage X11 (n'oubliez pas de garder cette session)
    • lancer echo $DISPLAY dans cette session ssh
    • définir la variable d'environnement DISPLAY pour votre PyCharm
4
Color

Lors de l'exécution de UXTERM ou XTERM, il suffit d'émettre

export $DISPLAY

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

4
Oracle2066

Je devais mettre dans /etc/ssh/sshd_config ce qui suit:

X11UseLocalhost no

Plutôt que de le définir "oui". Étrange si la valeur par défaut est "NON" Utilisateurs qui utilisent PuTTY avec XMing sous Windows. J'utilise ssh directement sur Fedora. Parfois, il commençait à nous donner

error can't open display localhost

Le redémarrage du serveur permettrait généralement de le réparer, mais c'est stupide. Est-ce que ce qui précède, redémarré le service sshd sur le serveur et de nouvelles connexions fonctionnent à nouveau.

2
Luigi

J'ai également eu ce problème avec Solaris 10 et j'ai constaté que l'auditeur 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
Doug Somers

Sur CentOS 6.5, j'ai soudainement perdu l'accès aux programmes X distants après avoir manipulé/etc/hosts. Même symptôme de la variable vide $ DISPLAY (pas d’aide pour le paramétrer/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 être aussi 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ésolu ce problème, xeyes, xclock et d’autres jouets testés X fonctionnent à nouveau. Par conséquent, mon nécessaire virt-manager est également de retour en ligne.

1
David Ramirez

terminal ouvert $ ssh nomutilisateur @ nomhôte -X

$ ssh username@hostname -Y

$ export DISPLAY='IP:0.0'

export DISPLAY = "127.0.0.1:10.0" tout devrait fonctionner.

1
Kenny Gichuhi

Si vous utilisez Konsole, il vous suffit de passer à un autre émulateur de terminal, tel que Xfce Terminal, et d’essayer à nouveau avec root.

1
Oliver

Je viens de trouver un problème dans ma configuration qui empêchait le transfert x: mon pare-feu bloquait toutes les connexions de localhost, empêchant ainsi l'accès au tunnel.

1
Pelle

Après beaucoup de frustration, j'ai découvert que l'entrée pour le nom d'hôte du serveur dans son fichier/etc/Host était incorrecte.

0
iceburn_pt