Je me suis connecté à un serveur distant et j'essaie d'afficher une application x (par exemple, Firefox). mais un message d'erreur apparaît. ce qui suit sont mes tentatives pour ouvrir Firefox
Black@Black-PC ~
$ ssh -X kwagjj@$labserver -p 122
[kwagjj@James5 ~]$ firefox
Error: no display specified
[kwagjj@James5 ~]$ exit
logout
Connection to 143.248.146.204 closed.
Black@Black-PC ~
$ ssh -Y kwagjj@$labserver -p 122
[kwagjj@James5 ~]$ firefox
Error: no display specified
[kwagjj@James5 ~]$
J'ai utilisé -X, -Y car j'ai lu quelque part que ces deux options sont liées aux informations d'identification concernant X11 et ces commutateurs feront le travail pour moi. Même sans les commutateurs -X, -Y, ma tentative a échoué.
Que signifie l'erreur "aucun affichage spécifique"?
P.S. La chose étrange est que si je me connecte au serveur distant via mon PuTTY et que je répète la commande 'firefox' cela fonctionne?!?! (Firefox s'affiche sur l'ordinateur local)
P.S. mon ordinateur local est Windows 7, donc j'ai Xming en arrière-plan afin de permettre l'affichage X11. Quant à la tentative écrite en partie haute, les commandes ont été tapées sur le terminal Cygwin.
Assurez-vous que la variable DISPLAY est définie dans votre environnement cygwin:
export DISPLAY=:0.0
après la connexion avec SSH, vérifiez si Shell connaît également la variable DISPLAY correcte avec:
echo $DISPLAY
Je viens de rencontrer ce problème de connexion à un serveur RHEL7 sans tête.
Vous avez besoin du package xorg-x11-xauth installé sur votre hôte pour que la variable DISPLAY soit définie et correctement autorisée.
J'espère que j'ai sauvé quelqu'un du temps.
Merci à @jensd, @unxnut de m'avoir aidé. sur la base de vos commentaires, j'ai pu comprendre le problème.
La solution nécessitait deux étapes:
mes tentatives précédentes manquent d'une ou des deux conditions.
Quoi qu'il en soit, pour les utilisateurs ultérieurs qui voient cela, voici des exemples pour vous montrer ce que j'essaie de dire.
ma machine locale n'aura pas de variable DISPLAY définie. Et puis je vais ssh sur le serveur distant avec le commutateur -X, puis j'essaierai d'exécuter xclock
.
Black@Black-PC ~
$ echo $DISPLAY
## the blank means that DISPLAY variable has not been specified##
Black@Black-PC ~
$ ssh -X kwagjj@$labserver -p 122
Last login: Tue Jun 24 22:23:13 2014 from
[kwagjj@James5 ~]$ xclock
Error: Can't open display:
[kwagjj@James5 ~]$ setenv | grep $DISPLAY
DISPLAY: Undefined variable.
comme vous pouvez voir une erreur Error: Can't open display:
s'affiche sur le terminal du serveur distant.
cette fois, sur la machine locale, je spécifierai la variable DISPLAY. Mais quand je ssh'ing, je ne vais pas activer le commutateur -X. Le résultat sera un échec:
Black@Black-PC ~
$ export DISPLAY=:0.0
Black@Black-PC ~
$ echo $DISPLAY
:0.0
Black@Black-PC ~
$ ssh kwagjj@$labserver -p 122
Last login: Tue Jun 24 22:33:32 2014 from
[kwagjj@James5 ~]$ xclock
Error: Can't open display:
[kwagjj@James5 ~]$ setenv | grep DISPLAY
[kwagjj@James5 ~]$
au début, vous pouvez voir que j'ai correctement défini la variable DISPLAY. Mais même ainsi, après ssh'ing (sans le commutateur -X) la xclock n'est pas exécutée.
* Un résultat différent avec setenv | grep DISPLAY
peut être vu ici (comparer avec case1). dans case2, le résultat est juste vide. d'un autre côté, le résultat de case1 sur cette ligne de commande est DISPLAY: undefined variable
.... Je ne sais pas exactement comment cette différence est provoquée, mais j'obtiens un pressentiment qui est lié au fait que vous ayez satisfait à la condition 1. ou 2.
cette fois, je spécifierai correctement la variable DISPLAY sur la machine locale et également ssh sur le serveur distant avec mon commutateur -X activé.
Black@Black-PC ~
$ echo $DISPLAY
:0.0
Black@Black-PC ~
$ ssh -X kwagjj@$labserver -p 122
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Tue Jun 24 22:37:27 2014 from
[kwagjj@James5 ~]$ xclock &
[1] 9174
[kwagjj@James5 ~]$ setenv | grep DISPLAY
DISPLAY=localhost:11.0
[kwagjj@James5 ~]$
avec ce paramètre, xclock
fonctionne !! voici une capture d'écran pour prouver que je ne mens pas. l'horloge est affichée avec succès sur ma machine locale.
Encore une fois, consultez le résultat de setenv | grep DISPLAY
dans ce cas. Il montre maintenant DISPLAY=localhost:11.0
. D'après ce que je sais, cela est lié à MIT-MAGIC-COOKIE dans le fichier .Xauthority mais comme je ne sais pas grand-chose à ce sujet, je n'irai pas plus loin.
Conclusion: à partir des trois cas ci-dessus, nous pouvons confirmer que pour que X Windows distant s'affiche correctement, à la fois 1. Variable DISPLAY de la machine locale et 2. ssh -X
l'interrupteur doit être correctement réglé. Bien sûr, le serveur distant doit autoriser le transfert X11.
Un autre cas dans lequel j'ai rencontré ssh refusera de reporter le paramètre de variable DISPLAY même lorsque vous utilisez ssh -X:
$ ssh -X foo
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE Host IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
...
...
Add correct Host key in /home/jdoe/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/jdoe/.ssh/known_hosts:71
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
X11 forwarding is disabled to avoid man-in-the-middle attacks.
Si vous êtes quelqu'un qui lit le message complet que ssh vous crache, la réponse sera immédiatement évidente pour vous. Cependant, si vous êtes comme moi et que vous ne lisez pas toujours les messages extrêmement longs qui s'affichent lorsque vous vous connectez à un serveur distant, car ils ont configuré un sysadmin déjà long MOTD (Message du jour) ou une bannière d'avertissement similaire chaque fois que vous vous connectez. dans le système, vous pourriez facilement manquer ce message!
Le correctif consiste, bien sûr (ne fois que vous êtes certain que vous vous connectez réellement au système que vous pensez être !!), à modifier votre fichier "known_hosts" comme le suggère le message d'avertissement utile que vous (I) si diligemment ignoré lors de la connexion. Vous pouvez rencontrer cette situation lorsque vous avez des administrateurs réseau ou système qui ressentent le besoin de reconfigurer le réseau tous les quelques mois (sécurité d'emploi?).