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é?

112

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.

Daryl Spitzer
la source
2
La boîte Ubuntu 10.04 dispose-t-elle des outils appropriés pour X11? Installez xbase-clients, s'il n'est pas déjà installé.
Zoredache
Je l'ai installé mais j'ai toujours le même problème. (Voir ci-dessus.)
Daryl Spitzer
3
Essayez peut-être de passer l'option -vv à ssh lors de la connexion. Ceci affiche les messages de débogage détaillés, vous devriez voir plusieurs commentaires sur le transfert X11 lors de la connexion.
Zoredache
1
@jcrawfordor Vous avez vérifié le X11Forwardingsur ubuntu, que vous avez xbase-clientsinstallé et que vous pouvez démarrer Xapps sur le mac sur le terminal à partir duquel vous établissez une connexion ssh. (Vérifiez que $DISPLAYest situé sur le terminal que vous exécutez ssh à partir .
Manwe
1
Dans mon cas, il s’agissait simplement de mettre à niveau la version XQuartz de MacOS
Waruna Ranasinghe,

Réponses:

48

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.

DerfK
la source
4
Après avoir configuré une autre machine virtuelle Ubuntu, j'ai découvert qu'il me fallait à la fois installer xbase-clients et activer X11Forwarding. Mettez à jour votre réponse pour inclure les deux et je l'accepterai.
Daryl Spitzer
1
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 valeurs par défaut.
Zoredache
29
@DerfK, dans mon système "X11Forwarding yes" était déjà là, je reçois toujours une erreur en tant que, (gedit: 8381): Gtk-WARNING **: impossible d'ouvrir display: dans de tels cas
AJ
1
Sur Debian, vous devrez peut-être installer le paquet xauth, puis vous reconnecter.
Comte
$ ssh nom_utilisateur @ nom_hôte -Ya a fonctionné pour moi
MarcoZen le
61

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.

harrymc
la source
12
+1 pour la note indiquant que IP = est l'adresse IP du poste de travail local sur lequel vous souhaitez obtenir l'interface graphique
PCoder
3
Pour ceux qui ont des problèmes similaires sur OS X, assurez-vous également que XQuartz est installé, sinon aucun de ces correctifs n’aide. (La question de l' OP montre qu'il a XQuartz, donc c'est plus une note de côté à ceux ayant des problèmes similaires comme je l' étais)
Dolan Antenucci
3
Notez que le fonctionnement xhost +est très dangereux et ne doit pas être utilisé! Comme Stefan Rogin l’a mentionné, l’attaquant peut alors, à partir de l’hôte, se connecter à votre XSession, lire tout ce que vous tapez, ou même modifier l’écran que vous voyez.
jirislav
le dernier l'a export Display=IP:0.0fait pour moi
javadba
Pour une raison quelconque, -Yça fonctionne, -Xça ne marche pas.
ibic
18

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.

Tournoiement en haut
la source
Cela a fonctionné pour moi. Une idée pourquoi Localhost ne fonctionnait pas?
Alex
2
BINGO! Je suis bloqué par ce problème depuis un certain temps ... Je me suis connecté par SSH et je ne pouvais pas lancer de programmes Gtk (X11, comme "xeyes", fonctionnait bien). AFFICHAGE était correct. En fait, la résolution de "localhost" ne l'était pas! Si je règle manuellement DISPLAY = 127.0.0.1: 10.0, ou DISPLAY = :: 1: 10.0, cela fonctionne. Éditer / etc / hosts semble n'avoir aucun effet; et le DNS est correctement configuré ("dig localhost" rapporte correclty 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
1
Sur une installation Debian pour Beagle Bone Black, / etc / host n’a pas été défini comme lisible par quiconque, sauf root. Cela a provoqué les symptômes rapportés ici. Faites en sorte que / etc / hosts soit lisible par tous, et cela a bien fonctionné.
Daniel
13

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

Joril
la source
1
Cela m'a aidé sur mon installation minimale de Debian, merci beaucoup!
binOu
9

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:

Stefan Rogin
la source
6

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
Couleur
la source
1
Pourquoi est-ce différent ou pourquoi devrait-il être préféré à une autre réponse? S'il vous plaît expliquer si vous pouvez avec une simple modification . Tu peux le faire!!
Pimp Juice IT
@ McDonald's Merci, mis à jour avec plus de détails.
Couleur
4

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.

Oracle2066
la source
4

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.

Luigi
la source
2

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
Doug Somers
la source
1

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.

David Ramirez
la source
1

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.

Pelle
la source
1

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

Oliver Dechant
la source
1

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.

Kenny Gichuhi
la source
Merci. Fonctionne pour mon cas particulier quand DISPLAY='localhost:10.0'ne fonctionne pas.
xpt
1

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.

qwr
la source
0

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.

iceburn_pt
la source