-X flag (X11 Forwarding) non sembra funzionare in Windows

16

Sto usando Open SSH (OpenSSH_6.6.1p1, OpenSSL 1.0.1i 6 ago 2014) in Windows 8.1. X11 Forwarding non sembra funzionare. La variabile di ambiente DISPLAY non sembra essere impostata.

Ad esempio, se uso BitVise o Putty per connettermi ed eseguo env, vedo:

[marko@vm:~]$ env
XDG_SESSION_ID=6
TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=192.168.1.174 61102 22
SSH_TTY=/dev/pts/0
USER=marko
MAIL=/var/mail/marko
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
PWD=/home/marko
LANG=en_CA.UTF-8
NODE_PATH=/usr/lib/nodejs:/usr/lib/node_modules:/usr/share/javascript
SHLVL=1
HOME=/home/marko
LANGUAGE=en_CA:en
LOGNAME=marko
SSH_CONNECTION=192.168.1.174 61102 192.168.1.64 22
XDG_RUNTIME_DIR=/run/user/1000
DISPLAY=localhost:10.0
_=/usr/bin/env

Se invece utilizzo OpenSSH (ssh -X marko @ vm):

[marko@vm:~]$ env
XDG_SESSION_ID=8
TERM=cygwin
SHELL=/bin/bash
SSH_CLIENT=192.168.1.174 61150 22
SSH_TTY=/dev/pts/1
USER=marko
MAIL=/var/mail/marko
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
PWD=/home/marko
LANG=en_CA.UTF-8
NODE_PATH=/usr/lib/nodejs:/usr/lib/node_modules:/usr/share/javascript
SHLVL=1
HOME=/home/marko
LANGUAGE=en_CA:en
LOGNAME=marko
SSH_CONNECTION=192.168.1.174 61150 192.168.1.64 22
XDG_RUNTIME_DIR=/run/user/1000
_=/usr/bin/env
ssh  x11 
— Abendigo
fonte
1
Potrebbe essere ovvio, ma non posso dirlo con certezza dal tuo post - hai effettivamente un server X installato su Windows, ad esempio seguendo bitvise.com/ssh-x11-forwarding ?
1
Sì, ho Xming X Server ( straightrunning.com/xmingnotes )
— abendigo
Hai - solo per testare le cose - provato lo stesso con PuTTY? Altrimenti, suggerisco di provarci e di vedere se funziona lì.
— polemon,
1
sì, funziona in stucco.
— abendigo,
Sto verificando la mia macchina virtuale Windows in questo momento. Potrebbe essere semplice come controllare quale tipo di variabili PuTTY imposta per farlo funzionare. Aggiungerò una risposta tra un paio d'ore.
— polemon,

Risposte:

16

Hai impostato DISPLAYla variabile di ambiente sul client? Non sono sicuro di quale shell stai usando, ma con la derivata della shell Bourne (come bash), prova:

export DISPLAY=127.0.0.1:0
ssh -X marko@vm

O se stai usando cmd.exe:

set DISPLAY=127.0.0.1:0
ssh -X marko@vm
— Yaegashi
fonte
Grazie, questo è esattamente quello che mi mancava! Assegnerò la taglia non appena mi sarà permesso.
— abendigo,
Nota che ho votato a favore della risposta di Roaima (di seguito) perché descrive il perché oltre a dare una risposta.
— Azhrei l'
2
Quindi la risposta di roaima spiega perché si è verificato il problema, ma non mi ha aiutato a risolverlo. Ho spiegato nella mia domanda che stavo eseguendo Windows. La risposta di Yaegashi mi ha dato un comando per entrare su Windows che ha risolto il mio problema. ecco perché ho selezionato questa risposta.
— abendigo,
Ho registrato un account solo per votare questa risposta. Avevo cercato su Internet molto prima di arrivare qui.
— Rio Wing
3
Questa soluzione non funziona per me. set DISPLAY=anythingseguito da ssh -X user@remoteritorni CreateProcessW failed error:2 ssh_askpass: posix_spawn: No such file or directory Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).Disattivare la variabile d'ambiente con set DISPLAY=mi permette di eseguire nuovamente ssh con successo, ma senza lavorare all'inoltro X. Non ha senso per me che l'impostazione DISPLAY dovrebbe far sì che il software richieda la mia password in questo modo. github.com/PowerShell/Win32-OpenSSH/issues/1088 github.com/PowerShell/Win32-OpenSSH/issues/1088
— Pavel Komarov
14

Quando corri ssh -X remotehoste vieni DISPLAY=localhost:10presentato all'host remoto. sshascolta su quella porta e inoltra il traffico al sistema chiamante, usando il suo valore originale di DISPLAYper determinare l'indirizzo del server.

È probabile che sul tuo sistema locale tu abbia DISPLAY=:0. O se non l'hai fatto, è quello che viene impostato come predefinito. Ciò indica al sistema locale di utilizzare il socket del dominio UNIX per comunicare con il display. Sfortunatamente Xmingsu Windows non imposta quel socket di dominio UNIX quindi il tuo sshinoltro X11 fallisce con questo tipo di errore:

$ export DISPLAY=:0
$ ssh -X remotehost xlogo
connect /tmp/.X11-unix/X0: No such file or directory
Error: Can't open display: localhost:10.0

La correzione - almeno per quanto riguarda Xming- è abbastanza semplice. Modificare la DISPLAYvariabile per fare riferimento a un socket TCP in ascolto anziché a un socket di dominio UNIX.

$ export DISPLAY=localhost:0
$ ssh -X remotehost xlogo

Potrebbe essere necessario adattare la Xmingconfigurazione per l'ascolto sulla porta TCP locale 6000. Ecco come iniziare Xming:

Xming.exe :0 -clipboard -multiwindow

Ed ecco le prove per confermare che Xmingè in ascolto sulla porta tcp / 6000:

$ netstat -na | grep ':6000 .*LISTEN'
  TCP    0.0.0.0:6000           0.0.0.0:0              LISTENING
— roaima
fonte
Grazie, ho avuto questo esatto problema! Non sapevo che: 0 significa che la connessione viene effettuata tramite un socket. Ho sempre pensato che fosse solo una scorciatoia per localhost: 0.
— Andreas Raster,
Ho avuto lo stesso problema con Bash per Ubuntu per Windows e Xming, e questo ha risolto! Ho dovuto solo impostare DISPLAY su localhost:0.
— Ben Richards,
Qualche idea sul perché DISPLAY=:0funzioni bene su WSL + XMing per xeyes, ma non per ssh -X? Non ssh -Xinterpretare $ DISPLAY in modo diverso da altri client X11 locali? Gli altri client X11 ritornano automaticamente a, localhost:0ma ssh -Xnon lo fanno?
— Markus Kuhn,
Su man Xdice che il nome host vuoto in DISPLAY =: 0 significa "Verrà scelto il trasporto locale più efficiente." Quindi si può ssh -Xusare un algoritmo diverso per farlo rispetto a dire xeyes?
— Markus Kuhn,
@MarkusKuhn forse WSL + Xming è diverso da Cygwin + Xming. Vedo che ora lo sto usando DISPLAY=:0e lo ssh -Xinoltra felicemente.
— roaima,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.