  Comment excuter des applications X  distance mini-HOWTO
  Vincent Zweije, zweije@xs4all.nl
  V 0.5.0, 3 Juin 1998

  Ce mini-HOWTO dcrit comment excuter des applications X  distance.
  C'est--dire, comment faire pour qu'un programme X s'affiche sur un
  cran d'ordinateur diffrent de celui sur lequel il s'excute. Ou,
  autrement dit, comment faire tourner un programme X sur un ordinateur
  diffrent de celui devant lequel vous tes assis. L'accent de ce mini-
  HOWTO sera mis sur les questions de scurit.  Adaptation franaise :
  Albert-Paul Bouillot apb@club-internet.fr
  ______________________________________________________________________

  Table des matires


  1. Introduction

  2. Lectures complmentaires

  3. Le contexte

  4. Un peu de thorie

  5. Dire au client ...

  6. Dire au serveur ...

     6.1 Xhost
     6.2 Xauth
        6.2.1 Fabrication du Cookie
        6.2.2 Transfert du Cookie
        6.2.3 Utilisation du Cookie
     6.3 Ssh

  7. Maintenance



  ______________________________________________________________________

  11..  IInnttrroodduuccttiioonn

  Ce mini-HOWTO constitue un guide  sur la manire de faire tourner des
  applications X  distance.  J'ai rdig ce document pour plusieurs
  raisons :


  1. Il y a eu de nombreuses questions, sur Usenet, sur la manire de
     faire tourner des applications X  distance.

  2. >J'ai vu beaucoup, beaucoup, de conseils d'utilisation de xhost
     +hostname ou mme de xhost + pour raliser des connexions X.  CC''eesstt
     dd''uunnee iinnssccuurriitt ttoottaallee, et il existe de bien meilleures mthodes.

  3. Je n'ai pas connaissance d'un document simple dcrivant les options
     dont _o_n _p_e_u_t disposer. Si vous avez des informations
     complmentaires, s'il vous plat, faites-le moi savoir :
     <zweije@xs4all.nl>

  Ce document a t crit en pensant  des systmes de type unix.  Si le
  systme d'exploitation de votre ordinateur local ou de celui qui est 
  distance est de type diffrent, vous devriez trouver ici des
  informations sur la manire dont les choses se passent. Cependant, il
  vous faudra modifier les exemples par vous-mme pour les utiliser sur
  votre (vos) propre(s) systmes(s).
  La version (anglaise) la plus rcente de ce document est toujours
  disponible sur leWWW  http://www.xs4all.nl/~zweije/xauth.html.  Il
  est galement disponible en tant que mini-HOWTO Linux Remote X Apps 
  : http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps. Les
  (mini-)HOWTOs  Linux sont disponibles par http ou ftp de
  sunsite.unc.edu.

  Ceci constitue la version 0.5.0. Aucunes garanties, seulement de
  bonnes intentions. Je suis ouvert aux suggestions, ides, ajouts,
  pointeurs utiles, corrections (typo), etc... Je veux que cela reste un
  document simple et lisible, dans la bonne moyenne du style HOWTO.  Les
  querelles seront rediriges vers /dev/null.

  Le contenu de ce mini-HOWTO a t mis  jour le 3 Juin 1998 par
  Vincent Zweije


  22..  LLeeccttuurreess ccoommppllmmeennttaaiirreess

  Un document, en rapport avec cela, sur le WWW traite de ''Quoi faire
  quand Tk dit que votre cran n'est pas sr'', http://ce-
  toolkit.crd.ge.com/tkxauth/.  Il a t crit par Kevin Kenny. Il
  suggre une solution similaire  celle de ce document pour
  l'authentification X (xauth). Cependant, Kevin vise plus 
  l'utilisation de xdm pour diriger xauth  votre place.

  On m'a indiqu que le volume n8 du guide de l'administrateur du
  systme X Window (X Window System Administrator's Guide Vol. 8) de
  chez O'Reilly and Associates tait une bonne source d'informations.
  Malheureusement, je n'ai pas pu le vrifier.

  Il y a galement un autre document qui ressemble beaucoup  celui que
  vous tes en train de lire, dont le titre est ''Securing X Windows'',
  et qui est disponible 
  http://ciac.llnl.gov/ciac/documents/ciac2316.html.

  Consultez galement les listes de diffusion usenet, telles que :
  comp.windows.x, comp.os.linux.x, comp.windows.x.i386-unix, et
  comp.os.linux.networking.


  33..  LLee ccoonntteexxttee

  Vous utilisez deux ordinateurs. Sur le premier, vous tes dans
  l'environnement X window pour taper au clavier et regarder l'cran.
  Sur le second vous effectuez un important traitement graphique. Vous
  voulez que les sorties du second soient affiches sur l'cran du
  premier. Le systme X window rend cela possible.


  Naturellement, vous devez disposez de connexions  un rseau pour
  pouvoir le raliser. De prfrence rapides, car le protocole X est un
  dvoreur de ressources rseau. Mais, avec un peu de patience et un
  protocole de compression de donnes adapt, vous pouvez mme faire
  tourner des applications par l'intermdiaire d'un modem. Pour un
  protocole de compression pour X, vous pouvez aller consulter les sites
  : dxpc <http://ccwf.cc.utexas.edu/~zvonler/dxpc/> ou LBX
  <http://www.ultranet.com/~pauld/faqs/LBX-HOWTO.html> (galement connu
  comme tant le LBX mini-HOWTO).

  Vous avez deux choses  faire pour raliser tout cela :


  1. Indiquer  l'unit d'affichage locale (le serveur) qu'elle doit
     accepter les connexions venant de l'ordinateur  distance.

  2. Dire  l'application  distance (le client) de rediriger ses
     sorties vers votre unit d'affichage locale.


  44..  UUnn ppeeuu ddee tthhoorriiee

  Le mot magique est DISPLAY (unit d'affichage). Dans le systme X
  window, une unit d'affichage est constitue (en simplifiant) d'un
  clavier, d'un mulot et d'un cran. Une unit d'affichage est gre par
  un programme serveur, plus connu sous le nom de serveur X. Le serveur
  fourni des fonctionnalits d'affichage aux autres programmes qui se
  connectent  lui.


  Une unit d'affichage est identifie par un nom, de type, par exemple
  :


    DISPLAY=light.uni.verse:0

    DISPLAY=localhost:4

    DISPLAY=:0

  Un nom d'unit d'affichage est constitu d'un nom d'hte (par exemple
  : light.uni.verse et localhost), du signe deux point (:), et d'un
  numro de squence (tels que 0 et 4). Le nom d'hte de l'unit
  d'affichage est le nom de l'ordinateur sur lequel tourne le serveur X.
  Si le nom de l'hte est omis, cela signifie qu'il s'agit de
  l'ordinateur local.  D'habitude, le numro de squence est 0 -- cela
  peut changer s'il y a plusieurs units d'affichage connectes sur le
  mme ordinateur.

  Si jamais il vous arrive de voir le nom d'une unit d'affichage avec
  un .n supplmentaire accol  son nom, c'est qu'il s'agit d'un numro
  d'cran. Une unit d'affichage peut, en thorie, avoir plusieurs
  crans.  Cependant, d'habitude, il n'y en a qu'un, qui porte le numro
  n=0.


  D'autres formes de DISPLAY existent, mais celle-ci suffira pour notre
  propos.


  55..  DDiirree aauu cclliieenntt ......

  Le programme client (par exemple, votre application graphique) sait 
  quelle unit d'affichage il doit se connecter en consultant la
  variable d'environnement DISPLAY. Cependant ce paramtrage peut tre
  modifi, en lanant le client avec l'argument  -display hostname:0
  dans la ligne de commande. Quelques exemples peuvent clarifier les
  choses.


  Notre ordinateur est connu du monde extrieur sous le nom light , et
  nous sommes dans le domaine uni.verse.  Si nous fonctionnons avec un
  serveur X normal, l'unit d'affichage est connue comme tant
  light.uni.verse:0.  Nous voulons faire tourner le programme de dessin
  xfig sur un ordinateur  distance, appel dark.matt.er, et afficher sa
  sortie ici, sur light.

  Si l'interprteur de commande de l'ordinateur loign est csh :




  dark% setenv DISPLAY light.uni.verse:0
  dark% xfig &




  Ou, d'une autre manire :



       dark% xfig -display light.uni.verse:0 &




  Si c'est sh qui tourne sur l'ordinateur  distance :



       dark$ DISPLAY=light.uni.verse:0
       dark$ export DISPLAY
       dark$ xfig &




  Ou, autrement :



       dark$ DISPLAY=light.uni.verse:0 xfig &




  Ou, bien sr, galement :



       dark$ xfig -display light.uni.verse:0 &




  Il parat que certaine versions de telnet transmettent automatiquement
  la variable DISPLAY  l'ordinateur hte loign. Si vous avez l'une ce
  celles-ci, vous avez de la chance, et c'est effectivement automatique.
  Si ce n'est pas le cas, la plupart des versions de telnet _d_o_i_v_e_n_t
  transmettre la variable d'environnement TERM, et avec un bidouillage
  judicieux, il est possible de superposer la variable DISPLAY sur la
  variable TERM.


  66..  DDiirree aauu sseerrvveeuurr ......

  Le serveur n'acceptera pas de connexions venant de n'importe o. Vous
  ne voulez pas que n'importe qui puisse afficher des fentres sur votre
  cran. Ou lire ce vous tapez -- souvenez-vous que votre clavier fait
  partie de votre unit d'affichage!


  Trop peu de gens semble raliser que permettre l'accs  leur unit
  d'affichage pose des problmes de scurit. Quelqu'un qui dispose d'un
  accs  votre unit d'affichage peut lire et crire sur vos crans,
  lire vos frappes au clavier, et suivre les dplacements de votre
  mulot.
  La plupart des serveurs disposent de deux manires d'authentifier les
  demandes de connexions qui arrivent : le mcanisme de la liste d'htes
  (xhost) et le mcanisme du mot de passe secret (magic cookie) (xauth).
  De plus, il y a ssh, l'interprteur de commande scuris, qui peut
  acheminer les connexions X.


  66..11..  XXhhoosstt

  Xhost permet les accs bass sur les nom d'htes. Le serveur
  entretient une liste des htes qui sont autoriss  se connecter 
  lui. Il peut aussi dsactiver compltement la vrification des htes.
  Attention : cela signifie que plus aucun contrle n'est effectu, et
  donc, que _n_'_i_m_p_o_r_t_e _q_u_e_l hte peut se connecter!


  Vous pouvez contrler la liste des htes du serveur avec le programme
  xhost.  Pour utiliser ce mcanisme dans l'exemple prcdent, faites :



       light$ xhost +dark.matt.er




  Ceci permet toutes les connexions  partir de l'hte dark.matt.er.
  Ds que votre client X a ralis sa connexion et affiche une fentre,
  par scurit, supprimez les permissions pour d'autres connexions avec
  :



       light$ xhost -dark.matt.er




  Vous pouvez dsactiver la vrification des htes avec :



       light$ xhost +




  Ceci dsactive la vrification des accs des htes et donc permet 
  _t_o_u_t _l_e _m_o_n_d_e de se connecter. Vous ne devriez _j_a_m_a_i_s faire cela sur
  un rseau o vous n'avez pas confiance dans _t_o_u_s les utilisateurs (tel
  internet). Vous pouvez ractiver la vrification des htes avec :



       light$ xhost -




  xhost - par lui-mme _n_e _s_u_p_p_r_i_m_e _p_a_s tous les htes de la liste
  d'accs (ce qui serait tout  fait inutile - vous ne pourriez plus
  vous connecter de n'importe o, pas mme de votre hte local).

  _X_h_o_s_t _e_s_t _u_n _m__c_a_n_i_s_m_e _v_r_a_i_m_e_n_t _t_r__s _p_e_u _s__r_. Il ne fait pas de
  distinction entre les diffrents utilisateurs sur l'hte  distance.
  De plus, les noms d'htes (en ralit des adresses) peuvent tre
  manipuls. C'est mauvais si vous vous trouvez sur un rseau douteux
  (dj, par exemple, avec un accs PPP tlphonique  Internet).


  66..22..  XXaauutthh

  Xauth autorise l'accs  tous ceux qui connaissent le bon secret.  On
  appelle un tel secret un enregistrement d'autorisation ou cookie.  Ce
  mcanisme d'autorisation est dsign crmonieusement comme tant le
  MIT-MAGIC-COOKIE-1.


  Les cookies pour les diffrentes units d'affichage sont stocks
  ensembles dans ~/.Xauthority. Le programme xauth gre ces cookies,
  donc les surnoms xauth pour le systme.  Votre fichier ~/.Xauthority
  doit tre inaccessible pour les utilisateurs groupe/autres.

  Au dmarrage d'une session, le serveur lira un cookie dans le fichier
  qui est indiqu par l'argument -auth. Ensuite, le serveur ne permet la
  connexion que des clients qui connaissent le mme cookie. Quand le
  cookie dans ~/.Xauthority change, _l_e _s_e_r_v_e_u_r _n_e _r__c_u_p__r_e_r_a _p_a_s _l_a
  _m_o_d_i_f_i_c_a_t_i_o_n.


  Les serveurs les plus rcents peuvent gnrer des cookies  la vole
  pour des clients qui le demandent. les cookies sont cependant encore
  conservs dans le serveur; ils ne finissent pas dans ~/.Xauthority 
  moins qu'un client ne les y mettent. Selon David Wiggins :


       Une possibilit supplmentaire , qui peut vous intresser, a
       t ajoute dans X11R6.3.  Par l'intermdiaire de la nou
       velle extension SECURITY, le serveur X lui-mme peut gnrer
       et renvoyer de nouveaux cookies  la vole. De plus on peut
       dsigner les cookies comme tant "douteux" de sorte que les
       applications qui se connectent avec de tels cookies auront
       une capacit opratoire restreinte. Par exemple, ils ne
       pourront pas regarder les entres au clavier/mulot, ou le
       contenu des fentres, d'autres clients "fiables".  Il y a
       une nouvelle sous-commande "generate" de xauth pour rendre
       cette fonctionnalit, pas forcment facile, mais au moins
       possible  utiliser.


  Xauth possde un avantage clair, au niveau de la scurit, sur xhost.
  Vous pouvez limiter l'accs  des utilisateurs spcifiques sur des
  ordinateurs spcifiques. Il ne permet pas l'usurpation d'adresse comme
  le permet xhost.  Et, si vous le dsirez, vous pouvez encore utiliser
  xhost en parallle pour permettre des connexions.


  66..22..11..  FFaabbrriiccaattiioonn dduu CCooookkiiee

  Si vous voulez utiliser xauth, vous devez lancer le serveur X avec
  l'argument -auth authfile. Si vous utilisez le script ssttaarrttxx pour
  lancer le serveur X, c'est le bon endroit pour le faire. Crez
  l'enregistrement d'autorisation comme indiqu ci-dessous dans votre
  script startx.

  Extrait de /usr/X11R6/bin/startx:



       mcookie|sed -e 's/^/add :0 . /'|xauth -q
       xinit -- -auth "$HOME/.Xauthority"

  Mcookie est un petit programme du paquetage util-linux, site primaire
  ftp://ftp.math.uio.no/pub/linux/. Autrement, vous pouvez utiliser
  md5sum pour crer quelques donnes alatoires (de, par exemple,
  /dev/urandom ou ps -axl) au format cookie :



       dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
       xinit -- -auth "$HOME/.Xauthority"




  Si vous ne pouvez pas diter le script startx(parce que vous n'tes
  pas root), demandez  votre administrateur de systme de configurer
  startx correctement, ou,  la place, laissez-le configurer xdm. S'il
  ne peut, ou ne veut, pas, vous pouvez crire un script ~/.xserverrc.
  Si vous avez ce script, il sera excut par xinit au lieu du vritable
  serveur X. Alors, vous pourrez lancer le serveur X vritable  partir
  de ce script avec les arguments adapts.  Pour faire cela, faites
  utiliser par votre ~/.xserverrc le mcookie de la ligne ci-dessus pour
  crer un cookie puis lancer le vritable serveur X :



       #!/bin/sh
       mcookie|sed -e 's/^/add :0 . /'|xauth -q
       exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"




  Si vous utilisez xxddmm pour grer vos sessions X, vous pouvez utiliser
  xauth facilement. Dfinissez les ressources du DisplayManager.authDir
  dans /etc/X11/xdm/xdm-config.  Xdm passera l'argument -auth au serveur
  X  son dmarrage. Au moment de la connexion sous xdm, xdm place le
  cookie dans ~/.Xauthority pour vous. Consultez xdm(1) pour de plus
  amples information.  Par exemple, mon /etc/X11/xdm/xdm-config contient
  la ligne suivante :



       DisplayManager.authDir: /var/lib/xdm





  66..22..22..  TTrraannssffeerrtt dduu CCooookkiiee

  Maintenant que vous avez lanc votre session X sur le serveur hte
  light.uni.verse et que vous avez votre cookie dans ~/.Xauthority, il
  vous faut transfrer le cookie sur le client, dark.matt.er.


  Le plus simple est que vos rpertoires sur light et dark soient
  partags. Les fichiers ~/.Xauthority sont les mmes, donc le cookie
  est transfr instantanment.  Cependant, il y a un pige : lorsque
  vous mettez un cookie pour :0 dans ~/.Xauthority, dark va croire que
  c'est un cookie pour lui au lieu de light. Il faut que vous utilisiez
  un nom d'hte explicite  la cration du cookie; on ne peut pas faire
  autrement. Vous pouvez installer le mme cookie pour,  la fois, :0 et
  light:0 avec :



  #!/bin/sh
  cookie=`mcookie`
  xauth add :0 . $cookie
  xauth add "$HOST:0" . $cookie
  exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"




  Si les rpertoires home ne sont pas partags, vous pouvez transfrer
  le cookie au moyen de rsh, le shell  distance :



       light$ xauth nlist :0 | rsh dark.matt.er xauth nmerge -





  1. Extraire le cookie de votre fichier local ~/.Xauthority (xauth
     nlist :0).

  2. Le transfrer vers dark.matt.er (| rsh dark.matt.er).

  3. >Le mettre dans ~/.Xauthority there (xauth nmerge -).

  Il est possible que rsh ne fonctionne pas chez vous. En plus de cela,
  rsh a un inconvnient en ce qui concerne la scurit (noms d'htes
  parodis, si je me souviens bien). Si vous ne pouvez, ou ne voulez,
  pas utiliser rsh, vous pouvez galement transfrer le cookie
  manuellement, comme ceci :



       light$ echo $DISPLAY
       :0
       light$ xauth list $DISPLAY
       light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926
       light$ rlogin dark.matt.er
       Password:
       dark% setenv DISPLAY light.uni.verse:0
       dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926
       dark% xfig &
       [15332]
       dark% logout
       light$




  Consultez galement rsh(1) et xauth(1x) pour de plus amples
  informations.

  Il doit tre possible de superposer le cookie sur la variable TERM
  quand vous utilisez telnet sur l'hte loign, et ainsi, c'est encore
  automatique. Regardez la section 6.1 sur le transfert de DISPLAY. Cela
  m'intresse si quelqu'un peut me confirmer ou m'infirmer cela.


  66..22..33..  UUttiilliissaattiioonn dduu CCooookkiiee

  Une application X, telle que xfig ci-dessus, sur dark.matt.er, ira
  automatiquement voir le cookie dans ~/.Xauthority pour s'authentifier.


  66..33..  SSsshh

  Les enregistrements d'autorisation sont transmis sans codage. Si vous
  vous souciez de ce que l'on puisse espionner vos connexions, utilisez
  ssh, le shell scuris. Il effectuera des transmissions X scurises
  au moyen de connexions cryptes. De plus, il est gnial pour d'autres
  choses aussi.  C'est une bonne amlioration structurelle de votre
  systme. Allez voir simplement http://www.cs.hut.fi/ssh/, la page
  d'accueil de ssh.

  Qui possde d'autres informations sur les mthodes d'authentification
  ou de cryptage des connexions X ?  Peut-tre Kerberos ?


  77..  MMaaiinntteennaannccee

  D'ordinaire, la premire fois que vous allez essayer de faire tourner
  une application X  distance,  ne marchera pas. Voici quelques-uns
  des messages d'erreur habituels, leur cause probable et des solutions
  pour vous aider  progresser.




       xterm Xt error: Can't open display:




  Il n'y a pas de variable DISPLAY renseigne dans votre environnement
  et vous n'avez pas non plus lanc l'application avec le drapeau
  -display.  L'application assume que la variable display contient une
  chane de caractres vide, ce qui est syntaxiquement incorrect. La
  solution  cela consiste  s'assurer que la variable DISPLAY est
  correctement renseigne dans l'environnement (avec setenv ou export
  selon votre shell).



       _X11TransSocketINETConnect: Can't connect: errno = 101
       xterm Xt error: Can't open display: love.dial.xs4all.nl:0




  L'application n'arrive pas  se connecter au serveur  travers le
  rseau.  Vrifiez que la variable  DISPLAY est correctement renseigne
  et que la machine serveur est accessible  partir de votre client (ce
  qui devrait tre le cas, car aprs tout vous tes probablement
  connect au serveur en ayant une session telnet avec votre client).



       _X11TransSocketINETConnect: Can't connect: errno = 111
       xterm Xt error: Can't open display: love.dial.xs4all.nl:0




  La machine  laquelle vous tes en train d'essayer de vous connecter
  peut tre atteinte, mais le serveur indiqu n'existe pas  cet
  endroit.  Vrifiez que vous utilisez le nom d'hte correct et le
  numro d'unit d'affichage adquat.



  Xlib: connection to ":0.0" refused by server
  Xlib: Client is not authorized to connect to Server
  xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0




  Le client pourrait raliser une connexion avec le serveur, mais celui-
  ci ne permet pas au client de l'utiliser (pas autoris). Assurez-vous
  que vous avez transfr le bon cookie au client, et qu'il n'est pas
  prim (le serveur utilise un nouveau cookie au dmarrage d'une
  nouvelle session).






















































