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 en cours d'exécution xhost +, j'ai ensuite accédé ssh -Yà ma machine virtuelle Ubuntu 10.04 (s'exécutant sur VMware). La 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 j'entre ssh -Ydans ma machine Ubuntu 11.04, ça gedit .bashrcmarche. echo $DISPLAYrenvoie "localhost: 10.0".

J'ai essayé export DISPLAY=localhost:10.0tout 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 qui expliquerait pourquoi l'une fonctionne et l'autre pas?

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

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.

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

Réponse : 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 à l'aide de xhost +

Exécutez la commande suivante pour désactiver le contrôle d'accès, ce qui permet aux clients de 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

Ouvrir des 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.

J'ai eu ce problème lors de la connexion à une machine virtuelle Ubuntu à partir de Mac OS X également: il ne semble pas que "localhost" apparaisse dans la variable d'affichage 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.

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

Si vous rencontrez ce problème après un certain temps lorsque vous utilisez -Xarg. ou simplement ForwardX11dans / etc / ssh / ssh_config, puis exécutez $ ssh username@hostname -Y-vous pour activer le transfert X11 de confiance . Vous ne connaissez pas la cause exacte, mais je suppose que -Xcertaines fonctionnalités expirent après un certain temps, probablement pour renforcer 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:

• Quelle est la difference entre ssh -Y et ssh -X
• avertissement cygwin / X: impossible d'ouvrir l'écran X

Vient de tester 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

   mettre à jour /etc/ssh/sshd_configet configurer X11Forwarding yes, puis redémarrer votre serveur ssh

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

   $ 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)
   • courir echo $DISPLAYdans cette session ssh
   • définir DISPLAYla variable d'environnement pour votre PyCharm

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.

Je devais mettre dans /etc/ssh/sshd_configce qui suit:

X11UseLocalhost no

Plutôt que de le définir "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 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 sshdsur le serveur et de nouvelles connexions fonctionne à nouveau correctement.

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

Sur CentOS 6.5, j'ai soudainement perdu l'accès à des programmes X distants après avoir manipulé / etc / hosts. Même symptôme de la variable vide $ DISPLAY (pas d’aide pour sa configuration / exportation manuelle).

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.

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

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

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.

Cette configuration fonctionne pour moi:

Local (Cygwin 64 bits sous Windows 10) DISPLAY=:0

Serveur (Amazon EC2 RHEL 7.6) DISPLAY=:10.0

Ces paramètres ont été trouvés en cliquant sur "Menu des applications X sur: 0" dans la barre des tâches et en sélectionnant Outils système> Terminal.

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.