Come posso correggere un errore "Impossibile aprire il display" quando apro un programma X dopo lo ssh'ing con l'inoltro X11 abilitato?

Dopo aver avviato l'app X11 (XQuartz 2.3.6, xorg-server 1.4.2-apple56) sul mio Mac (OS X 10.6.8), aprendo un terminale in X11 e in esecuzione xhost +, ho quindi il ssh -Ymio Ubuntu 10.04 VM (in esecuzione su VMware Fusione). Quando corro gedit .bashrc(per esempio), ottengo:

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

set | grep DISPLAY non restituisce nulla.

Ma se io ssh -Ynella mia macchina Ubuntu 11.04, gedit .bashrcfunziona. echo $DISPLAYrestituisce "localhost: 10.0".

Ho provato export DISPLAY=localhost:10.0mentre ero spinto nella mia macchina virtuale e poi in esecuzione gedit .bashrc, ma ottengo:

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

Cosa potrebbe esserci di diverso nella configurazione delle due macchine Ubuntu che spiegherebbero perché uno funziona e l'altro no?

Aggiornamento: come suggerito da Zoredache nel commento qui sotto, ho corso sudo apt-get install xbase-clients, ma continuo ad avere lo stesso problema.

Controlla il server sshd_config (normalmente /etc/ssh/sshd_config) e assicurati che l'opzione X11Forwarding sia abilitata con la linea

X11Forwarding yes

Se X11Forwarding non è specificato, il default è no sui computer Debian che ho a disposizione per controllare.

Da xhost +: Come risolvere l'errore "Impossibile aprire il display" durante l'avvio della GUI sul server remoto :

Risposta : È possibile correggere l'errore "Impossibile aprire il display" seguendo la procedura xhost menzionata in questo articolo.

Consenti ai client di connettersi da qualsiasi host utilizzando xhost +

Eseguire il comando seguente per disabilitare il controllo di accesso, mediante il quale è possibile consentire ai client di connettersi da qualsiasi host.

$ xhost +

controllo accessi disabilitato, i client possono connettersi da qualsiasi host

Abilita inoltro X11

Mentre fai ssh usa l'opzione -X per abilitare l'inoltro X11.

$ ssh username@hostname -X

Abilita l'inoltro X11 affidabile, utilizzando l'opzione -Y,

$ ssh username@hostname -Y

Apri le applicazioni della GUI in quell'host

Dopo aver aperto la connessione ssh all'host remoto come spiegato sopra, è possibile aprire qualsiasi applicazione GUI che la aprirà senza alcun problema.

Se viene ancora visualizzato l'errore "Impossibile aprire il display", impostare la variabile DISPLAY come mostrato di seguito.

$ export DISPLAY='IP:0.0'

Nota: IP è l'IP della workstation locale in cui si desidera visualizzare l'applicazione GUI.

Ho avuto questo problema anche quando accedevo a una macchina virtuale Ubuntu da Mac OS X: per qualche motivo, non mi piace 'localhost' nella variabile di visualizzazione. Quindi imposta manualmente l'IP, come suggerisce harrymc:

export DISPLAY="127.0.0.1:10.0"

Quindi i programmi X11 dovrebbero andare bene. Non sembra che dovrebbe essere necessario dire al sistema operativo che localhost e 127.0.0.1 sono equivalenti, ma funziona almeno.

Ho avuto questo problema con il mio server CentOS KVM, mi mancava il programma "xauth".

Se si riscontra questo problema dopo qualche tempo durante l'esecuzione con -Xarg. o semplicemente ForwardX11in / etc / ssh / ssh_config, quindi esegui $ ssh username@hostname -Y, per abilitare l' inoltro X11 di fiducia , non conosco la causa esatta, ma immagino che -Xalcune funzionalità scadano dopo qualche tempo, probabilmente per aumentare la sicurezza.

Ecco cosa ho trovato online:

Se si utilizza la macchina remota ssh -X, la macchina remota viene considerata come un client non attendibile. Quindi il client locale invia un comando al computer remoto e riceve l'output grafico. Se il tuo comando viola alcune impostazioni di sicurezza, riceverai invece un errore.

Ma se si utilizza la macchina remota ssh -Y, la macchina remota viene trattata come client attendibile. Quest'ultima opzione può aprire problemi di sicurezza. Perché un altro client grafico (X11) potrebbe annusare i dati dalla macchina remota (fare screenshot, fare keylogging e altre cose cattive) ed è persino possibile alterare quei dati.

Se vuoi saperne di più su queste cose ti suggerisco di leggere la manpage di Xsecurity o le specifiche dell'estensione di X Security. Inoltre puoi controllare le opzioni ForwardX11 e ForwardX11Trusted nel tuo / etc / ssh / ssh_config.

fonti:

• qual è la differenza tra ssh -Y e ssh -X
• avviso cygwin / X: impossibile aprire il display X.

Appena testato sul mio Mac, altri sistemi potrebbero essere a posto :

1. Consenti ai client di connettersi da qualsiasi host utilizzando xhost +

   $ xhost +

2. Dovresti avere un ambiente che supporti il ​​display X11

   [Sistema Mac] Installa X11 per mac https://www.xquartz.org/

3. Dovresti lasciare che il tuo server ssh inoltri il display x11

   aggiornare /etc/ssh/sshd_confige impostare X11Forwarding yes, quindi riavviare il server SSH

4. Si dovrebbe lasciare che la sessione ssh in avanti x11 venga visualizzata con il -Xparametro

   $ ssh -X utente @ ip

5. Come aprire l'app X11 in PyCharm?

   • aprire una sessione ssh che supporti il ​​display X11 (ricordarsi di mantenere questa sessione)
   • eseguire echo $DISPLAYin quella sessione SSH
   • imposta DISPLAYla variabile d'ambiente per il tuo PyCharm

Quando esegui UXTERM o XTERM basta emettere

export $DISPLAY 

La variabile sarà lì. Quindi basta impostarlo ed esportarlo.

Ho dovuto inserire /etc/ssh/sshd_configquanto segue:

X11UseLocalhost no

Piuttosto, impostarlo su "sì". Strano se il valore predefinito è "NO" Gli utenti che usano putty con XMing in Windows. Uso straight ssh su Fedora. Di tanto in tanto inizia a darci

error can't open display localhost

Il riavvio del server di solito lo risolveva, ma questo è stupido. Fatto quanto sopra, riavviato il servizio sshdsul server e presto nuove connessioni funzioneranno di nuovo bene.

Ho anche avuto questo problema con Solaris 10 e ho scoperto che l'ascoltatore non era impostato.

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

Su CentOS 6.5, improvvisamente ho perso l'accesso ai programmi X remoti dopo aver incasinato / etc / hosts. Stesso sintomo della variabile $ DISPLAY vuota (nessuna guida per l'impostazione / esportazione manuale).

È necessaria la voce 127.0.0.1 che punta al nome host effettivo; infatti l'ordine sembra essere anche rilevante (metti l'ultimo e non funzionerà ...)

[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

Dopo aver risolto questo problema, xeyes, xclock e altri giocattoli di prova X funzionano di nuovo, quindi anche il mio virt-manager necessario è di nuovo in linea.

Ho appena trovato un bel singhiozzo nella mia configurazione che ha impedito l'inoltro x: il mio firewall stava bloccando tutte le connessioni da localhost, impedendo così di raggiungere il tunnel

Se usi Konsole, passa a un altro emulatore di terminale come Xfce Terminal e riprova usando root.

aprire il terminale $ ssh username @ hostname -X

$ ssh username@hostname -Y

$ export DISPLAY='IP:0.0'

export DISPLAY = "127.0.0.1:10.0" tutto dovrebbe funzionare.

Questa configurazione funziona per me:

Locale (Cygwin a 64 bit su Windows 10) DISPLAY=:0

Server (Amazon EC2 RHEL 7.6) DISPLAY=:10.0

Queste impostazioni sono state trovate facendo clic su "X menu applicazioni su: 0" nella barra delle applicazioni e selezionando Strumenti di sistema> Terminale

Dopo molte frustrazioni ho scoperto che la voce per il nome host del server nel suo file / etc / host era errata.