J'utilise Open SSH (OpenSSH_6.6.1p1, OpenSSL 1.0.1i 6 août 2014) dans Windows 8.1. Le transfert X11 ne semble pas fonctionner. La variable d'environnement DISPLAY ne semble pas être définie.
Par exemple, si j'utilise BitVise ou Putty pour me connecter et exécuter env, je vois:
[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
Si j'utilise plutôt 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
Réponses:
Avez-vous défini
DISPLAY
une variable d'environnement sur le client? Je ne sais pas quel shell vous utilisez, mais avec le dérivé du shell Bourne (comme bash), veuillez essayer:Ou si vous utilisez cmd.exe:
la source
set DISPLAY=anything
suivi dessh -X user@remote
retours LaCreateProcessW failed error:2 ssh_askpass: posix_spawn: No such file or directory Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
suppression de la variable d'environnement avecset DISPLAY=
me permet de réussir ssh à nouveau, mais sans travailler avec le transfert X. Cela n'a aucun sens pour moi que le réglage de DISPLAY devrait amener le logiciel à demander mon mot de passe de cette façon. github.com/PowerShell/Win32-OpenSSH/issues/1088 github.com/PowerShell/Win32-OpenSSH/issues/1088Lorsque vous exécutez
ssh -X remotehost
et que vous êtesDISPLAY=localhost:10
présenté à l'hôte distant.ssh
écoute sur ce port et retransmet le trafic vers le système appelant, en utilisant sa valeur d'origine deDISPLAY
pour déterminer l'adresse du serveur.Il est probable que vous en ayez sur votre système local
DISPLAY=:0
. Ou si vous ne l'avez pas fait, c'est ce qui est par défaut. Cela indique au système local d'utiliser le socket de domaine UNIX pour communiquer avec l'écran. Malheureusement,Xming
sous Windows ne configure pas ce socket de domaine UNIX, votressh
transfert X11 échoue avec ce type d'erreur:La solution - du moins pour autant
Xming
- est assez simple. Modifiez laDISPLAY
variable pour référencer un socket TCP d'écoute plutôt qu'un socket de domaine UNIX.Vous devrez peut-être adapter votre
Xming
configuration pour écouter sur le port TCP local 6000. Voici comment commencerXming
:Et voici des preuves pour confirmer que vous
Xming
écoutez sur le port TCP / 6000:la source
localhost:0
.DISPLAY=:0
fonctionne bien sur WSL + XMing pourxeyes
, mais pas pourssh -X
? Est -ssh -X
interprète $ DISPLAY différemment des autres clients locaux X11? Les autres clients X11 se replient-ils automatiquementlocalhost:0
maisssh -X
ne le font pas?man X
y dit que le nom d'hôte vide dans DISPLAY =: 0 signifie "Le transport local le plus efficace sera choisi." Alors peut-êtressh -X
utilise un algorithme différent pour le faire par rapport à direxeyes
?DISPLAY=:0
et lessh -X
transmet avec bonheur.Avec ssh dans Windows10 et Xming, je semble obtenir de "bons" résultats (?) Avec:
et créer un objet C: \ dev \ tty par exemple avec
et en utilisant
ssh -Y
(nonssh -X
).la source