Come posso correggere un errore di "cannot open display" quando apro un programma X dopo aver ssh'ing con il forwarding X11 abilitato?

Da xhost+ : Come risolvere l'errore “Impossibile aprire la visualizzazione” durante il lancio dell'interfaccia grafica sul server remoto :

Risposta : È possibile correggere l'errore “cannot open display” seguendo la procedura xhost menzionata in questo articolo.

Consentire ai client di connettersi da qualsiasi host utilizzando xhost+

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

$ xhost +

controllo d'accesso disattivato, i client possono connettersi da qualsiasi host

Abilitare l'inoltro X11

Mentre si esegue ssh utilizzare l'opzione -X per abilitare l'inoltro X11.

$ ssh username@hostname -X

Abilitare l'inoltro X11 fidato, utilizzando l'opzione -Y,

$ ssh username@hostname -Y

Aprire le applicazioni 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 si ottiene ancora l'errore “cannot open display”, impostare la variabile DISPLAY come illustrato di seguito.

$ export DISPLAY='IP:0.0'

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

Controllare il sshd_config del server (normalmente /etc/ssh/sshd_config), e assicurarsi che l'opzione X11Forwarding sia abilitata con la linea

X11Forwarding yes

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

Ho avuto questo problema anche quando mi sono connesso ad una Ubuntu VM di Mac OS X - per qualche ragione non sembra piacermi ‘localhost’ nella variabile di visualizzazione. Quindi impostare l'IP manualmente, come suggerisce harrymc:

export DISPLAY="127.0.0.1:10.0"

Allora 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 KVM CentOS, mi mancava il programma “xauth”.

Se avete questo problema dopo un po’ di tempo quando si esegue con -X arg. o solo ForwardX11 in /etc/ssh/ssh_config, quindi eseguire $ ssh username@hostname -Y, per abilitare il fidato inoltro X11 , non so la causa esatta, ma immagino che con -X alcune caratteristiche scadono dopo qualche tempo, probabilmente per aumentare la sicurezza.

Ecco cosa ho trovato online :

Se si utilizza ssh -X remotemachine la macchina remota viene trattata come un client non fidato. Così il vostro client locale invia un comando alla macchina remota e riceve l'output grafico. Se il vostro comando viola alcune impostazioni di sicurezza riceverete invece un errore.

Ma se usate ssh -Y remotemachine la macchina remota viene trattata come un client di fiducia. Quest'ultima opzione può aprire problemi di sicurezza. Poiché altri client grafici (X11) potrebbero fiutare i dati dalla macchina remota (fare screenshot, fare keylogging e altre brutte cose) ed è anche possibile alterare quei dati.

Se volete saperne di più su queste cose vi suggerisco di leggere la manpage di Xsecurity o le specifiche dell'estensione X Security. Inoltre potete controllare le opzioni ForwardX11 e ForwardX11Trusted nelle vostre fonti /etc/ssh/ssh_config.

:

• qual è la differenza tra ssh -Y e ssh -X
• cygwin/X warning: non è stato possibile aprire il display X

Appena testato sul mio Mac, altri sistemi potrebbero essere OK :

1. 2. Consentire ai clienti di connettersi da qualsiasi host utilizzando xhost+

$ xhost +

1. 2. Dovreste avere un ambiente che supporti X11 display

[Mac System] Installare X11 per mac https://www.xquartz.org/

1. 3. Dovreste lasciare il vostro ssh-server forward x11 display

aggiornare /etc/ssh/sshd_config e impostare X11Forwarding yes, quindi riavviare il vostro ssh server

1. Dovreste lasciare la vostra sessione ssh forward x11 display con il parametro -X

$ ssh -X user@ip

1. Come aprire l'applicazione X11 in PyCharm?

• aprire una sessione ssh che supporta la visualizzazione X11 (ricordatevi di mantenere questa sessione)
• eseguire echo $DISPLAY in quella sessione ssh
• impostare la variabile d'ambiente DISPLAY per il vostro PyCharm

Ho dovuto inserire /etc/ssh/sshd_config il seguente:

X11UseLocalhost no
``` ```
error can't open display localhost

Piuttosto che impostarlo “sì”. Strano se il valore predefinito è “NO” Utenti che usano il mastice con XMing sotto Windows. Io uso ssh dritto su Fedora. Occasionalmente inizierebbe a darci

&001 &001

Il riavvio del server di solito lo risolverebbe, ma questo è stupido. Fatto quanto sopra, riavviato il servizio sshd sul server e presto nuove connessioni che funzionano di nuovo bene.

Quando si esegue UXTERM o XTERM basta emettere

export $DISPLAY

La variabile sarà presente. Poi basta impostarla ed esportarla.

Questa configurazione funziona per me:

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

Server (Amazon EC2 RHEL 7.6) DISPLAY=:10.0

Queste impostazioni sono state trovate cliccando su “X applications menu on :0” nella barra delle applicazioni e selezionando System Tools > Terminal

Ho avuto anche 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

Se vi capita di usare Konsole, passate semplicemente ad un altro emulatore di terminale come Xfce Terminal e riprovate usando root.

Su CentOS 6.5, ho improvvisamente perso l'accesso remoto ai programmi X dopo aver pasticciato con /etc/hosts. Stesso sintomo della variabile vuota $DISPLAY (nessun aiuto per impostarla/esportarla manualmente).

L'entrata 127.0.0.1 che punta al nome host effettivo è necessaria; infatti l'ordine sembra essere anche rilevante (metti per 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 sistemato questo, xeyes, xclock e altri giocattoli di prova X funzionano di nuovo, quindi anche il mio necessario virt-manager è tornato in linea.

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

aprire il terminale $ ssh username@hostname -X

$ ssh username@hostname -Y

$ export DISPLAY='IP:0.0'

export DISPLAY=“127.0.0.0.1:10.0” tutto dovrebbe funzionare.