Vous êtes ici :   Accueil » XMing redirection X11
 
Prévisualiser...  Imprimer...  Imprimer la page...
Prévisualiser...  Imprimer...  Imprimer la section...
!Introduction
Technique
Outils
Base de connaissances
Visites

 1579644 visiteurs

 7 visiteurs en ligne

Contact

Notre site
griessenconsulting-Tag-Qrcode.png

info@griessenconsulting.ch

ch.linkedin.com/in/thierrygriessenCISA

Neuchâtel, Suisse


Mes coordonées
griessenconsulting-Tag-Vcard-OK.png

Crée votre Code

PuTTY et XMING

SSH et la redirection X11

1. Introduction

Les problèmes liés à la redirection X11 avec SSH sont généralement largement documentés et
même explicitement mentionnés dans la page de manuel du client OpenSSH :

« X11 forwarding should be enabled with caution. Users with the ability to
bypass file permissions on the remote host (for the user's X authorization
database) can access the local X11 display through the forwarded connection.
An attacker may then be able to perform activities such as keystroke
monitoring. »

2. Redirection X11

Avant d'aborder la redirection X11, on controle l'existence du X11Forwarding, autrement dit, lancer
son terminal depuis la machine distante :
host-client $ xhost +host-server ; ssh host-server
host-server $ DISPLAY=host-client:10.0 xterm&

En toute logique, si le serveur X de l'hôte host-client est effectivement en
écoute sur la socket TCP spécifiée (correspondant au port 6010/TCP dans
l'exemple), une fenêtre devrait apparaître au niveau de host-client. Le
problème est double dans cette situation :

- utilisation du mécanisme xhost, qui prend la main avant xauth, donnant accès,
  depuis host-server, au serveur X de host-client.
  => La sécurité s'appuie donc sur une identification du client X (host-server)
  par son adresse IP, et non une authentification de l'utilisateur connecté à
  host-server sur la base d'un secret partagé (cookie xauth).

- trafic X11 en clair entre host-client et host-server.

                   Flux X11
             -------------------------------------                      
            | 6010/TCP                            |
    |/                                   | 
         ---x---                               -------
 |       |                             |       |
 |       | ==========================> |       |
 |       |       Session SSH           |       |
  -------                               -------

       host-client                            host-server


Remarque : « client » est à prendre au sens de « client SSH », mais aussi de «
serveur X11 ».

Afin d'éviter un flux X11 « en clair », l'option X11 Forwarding de SSH est donc
à activer -- au niveau client comme au niveau serveur -- mais, nous allons le
voir, avec précaution.

Au niveau du client, il s'agit de l'option en ligne de commande '-X'.
Au niveau du serveur, il s'agit de la directive « X11Forwarding yes » du
fichier de configuration sshd_config.

Pour illustrer le fonctionnement et les problèmes potentiels, considérons
l'exemple suivant -- cas d'un poste d'administration se connectant (avec déport
d'affichage via SSH) sur un serveur distant infogéré :

- L'utilisateur admin souhaite se connecter via SSH à l'hôte
  compromised-server, depuis l'hôte network-admin ; au niveau de network-admin,
  la variable d'environnement DISPLAY est :0.0 :

  admin@network-admin > echo $DISPLAY
  :0.0
 

  => Le serveur X correspondant est en écoute sur la socket unix suivante :
  srwxrwxrwx  1 root root 0 2004-09-28 11:52 /tmp/.X11-unix/X0

  L'application locale doit donc se connecter à ce serveur X pour affichage.
  Le magic-cookie, secret à partager entre serveur X et applications souhaitant
  se connecter à ce dernier, est obtenu par la commande xauth(1) :

  admin@network-admin > xauth list $DISPLAY
  network-admin/unix:0  MIT-MAGIC-COOKIE-1  << 32 character hexkey >>


  La valeur du magic-cookie est la chaîne de 32 caractères obtenue. Cette
  dernière est enregistrée dans le fichier ~/.Xauthority de l'utilisateur --
  les permissions sur ce dernier doivent donc être particulièrement strictes.
  Elle est transmise en clair du client au serveur X, d'où l'intérêt d'une
  encapsulation dans un canal SSH.


- L'utilisateur admin se connecte sur l'hôte compromised-server, en activant la
  redirection X11 -- autorisée au niveau du serveur SSH (X11Forwarding
  positionné à yes) :

  admin@network-admin > ssh -X compromised-server
  admin@compromised-server >


  Le DISPLAY sur le serveur compromised-server pointe sur une socket TCP locale en
  6010/TCP :

  admin@compromised-server > echo $DISPLAY
  localhost:10.0


  => Effectivement, au niveau du serveur, le port 6010/TCP est ouvert
  localement par le démon sshd, qui assure la redirection X11 :

  root@compromised-server # lsof -ni TCP:6010  
  COMMAND   PID USER   FD   TYPE DEVICE SIZE NODE NAME
  sshd    15663 root    9u  IPv4 437835       TCP 127.0.0.1:6010 (LISTEN)


  => Ainsi, les connexions sur compromised-server en 127.0.0.1:6010/TCP seront
  redirigées sur network-admin vers la socket unix /tmp/.X11-unix/.X0 par SSH.
  Reste le problème de l'authentification X11 : en mode debug2 (-vv), on
  constate que la commande suivante est exécutée par SSH au niveau client, afin
  de récupérer le magic-cookie xauth -- qui permettra de se connecter à X via
  la socket unix :

  debug2: x11_get_proto: /usr/bin/X11/xauth  list :0.0 . 2>/dev/null


    Où :0.0 correspond au DISPLAY local (network-admin).

  Le danger survient, classiquement, lorsque l'hôte compromised-server est..
  compromis (dans le pire des cas -- des droits d'accès permissifs sur
  ~/.Xauthority conduiraient au même résultat) : un utilisateur possédant les
  privilèges suffisants pour accéder au fichier ~/.Xauthority -- manipulé par
  la commande xauth(1) -- de l'utilisateur admin sera en mesure de se connecter
  au serveur X local en 6010/TCP (compromised-server) redirigé au niveau de
  l'hôte du serveur X du client SSH (network-admin), sorte de « back channel ».


  Figure : redirection de  compromised-server:127.0.0.1:6010/TCP vers
                           network-admin:/tmp/.X11-unix/X0 via SSH
             avec authentification par xauth(1)

             -----                           ---------------------
           |/    |                         |                     |
         ---x---  |                         |  -------            |
 |  .X0  | --------------------------- |       x 6010/TCP -
 |       | ==========================> |       |
 |       |       Session SSH           |       |
  -------                               -------

       network-admin                          compromised-server


Remarque : l'utilisation d'une socket TCP est rendue nécessaire par la
séparation des privilèges dans OpenSSH, dans la mesure où le processus possède
alors l'identité de l'utilisateur authentifié, et ne peut donc écrire dans le
répertoire /tmp/.X11-unix dans la mesure où il n'est pas SUID root.

Dès lors, les « attaques » ultra classiques relatives à X11 peuvent être mises
en oeuvre au niveau du serveur compromis, afin de capturer les évènements X via
xev(1) par exemple, ou encore afin d'exécuter des commandes au niveau du poste
client, par l'intermédiaire des XSendEvent -- dont le résultat sera variable
suivant le terminal utilisé (dans l'exemple, aterm(1) est utilisé et accepte de
tels évènements).

On imagine sans difficulté les conséquences de la compromission d'un serveur
Web (par exemple) administré depuis un réseau d'admin dédié via une solution de
type SSH + X11 Forwarding. Voire la situation d'un prestataire infogérant n
plateformes de différents clients, présentant potentiellement des niveaux de
sécurité hétérogènes.

Plus efficace qu'un long discours (plugin Flash nécessaire) :
http://www.hsc.fr/~davy/breves/ssh.html

Remarque : dans la démonstration, l'utilisateur root dispose d'un accès en
lecture au fichier ~/.Xauthority de l'utilisateur admin.

3. Redirection X11 en mode « trusted »

Dans tout l'exposé précédent, l'option '-X' est utilisée. En fait, le
comportement de cette option a été modifié - ou plutôt « enrichi » - dans les
versions postérieures à OpenSSH 3.8p1, via l'introduction de l'option '-Y'.

Cette dernière est décrite (très succinctement) de la façon suivante :

« -Y      Enables trusted X11 forwarding. »


En pratique, l'option '-X' active le forwarding X11. Son comportement dépend
ensuite de la présence ou non de l'option '-Y' sur la ligne de commande, ou de
la configuration par défaut dans le fichier ssh_config.

Par défaut, la configuration adoptée est « untrusted » (ForwardX11Trusted no),
qui correspond à ne pas employer l'option '-Y'.

La notion de client X « trusted » et « untrusted » est définie dans les
extensions de sécurité X11 qui mettent en oeuvre un contrôle d'accès par
client, fondé sur la politique de sécurité décrite dans le fichier
/etc/X11/xserver/SecurityPolicy.

Dans ce mode, le client SSH génère un cookie xauth à la volée, qui sera donc
considéré comme « untrusted », et donnera un accès restreint par la politique
de sécurité aux programmes l'employant.

Le principe est, une fois la session SSH authentifiée, que le client SSH
exécute la commande suivante :
debug2: x11_get_proto: /usr/bin/X11/xauth -f /tmp/ssh-TPOAQ11862/xauthfile generate :0.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
debug2: x11_get_proto: /usr/bin/X11/xauth  list :0.0 .  2>/dev/null


=> Le mot-clef « untrusted » est employé dans la commande xauth(1).

Ainsi, dans un premier temps, le client SSH génère un cookie « untrusted »
qu'il associe au serveur local (:0.0). Ce cookie est alors récupéré par la
commande « list ». Il est donc associé au serveur X local, tout en étant
différent du cookie statique et trusted utilisé par les applications locales.

Un *autre* cookie est alors généré par le client SSH, et transmis au serveur
SSH cette fois -- ce dernier alors met à jour le fichier ~/.Xauthority de
l'utilisateur au niveau du serveur SSH en lançant les scripts ~/.ssh/rc,
/etc/ssh/sshrc ou, en dernier lieu, la commande xauth (avec l'option add). À
titre d'illustration, la page de manuel de sshd(8) précise que de tels scripts,
s'ils sont présents, doivent gérer la redirection X11 (détectée par une
variable d'environnement $DISPLAY initialisée), de la façon suivante :

if read proto cookie && [ -n "$DISPLAY" ]; then
 if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
  # X11UseLocalhost=yes
  echo add unix:`echo $DISPLAY |
  cut -c11-` $proto $cookie
 else
  # X11UseLocalhost=no
  echo add $DISPLAY $proto $cookie
 fi | xauth -q -


=> script qui a donc pour effet de mettre à jour le fichier ~/.Xauthority au
niveau du serveur SSH.

Ensuite, pour toute redirection X11 à travers le tunnel, le client SSH
réalisera l'association entre le cookie untrusted présenté et le cookie
untrusted réellement utilisé au niveau du serveur X (localement, récupéré via
xauth list).

=> D'où le terme de « X11 forwarding with authentication spoofing. » mentionné
en mode verbeux : le cookie employé par les applications déportées est remplacé
(par le client SSH) par le cookie réel employé au niveau du serveur X.

Par rapport à la démonstration, en mode « untrusted » la capture ou l'envoi
d'évènements n'est donc plus possible. En revanche, l'énumération via
xlsclients est toujours autorisée, mais elle peut être désactivée dans le
fichier /etc/X11/xserver/SecurityPolicy pour les clients « untrusted ».

Remarque : au contraire, avec l'option '-Y' (mode trusted), la commande
suivante serait exécutée :
debug2: x11_get_proto: /usr/bin/X11/xauth  list :0.0 . 2>/dev/null


Le cookie ainsi généré permet un accès sans limitation au serveur X, les
risques précédemment évoqués s'appliquent donc. Encore une fois, le cookie
niveau serveur SSH est différent du cookie local au client SSH.

Suivant les distributions, le comportement par défaut peut changer.
Typiquement, sous debian, la page de manuel de ssh_config(5) explique :

 ForwardX11Trusted
 [...]
 The default is ``yes'' (Debian-specific).
 See the X11 SECURITY extension specification for full details on the restrictions imposed on untrusted clients.


Ainsi, les commandes « ssh -X host » et « ssh -Y host » sont équivalentes dans
ce cas précis, et correspondent à un mode « trusted ».

Les raisons justifiant une telle configuration sont aussi bien d'ordre pratique
que technique, par exemple, celles notamment avancées dans ces messages
suivants -- cas de la distribution debian-knoppix, suivi d'une entrée de la FAQ
du serveur Cygwin/X, relatif à un dysfonctionnement en mode « untrusted » :
http://mailman.linuxtag.org/pipermail/debian-knoppix/2004-May/005235.html
http://x.cygwin.com/docs/faq/cygwin-x-faq.txt

4. Conclusion

On retiendra que l'application SSH est bien plus qu'un simple « telnet
chiffré/authentifié », et comporte quelques effets de bord pour la sécurité
qui, sans constituer une « vulnérabilité », sont à considérer.
Aux précautions à prendre concernant les redirections X11, on ajoutera celles
liées au remplacement du protocole FTP par SCP on SFTP dans les environnements
de production (très courant), visant à offrir un FTP « chiffré/authentifié »,
mais offrant, en fait, un accès distant avec shell et redirection de connexions
TCP. Problème auquel la réponse généralement apportée consistera en la mise en
place d'un serveur SSH sécurisé (désactivation du TCP Forwarding, mise en place
de wrapper/shells restreints pour les utilisateurs), voire d'une solution
alternative de FTP/SSL http://www.hsc.fr/ressources/breves/ftp-ssl.html.fr

5. Références

Quelques papiers/présentations très intéressants faisant un point sur les
mécanismes d'authentification et la sécurité dans X11, et les attaques
traditionnelles qui s'y rapportent :

- « Enhancing XFree86 Security » par Matthieu Herrb -- auquel vont nos
  remerciements pour ses remarques et son avis éclairé sur le sujet :
http://www.openbsd.org/papers/xf86-sec.pdf

- « SSH X11 forwarding considered harmful » par Holger van Lengerich :
http://www.giac.org/practical/GCIH/Holger_Van_Lengerich_GCIH.pdf

Enfin, quelques pointeurs permettant, de façon similaire, d'offrir un canal de
retour vers le poste client connecté (sans X11Forwarding dans cette situation),
via des failles au niveau des émulateurs de terminaux :

- « Vulnérabilité dans les émulateurs de terminaux »
http://www.certa.ssi.gouv.fr/site/CERTA-2003-AVI-067/index.html

- « Terminal Emulator Security Issues »
http://www.securityfocus.com/archive/1/313007

Tiree de la`article HSC.fr by Franck Davy (27/09/2004)

maintenant la configuration avec Putty et xming

What is PuTTY ?

PuTTY is a Windows SSH client that allows you to connect to the CSE servers, giving you a terminal window like you use in the CSE laboratories. PuTTY can be found on the CSE homecomputing CD which can be borrowed from the CSE Help Desk OR can be downloaded from: http://www.cse.unsw.edu.au/~homecomputing/

What is Xming ?

Xming is a standalone open source X Server for Windows.  Programs that use a graphical user interface like Kate require an X server on your home computer. Xming can be found on the CSE mirror at http://mirror.cse.unsw.edu.au/pub/xming/  You should download the setup program and optionally the fonts package.

Installing PuTTY and XMing

Run the setup programs for PuTTY and Xming. We suggest that you choose the default options for the installation, and choose the options to create icons for PuTTY and Xming on the desktop.

Xming must be running before you run PuTTY.  When it is running, you will see an X icon in the system tray (the bottom right hand side of your Windows screen). If you forget, you can always run it after running PuTTY, even if you are logged on to the CSE login server.

Configuring PuTTY and XMing

Run PuTTY

STEP 1 - In the box Host Name (or IP Address) enter the server name or IP. If the lecturer for your subject has suggested you use a specific server, enter it instead. For more information about CSE servers and their uses see: http://www.cse.unsw.edu.au/help/computing/facilities/computers/index.html

STEP 2 – Make sure SSH is selected.

STEP 3 – Enter Server name in the box below Saved Sessions.

STEP 4 – Click the [-] to expand SSH from the window on the left (if necessary) and click X11.  You should see this screen. Ensure that the checkbox for Enable X11 forwarding is selected.

Under X display location you can have to insert localhosts:0:0

After you have clicked the check box, scroll the left hand window back to the top and click on the Session heading.  You should see the same screen as in Step 1

STEP 5 Click the Save button. The host name you entered should now appear below Default Settings. In the future, you will be able to connect by simply double-clicking this host name.

STEP 6 Click the Open button.

STEP 7 If you see a window like this: click the Yes button.

STEP 8 When you see: login as: enter your CSE username.

STEP 9 When you see: username@servername's password: enter your CSE password.

YOU ARE NOW REMOTELY LOGGED IN TO YOUR CSE ACCOUNT

X11 DISPLAY variables and X forwarding

Assuming we are logged in via "ssh" from WOMBATNET to chinookfe, what are some of the possible problems we can encounter with X11 forwarding ? The first clue, in the following example, is the DISPLAY environment variable.


    [chinookfe:/home/chinook/wombat]
    $ xterm
    xterm Xt error: Can't open display: :0

Trying to execute a simple "xterm" on chinookfe through "ssh" yields the above error message, which shows that the DISPLAY environment variable is not set correctly. We can confirm this as follows:


    [chinookfe:/home/chinook/wombat]
    $ echo $DISPLAY
    :0

The immediate inclination is to manually set the DISPLAY variable on chinookfe using either "export" or "setenv", depending on your shell. This is not correct, in that the proper operation of "ssh" with X forwarding allows us to avoid setting or trying to set the DISPLAY variable manually, and it even bypasses the need to run the "xhost" command for the chinookfe session on your workstation. A correct DISPLAY setting, assuming a simple X forwarding operation between chinookfe and our hypothetical workstation WOMBATNET, would yield a value such as:


    [chinookfe:/home/chinook/wombat]
    $ echo $DISPLAY
    chinookfe:11.0

This varies from what you may have seen in the past, in that often users will place command lines into their login scripts on remote systems that set the DISPLAY variable upon login. Lines like:


      setenv DISPLAY myworkstation:0.0
                   or
      export DISPLAY=myworkstation:0.0

should be removed from your dot files (.cshrc, .kshrc, .login, etc.) on NCAR computer systems, as "ssh" will automatically handle forwarding X11 connections for us. This includes setting the DISPLAY environment variable on the remote host, in this case chinookfe.

Assuming we have removed the line(s) setting our DISPLAY variable from our dot files on chinookfe, how do we get "ssh" to do the work for us? Our recommended approach is to use the "-X" option of "ssh" to establish the connection from our hypothetical example workstation WOMBATNET to chinookfe, as follows:


    [WOMBATNET:/home/wombat]
    $ ssh -X chinookfe.ucar.edu

    wombat@chinookfe's password:

After entering our password, we receive the MOTD and are logged into the system.


    Last login: Wed Jul 17 10:34:08 2002 from WOMBATNET.net
    =======================================================================
    chinookfe: IRIX64 6.5.16, SGI Origin2000 (8 cpus, 8 GB's memory)
    =======================================================================
    THIS SYSTEM IS FOR THE USE OF AUTHORIZED USERS ONLY.  INDIVIDUALS USING
    THIS COMPUTER SYSTEM WITHOUT AUTHORITY, OR IN EXCESS OF THEIR AUTHORITY,
    ARE SUBJECT TO HAVING ALL THEIR ACTIVITIES ON THIS SYSTEM MONITORED AND
    RECORDED BY SYSTEM PERSONNEL.  IN THE COURSE OF MONITORING INDIVIDUALS
    IMPROPERLY USING THIS SYSTEM, OR IN THE COURSE OF SYSTEM MAINTENANCE,
    THE ACTIVITIES OF AUTHORIZED USERS MAY ALSO BE MONITORED.
    =========================================================================

    [chinookfe:/home/chinook/wombat]
    $

We should now have the correct DISPLAY variable set:


    [chinookfe:/home/chinook/wombat]
    $ echo $DISPLAY
    chinookfe:10.0

Note that the form of the DISPLAY variable will always be "HOSTNAME:x.y" where "HOSTNAME" is the host we just logged in to, in this case "chinookfe", "x" is a small integer, in this case "10", and "y" is usually "0". What this does, in general terms, is enable X11 forwarding across the established ssh tunnel. The upside is this means we don't have to set DISPLAY through either files or after login, and back on the workstation we don't have to issue a command like "xhost +chinookfe.ucar.edu". In addition, all of the X11 traffic is now encrypted. This effect provides better security than the more traditional techniques, and if your facility has a firewall, this may be the only way, because of the tunneling, to get X11 applications to display back to your workstation from the system at NCAR.

You should now be able to execute a simple X11 application like "xterm" and get the window back at your workstation:


    [chinookfe:/home/chinook/wombat]
    $ xterm &

If this fails to display the "xterm" window, then we need to employ remedial "ssh" diagnostics to try to determine where the X11 authorization problem may exist. With the OpenSSH client software, we can use the same verbose stream debugging we did in our previous example.


Here is also an interesting information

Using X Forwarding on Windows

--------------------------------------------------------------------------------

By Evan Murphy mailto:erm@ugcs.caltech.edu , 4/17/2006. Revised by Mike Vanier mailto:mvanier@cs.caltech.edu , 4/24/2006.

Introduction
Most CS 11 students do their labs from the comfort and convenience of their own rooms. However, since most people are stuck running Windows, and the CS cluster machines run Linux, there's a problem. If you did your labs on the CS cluster computer, you would get a nice graphical interface to work with. But if you log in remotely to the CS cluster with (say) PuTTY, then all you get is a single terminal. Worse, you can't start up graphical programs, because the graphical interface software on Linux is different from that on Windows.

That being the case, you have these choices:

You can come in to the CS computer lab to do your assignments
You can grin and bear it, and work within one lousy terminal and a non-graphical editor.
You can configure your computer so that it can run Linux programs remotely that have a graphical interface.
This document will cover option 3. If you set this up correctly, you will be able to use all the programs that you would have used in the CS lab on your Windows computer. You'll also be able to run multiple programs on the CS cluster at the same time (e.g. a terminal and a text editor) and all of them will show up on your Windows computer. So working on your labs in your room won't be much different from working on them in the CS lab.

If your computer runs Linux already, you don't need this document -- you just need to know this command:

% ssh -X login.cs.caltech.edu
where "%" is the terminal prompt. If your computer is a Mac, this document won't help, but I believe there is an X server that works on the Mac (anyone want to look into this?)

Background
The Linux graphical windowing system is called X11, also known as X Windows, or X for short. Note that "X Windows" has nothing whatsoever to do with Microsoft Windows. Nada. Zip. Zero. Forget I even mentioned it.

"X forwarding" is a feature of X where a graphical program runs on one computer, but the user interacts with it on another computer. If you've ever used VNC or Microsoft's Remote Desktop, it's conceptually like that, but it works on a program-by-program or window-by-window basis.

If both computers are running Linux, it's pretty much transparent. However, if you're sitting in front of a Windows computer, it's a little bit trickier -- not much, though! All you need is an X server that runs on Windows, and an SSH client, both of which are freely available.

A Note on Terminology
In X parlance, the "client" is the computer running the program, and the "server" is the computer you're sitting in front of. This might seem backwards: normally the server is the remote computer that's serving you.

Think of it this way: the X server is serving you, the human being, to the programs on the remote computer. The client, a program, makes requests of you through the X server by changing its graphical display, and you respond to it by clicking on it or typing into it.

What You Need
SSH Client
I'm going to explain how to do this with PuTTY, a free and very powerful SSH client for Windows. You can find it here.

You don't need to install PuTTY; just put it in a convenient place and run it. You can leave it on your desktop, or put it in "Program Files" and create a shortcut to the program in your Start Menu. Or you can install it if you like.

X Server and Fonts
You can get the standard X.Org X server ported for Windows; it's called XMing. Actually finding the installer files is a pain, so here are some direct links:

The X server itself
The fonts package
You need both of these!

Now, install both these packages. They have nice Windows installers, so this should be pretty straightforward. Make sure that you put both of them in the same directory (it will do this by default -- be sure to say "yes" even though the directory already exists).

Making It Go
Start XMing
You should have a Start Menu item for XMing. Go ahead and start it. If you're using a firewall, it'll ask you if you want to unblock it. You don't need to.

Look for the "X" icon in your system tray. Hover the mouse over it: it should say something like "Xming server - 0:0". The last bit should be "0:0", but if it's not, pay attention to that and use it below.

PuTTY
I'm assuming you're currently using PuTTY. If not, there's some good documentation on the PuTTY website. It's also very easy to use, so you should be able to start using it without much trouble anyways.

First, open PuTTY. Then, put in your normal settings for connecting to the CS cluster: under host name, put "your-username@login.cs.caltech.edu".

Then, on the left, click on the Connection/SSH/X11 sub-panel. It'll have a few options. Check "Enable X11 Forwarding", and in the "X display location", put "localhost:0:0" in the box (unless you didn't have "0:0" in the section above: then use "localhost:x:y", where "x:y" is whatever you saw on the icon). Leave the radio button on "MIT-Magic-Cookie-1".

Now click back to the main "Session" panel on the left. Put a name (like "CS + XWindows") in the text box in the middle right below "Saved Sessions". Click the "Save" button. From now on, you can double click the connection in the list box when you want to connect to CS; you don't need to do these settings every time.

Press "Open" to start PuTTY. Put in your password or do whatever you do to authenticate. Now run the command "xeyes &". You should get a big pair of googly-eyes that follows the cursor around. It works!

Tips and Tricks
It's important to start the XMing server before you try to start the graphical program you want to run. Otherwise, there won't be anything on your end to draw the windows.

You can put an ampersand ('&') after any command to make it go to the background: i.e. "emacs &" will start emacs and let you continue to use the PuTTY terminal.

Any programs you start in this way will close (and lose your work!) if you close the PuTTY session. So don't do that.

If you need another terminal, instead of running another PuTTY session, try running "xterm &" in your current session. This will create a terminal using the CS cluster's terminal program, and display the window on your computer.

You can run any program that you'd start as if you're sitting in front of one of the terminals in the CS lab. Unfortunately, they're not always installed on login.cs. You can SSH to another computer (try e.g. pacman.cs or pong.cs) if that's the case. Try "mozilla-firefox &", for example. NOTE: In general, you shouldn't be running graphical applications on login.cs anyway, because they often use a lot more computing power than their non-graphical counterparts, and login.cs is not an appropriate computer on which to run computationally-intensive programs. Please keep this in mind.

Very graphics-heavy programs (like, ahem, "mozilla-firefox") may be somewhat slow. Be patient if you're on a slow connection; everything will work eventually. Terminals and editors should be reasonably fast, and that's all you need for most CS 11 tracks.

by Franck Davy (27/09/2004)


Catégorie : Base de connaissances - Linux