wake-up-neo.net

Wie behebe ich einen Fehler "Kann Anzeige nicht öffnen", wenn ein X-Programm nach dem Senden mit aktivierter X11-Weiterleitung geöffnet wird?

Nachdem ich die X11-App (XQuartz 2.3.6, xorg-server 1.4.2-Apple56) auf meinem Mac (OS X 10.6.8) gestartet, ein Terminal in X11 geöffnet und xhost + ausgeführt habe, ssh -Y auf meinem Ubuntu 10.04 VM (läuft unter VMware Fusion). Wenn ich zum Beispiel gedit .bashrc ausführe, erhalte ich:

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

set | grep DISPLAY gibt nichts zurück.

Aber wenn ich ssh -Y in meinen Ubuntu 11.04-Rechner einbinde, funktioniert gedit .bashrc. echo $DISPLAY gibt "localhost: 10.0" zurück.

Ich habe versucht, export DISPLAY=localhost:10.0 in mein VM zu kopieren und dann gedit .bashrc auszuführen, aber ich erhalte:

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

Was könnte an der Konfiguration der beiden unterschiedlichen Ubuntu-Maschinen anders sein, was erklären würde, warum eine funktioniert und die andere nicht?

Update: Wie von Zoredache im Kommentar unten vorgeschlagen, habe ich Sudo apt-get install xbase-clients ausgeführt, aber ich habe weiterhin das gleiche Problem.

98
Daryl Spitzer

Überprüfen Sie die sshd_config des Servers (normalerweise /etc/ssh/sshd_config) und stellen Sie sicher, dass die Option X11Forwarding für die Zeile aktiviert ist

X11Forwarding yes

Wenn X11Forwarding nicht angegeben ist, ist der Standardwert Nein auf den Debian-Maschinen, die ich überprüfen kann.

39
DerfK

Von xhost +: So beheben Sie den Fehler "Anzeige kann nicht geöffnet werden" beim Starten der GUI auf dem Remote-Server :

Answer : Sie können den Fehler "Kann Anzeige nicht öffnen" beheben, indem Sie die in diesem Artikel beschriebene xhost-Prozedur ausführen.

Clients erlauben, von jedem Host aus eine Verbindung mit xhost herzustellen +

Führen Sie den folgenden Befehl aus, um die Zugriffssteuerung zu deaktivieren, mit der Sie Clients erlauben können, von jedem Host aus eine Verbindung herzustellen.

$ xhost +

wenn die Zugriffskontrolle deaktiviert ist, können Clients von jedem Host aus eine Verbindung herstellen

X11-Weiterleitung aktivieren

Verwenden Sie dabei die Option -X, um die X11-Weiterleitung zu aktivieren.

$ ssh [email protected] -X

Aktivieren Sie die vertrauenswürdige X11-Weiterleitung mit der Option -Y.

$ ssh [email protected] -Y

GUI-Anwendungen auf diesem Host öffnen

Nachdem Sie die SSH-Verbindung zum Remote-Host wie oben beschrieben hergestellt haben, können Sie eine beliebige GUI-Anwendung öffnen, die diese ohne Probleme öffnet.

Wenn der Fehler "Anzeige kann nicht geöffnet werden" weiterhin angezeigt wird, setzen Sie die Variable DISPLAY wie unten gezeigt.

$ export DISPLAY='IP:0.0'

Hinweis: IP ist die IP-Adresse der lokalen Arbeitsstation, auf der die GUI-Anwendung angezeigt werden soll.

54
harrymc

Ich hatte dieses Problem, als ich mich von Mac OS X aus bei Ubuntu VM anmeldete - aus irgendeinem Grund scheint 'localhost' in der Anzeigevariable nicht zu gefallen. So stellen Sie die IP manuell ein, wie Harrymc vorschlägt:

export DISPLAY="127.0.0.1:10.0"

Dann sollten X11-Programme in Ordnung sein. Es scheint nicht notwendig zu sein, dem Betriebssystem mitzuteilen, dass localhost und 127.0.0.1 gleichwertig sind, aber es funktioniert zumindest.

17
spinup

Ich hatte dieses Problem mit meinem CentOS KVM Server, mir fehlte das "xauth" Programm.

13
Joril

Wenn Sie dieses Problem haben nach einiger Zeit beim Ausführen mit -X arg. oder einfach ForwardX11 in/etc/ssh/ssh_config, dann $ ssh [email protected] -Y ausführen, um vertrauenswürdige X11-Weiterleitung zu aktivieren, die genaue Ursache ist nicht bekannt, aber ich vermute, dass mit -X einige Funktionen nach einiger Zeit ablaufen, wahrscheinlich zu Sicherheit erhöhen.

Folgendes habe ich online gefunden:

Wenn Sie die Remotemachine ssh -X verwenden, wird der Remotecomputer als nicht vertrauenswürdiger Client behandelt. Ihr lokaler Client sendet also einen Befehl an den Remote-Computer und empfängt die grafische Ausgabe. Wenn Ihr Befehl gegen einige Sicherheitseinstellungen verstößt, erhalten Sie stattdessen eine Fehlermeldung.

Wenn Sie jedoch die Remotemachine ssh -Y verwenden, wird der Remotecomputer als vertrauenswürdiger Client behandelt. Diese letzte Option kann zu Sicherheitsproblemen führen. Da andere grafische Clients (X11) Daten von der Remote-Maschine abrufen können (Screenshots erstellen, Keylogging und andere unangenehme Dinge ausführen) und es sogar möglich ist, diese Daten zu ändern.

Wenn Sie mehr über diese Dinge erfahren möchten, empfehlen wir Ihnen, die Xsecurity-Manpage oder die X Security-Erweiterungsspezifikation zu lesen. Außerdem können Sie die Optionen ForwardX11 und ForwardX11Trusted in Ihrer/etc/ssh/ssh_config überprüfen.

quellen:

9
Stefan Rogin

Gerade auf meinem Mac getestet, andere Systeme könnten in Ordnung sein :

  1. Clients erlauben, von jedem Host aus eine Verbindung mit xhost + Herzustellen

    $ xhost +

  2. Sie sollten eine Umgebung haben, die X11-Anzeige unterstützt

    [Mac System] Installieren Sie X11 für Mac https://www.xquartz.org/

  3. Sie sollten Ihren SSH-Server x11-Anzeige weiterleiten lassen

    /etc/ssh/sshd_config aktualisieren und X11Forwarding yes einstellen, dann den ssh-server neu starten

  4. Sie sollten Ihre ssh-Sitzung mit dem -X-Parameter X11 weiterleiten lassen.

    $ ssh -X user @ ip

  5. Wie öffne ich die X11-App in PyCharm?
    • Öffnen Sie eine SSH-Sitzung, die X11-Anzeige unterstützt (denken Sie daran, diese Sitzung beizubehalten).
    • führen Sie in dieser SSH-Sitzung echo $DISPLAY aus
    • setze DISPLAY umgebungsvariable für dein PyCharm
4
Color

Beim Ausführen von UXTERM oder XTERM nur ausstellen

export $DISPLAY 

Die Variable wird dort sein. Dann einfach einstellen und exportieren.

4
Oracle2066

Ich musste folgenden /etc/ssh/sshd_config eingeben:

X11UseLocalhost no

Setzen Sie es lieber auf "Ja". Seltsam, wenn die Standardeinstellung "NEIN" ist. Benutzer, die PuTTY mit XMing unter Windows verwenden. Ich benutze gerade ssh über Fedora. Gelegentlich gab es uns etwas

error can't open display localhost

Ein Neustart des Servers würde normalerweise das Problem beheben, aber das ist blöd. Habe das oben angeführte getan, den Dienst sshd auf dem Server neu gestartet und dafür gesorgt, dass neue Verbindungen wieder einwandfrei funktionieren.

2
Luigi

Ich hatte auch dieses Problem mit Solaris 10 und stellte fest, dass der Listener nicht eingerichtet war.

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

Unter CentOS 6.5 verlor ich plötzlich den Zugriff auf entfernte X-Programme, nachdem ich mit/etc/hosts rumgespielt hatte. Gleiches Symptom für leere Variable $ DISPLAY (keine Hilfe beim manuellen Einstellen/Exportieren).

Der 127.0.0.1-Eintrag, der auf den tatsächlichen Hostnamen verweist, ist erforderlich. in der Tat scheint die Reihenfolge auch relevant zu sein (zuletzt & es wird nicht funktionieren ...)

[[email protected] /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

Nachdem dies behoben wurde, funktionieren xeyes, xclock und andere X-Testspielzeuge wieder, daher ist mein benötigter virt-manager auch wieder online.

1
David Ramirez

Öffnen Sie das Terminal $ ssh Benutzername @ Hostname -X

$ ssh [email protected] -Y

$ export DISPLAY='IP:0.0'

export DISPLAY = "127.0.0.1:10.0" sollte alles funktionieren.

1
Kenny Gichuhi

Wenn Sie Konsole verwenden, wechseln Sie einfach zu einem anderen Terminal-Emulator wie Xfce Terminal und versuchen Sie es erneut mit root.

1
Oliver

Ich habe gerade ein Problem in meinem Setup festgestellt, das die Weiterleitung von x verhindert hat: Meine Firewall hat alle Verbindungen von localhost blockiert und somit verhindert, dass der Tunnel erreicht wird

1
Pelle

Nach einiger Frustration stellte ich fest, dass der Eintrag für den Hostnamen des Servers in seiner/etc/Host-Datei falsch war.

0
iceburn_pt