Hi,
I log in an AIX worstation using ssh -X mode but, although I have xhost + and copy my .Xauthority on the remote server, xclock or other graphic command returns me a laconic "Error : can't open DISPLAY..."
The $DISPLAY is well set...
I have also set off the -nolisten tcp option ...
so I don't see any solution...
Could it be a problem with the firewall ?
Forum général.général Kubuntu 5.04 : can't open display from an aix worstation
27
juil.
2005
# LinuxFR
Posté par Christophe Chailloleau-Leclerc . Évalué à 3.
as the name of the site should suggest, you're on a french speaking only site...
Because a lot of readers could understand english also, you may have answers to your questions, but I think that for most people on this site, this is just disturbing and of no interest.
Could I suggest you to post your questions on one of the many linux related sites using Shakespeare's language as their default ?
Regards,
Christophe
[^] # Re: LinuxFR
Posté par Yo_sensei . Évalué à 2.
oui c'est vrai, surtout pour un frenchie, désol'... j'ai juste recopié un post Anglais que j'ai fais dans un autre forum ... sur Ubuntu.fr en fait.
Mais le niveau de réponse n'égale pas linuxfr... so ;-)
Encore désol'.
[^] # Re: LinuxFR
Posté par Christophe Chailloleau-Leclerc . Évalué à 5.
Décidemment, je vais croire le message en dessous ! ;-)
Sans rancune !
[^] # Re: Linux.en_FR
Posté par Obsidian . Évalué à 4.
http://linuxfr.org/comments/605485.html#605485(...)
We'll also be really laughing out loud when we realize that he also managed to write two different forum entries simultaneously then post them exactly at the same time (check the clocks) :
http://linuxfr.org/forums/12/10374.html(...)
http://linuxfr.org/forums/12/10373.html(...)
Say, Yo_sensei, are you on drugs ? :-)
[^] # Re: Linux.en_FR
Posté par Yo_sensei . Évalué à 1.
Bon mais ça ne répond pas à ma question tout ça...:-(
# ssh -X
Posté par Ramón Perez (site web personnel) . Évalué à 2.
Avec 'ssh -X' il ne faut pas faire de "xhost +", ni de "export DISPLAY".
C'est ssh qui crée comme un grand un tunnel pour le X11.
>The $DISPLAY is well set...
C'est à dire ? C'est toi qui l'as mis ou ssh ?
[^] # Re: ssh -X
Posté par Obsidian . Évalué à 2.
Auquel cas les applications graphiques tenteraient encore de s'ouvrir vers le mauvais canal. Tu peux également essayer d'attaquer le port X-Window local à ton serveur avec un telnet. C'est sauvage mais cela te permettra de vérifier s'il est bien ouvert.
# X sous SSH
Posté par JJD . Évalué à 4.
Avec l'option -X du client SSH tu ne devrais rien avoir à faire pour pouvoir affichier des applications distantes sur ton display.
Quelques points cependant à vérifier :
- il ne faut pas que tu fixes manuellement la variable DISPLAY dans ta session distante. ssh se débrouille comme un grand pour fixer le DISPLAY qui va bien (normalement DISPLAY est positionné à localhost:10.0 si ton DISPLAY local est :0.0). C'est également ssh qui va se charger de mettre les bonnes données dans .Xauthority.
- dans la conf du serveur ssh (/etc/sh/sshd_config), il faut que la directive "X11Forwarding" soit positionnée à "yes", sinon ça ne peut pas marcher.
- sur le serveur, il fut trouver le programme xauth dans /usr/bin/X11/xauth, sinon il est nécessaire de le préciser dans sshd_config avec la directive XAuthLocation (le chemin par défaut peut être différent).
Pour faire un diagnostic plus précis : quand tu te connectes avec l'option -X, est-ce que la variable DISPLAY est bien positionnée ?
Si ce n'est pas le cas, vérifie les fichiers de conf ("man sshd_config" peut bien t'aider).
Tu peux également lancer ssh avec l'option -v (ou -vv ou -vvv) pour avoir une trace de parlante et essayer de comprendre ce qui ne marche pas.
Bonne chance
JJD
[^] # Re: X sous SSH
Posté par Yo_sensei . Évalué à 3.
- "X11Forwarding" est bien positionné à yes
- xauth est bien dans /usr/bin/X11/xauth
Par contre le display est positionné à mon IP sur le serveur distant et non à localhost:10.0...
Ceci dit, le changement via export DISPLAY=localhost:10.0 n'a rien donné...
pas glop !
[^] # Re: X sous SSH
Posté par Ramón Perez (site web personnel) . Évalué à 4.
Donc quelque chose (un script lancé à la connexion ?) change ta variable DISPLAY. Il faut que tu vires ça.
>Ceci dit, le changement via export DISPLAY=localhost:10.0 n'a rien donné...
Ce n'est pas forcément 10. Ca va (normalement) de 10 à 19.
[^] # Re: X sous SSH
Posté par JJD . Évalué à 4.
[la valeut xx dépend de la directive X11DisplayOffset de sshd_config sur ton AIX, normalement positionnée à 10]
Essaie donc de regarder dans les scripts exécutés au lancement (.profile et /etc/pofile en particulier si le shell est ksh).
Si tu ne vois rien de particulier, tu peux toujours essayer de nous envoyer la sortie que tu obtiens lors d'une connexion avec l'option -vv (et -X évidemment).
@+
JJD
[^] # Re: X sous SSH
Posté par Yio . Évalué à 3.
Bref, merci pour toutes ces réponses, je retesterais demain.
Par contre, juste pour alimenter le débat :
- Si je me loggue sur un autre serveur linux, no pb, l'affichage X me revient bien
- un collègue (sous Mandrake) arrive à se logger sur le serveur AIX via ssh et reçoit la sortie X
- un autre (sous Ubuntu comme moi) a le même pb...
Et oui, il y a bien un .profile sur mon compte AIX appartenant à root et chargeant un profile.common qui fixe le DISPLAY à l'IP qu'il reçoit à la connection...
Je vais demander aux administrateurs de me virer ça...
En tout cas, merci pour vos réponses.
Et sans rancune à LinuxFR :-)
[^] # Re: X sous SSH
Posté par Yo_sensei . Évalué à 1.
Voici la sortie -vv de mon ssh concernant la connection X. Si qqn a une idée...
debug2: x11_get_proto: /usr/bin/X11/xauth list :0.0 . 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
[^] # Re: X sous SSH
Posté par JJD . Évalué à 2.
Est-ce que tu as pu modifier les scripts d'initialisation (.profile) pour ne pas forcer la variable DISPLAY?
Si oui, que vaut cette variable ?
La directive X11DisplayOffset apparaît-elle dans le fichier sshd_config du serveur ?
Que te donne, sur le serveur, la commande "xauth list" ?
Est-ce que tu as un fichier .Xauthority sur l'AIX ?
Quels sont les droits sur ce fichier ?
(question bête : tu as bien le droit d'écriture dans ton HOME sur le serveur ? : je demande ça à tout hazard, parce que tu as dit que ton .profile appartenait à root)
Tu as dit qu'un de tes collègues pouvait se connecter au serveur AIX et lancer des applications graphiques : que vaut alors la variable DISPLAY et que donne "xauth list". Il est fort possible, vu ce que tu as déjà écrit, que la connexion X11 ne passe pas du tout pas un tunnel SSH mais par une simple connexion TCP. Si c'est le cas, tu peux essayer de faire la même chose en faisant :
1) sur ta machine cliente, tu récupère le cookie d'autorisation avec :
xauth list localhost:0
tu devrais avoir une sortie avec nom_de_ta_machine MIT-MAGIC-COOKIE-1 <chaine de 32 caractères>.
2) Ensuite, sur le serveur AIX tu tapes :
export DISPLAY=<IP machine cliente>:0
xauth add <IP machine cliente>:0 MIT-MAGIC-COOKIE-1 <chaine de 32 caractères>
Et tu testes : comme tu as déjà viré l'option -nolisten tcp ça devrait marcher, mais ça n'a alors plus rien à voir avec du tunneling ssh (ça marcherait de la même façon avec une connexion telnet ou rlogin).
Cela signifie que les paquets X11 passent en clair sur le réseau, mais sur un réseau local d'entreprise le risque est tout de même minime.
JJD
[^] # Re: X sous SSH
Posté par Yio . Évalué à 1.
- j'ai bien le droit d'écrire dans mon home (seul le .profile appartient à root, histoire d'homogénéiser les comptes...)
- une fois le .profile by-passer, $DISPLAY est mis à blanc via ssh...
-xauth list ne donne rien côté AIX, j'ai donc créé la liste avec mon IP mais sans plus de succès.
A signaler : une connection telnet sur le serveur AIX ne donne pas plus de résultat... les applications X ne passent tjs pas
[^] # Re: X sous SSH
Posté par JJD . Évalué à 2.
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
[le numéro de port doit être 6000 + numéro de display]
Si cette ligne n'apparaît pas ou si X écoute seulement sur l'interface locale (127.0.0.1 au lieu de 0.0.0.0) ça ne peut pas fonctionner avec une connexion telnet.
Que vaut DISPLAY et que donne "xauth list" sur l'AIX lorsque ton collègue sous Mandrake s'y connecte ? (pour savoir si le tunneling SSH du protocole X11 est utilisé et fonctionne).
[^] # Re: X sous SSH
Posté par Yio . Évalué à 1.
j'ai fait un "netstat -an | grep 6000"
Que faut-il faire pour le configurer ?
Le DISPLAY chez mon collègue sous Mandrake vaut son IP lorsqu'il se loggue en ssh sur le serveur AIX...
Son xauth.list ne contient qu'une ligne sur une IP qui n'est pas la sienne ni celle du serveur AIX... je me demande si Xauthority est bien utilisé...
On a des fichiers .TTAuthority aussi, ça sert à quoi ?
Apparemment, on accède à une liste aussi via "ttauth" qui contient des cookies reliés à l'IP du serveur AIX...
[^] # Re: X sous SSH
Posté par JJD . Évalué à 2.
D'après ce que tu nous dit, il apparaît que la connexion X11 avec la machine Mandrake passe bien directement en TCP sans utiliser le tunneling SSH, ni même l'authentification xauth (je trouve tout de même ce dernier moint surprenant).
Comment est-ce que la sesion X est lancé su ton poste ? (gdm, xdm, kdm, startx, ...)
Avec quelles options X s'exécute ? (ps -ef |grep X)
Je pense qu'il va falloir fouiller un peu du côté de la configuration de kdm (sous kubuntu, je pense que c'est ce que tu utilises) ...
A+
JJD
[^] # YES !!!
Posté par Yo_sensei . Évalué à 1.
Mais ce cochon de kdm avait son propre fichier de conf : kdmrc dans /etc/kde3/kdm où il mettait l'option
ServerArgsLocal=-nolisten tcp
Une fois cette option commentée, j'ai ENFIN pu obtenir mon affichage X, YES !
MERCI BEAUCOUP JJD !
@+
[^] # Re: YES !!!
Posté par JJD . Évalué à 2.
Juste une dernière question : l'affichage fonctionne avec du tunneling SSH ou bien simplement avec une connexion TCP "classique" (DISPLAY fixée à l'adresse IP de la station cliente/Serveur X) ?
Bonne journée
JJD
[^] # Re: YES !!!
Posté par Ramón Perez (site web personnel) . Évalué à 1.
> Une fois cette option commentée, j'ai ENFIN pu obtenir mon affichage X, YES !
Mais donc pas à travers ssh !
Tes applis X passent en clair sur le réseau !
[^] # Re: X sous SSH
Posté par Ramón Perez (site web personnel) . Évalué à 1.
Ca c'est pas normal.
Lorsque tu te loggues en ssh -X, le fichier ~/.Xauthority est créé sur ta machine AIX (et affichable ensuite avec xauth list).
> A signaler : une connection telnet sur le serveur AIX ne donne pas plus de résultat... les applications X ne passent tjs pas
Ca c'est normal, je crois que tu avais dit que côté client ton serveur X est lancé avec l'option -nolisten tcp donc il refuse les connexions distantes.
[^] # Re: X sous SSH
Posté par Ramón Perez (site web personnel) . Évalué à 0.
Tu ne nous as toujours pas dit ce que vaut ta variable DISPLAY...
Sur le serveur, vire ton fichier .Xauthority, délogue toi, relogue toi avec "ssh -X".
Que vaut "xauth list" ?
Que vaut ton DISPLAY ?
[^] # Re: X sous SSH
Posté par Yio . Évalué à 1.
- Si j'enlève le .profile, elle est mise à blanc
- si je la force à localhost:10.0, cela ne fonctionne pas...
le xauth list côté AIX est vide... c'est peut être la solution...
[^] # Re: X sous SSH
Posté par Ramón Perez (site web personnel) . Évalué à 1.
Attention, les tunnels ssh X ne sont pas forcément ouvert sur :10.
Ca va dépendre de la valeur de X11DisplayOffset fixée dans le fichier sshd_config du serveur ssh.
Ensuite, les 10 prochains ports à partir de cette valeur sont utilisés, et pas uniquement le premier.
Donc il se peut très bien qu'il faille rediriger vers localhost:12, voire vers localhost:38 !
[^] # Re: X sous SSH
Posté par mrmarco . Évalué à 1.
J'ai suivi le post et cela fonctionne très bien chez moi maintenant alors que j'avais un peu galéré avec l'export display. Merci !
Sur ma machine pc1 je fais un ssh -X pc2
et l'export du display est OK.
Ma question :
Une fois loggué en ssh sur pc2 je me loggue en root et l'export du display ne fonctionne plus. Une idée ?
Pour ma part, l'intérêt c'est de lancer synaptic pour gérer mes paquets (j'ai du mal avec aptitude).
NB : les deux machines sont sous Debian Sarge.
Bon dimanche,
Marc
[^] # Lancement appli graphique sous un autre utilisateur
Posté par JJD . Évalué à 2.
Le problème de lancement de synaptic sous root (ou de n'importe quelle appli graphique sous un utilisateur différent) est le même que tu sois en local ou connecté en SSH sur un serveur distant.
Lorsque tu te logues en root (su -), tu ne récupéres pas la variable DISPLAY (ça c'est facile à régler) ni le cookie d'authentification de ta session X (dans le fichier ~/.Xauthority). Tu peux fixer la variable DISPLAY manuellement à la même valeur que celle de la session utilisateur ouverte avec SSH et récupérer le cookie qui va bien (voir un de mes posts précédents, ou alors tu récupères le fichier .Xauthority en le copiant ou en faisant un lien symbolique).
Mais le plus simple est tout de même de faire exactement la même chose que le lanceur "synaptic" dans le menu : au lieu d'ouvrir une session sous root avec un "su -" puis de lancer synaptic, tu exécutes simplement
gksu -u root /usr/sbin/synaptic.
C'est alors gksu qui se charge de l'authentification (mot de passe root) et du paramétrage nécessaire pour X (DISPLAY + autorisation).
J'espère avoir pu t'aider
JJD
[^] # Re: Lancement appli graphique sous un autre utilisateur (Thx !)
Posté par mrmarco . Évalué à 1.
C'est exactement la solution que je cherchais : ne pas me logguer en root sur la machine distante, et une fois loggué comme un utilisateur lamda lancer en root des utilitaires comme synaptic.
J'ai appris gksu que je ne connaissais pas. Fonctionne impec ;-)
Merci x 1000 ! Je te souhaite une bonne semaine ;-)
Marc
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.