Home Page

TP 7
Réseaux 1ère Année
IUT Info Aix-en-Provence © Cyril Pain-Barre

I. Introduction à SSH
Le protocole SSH (pour Secure SHell) est le remplaçant de rsh (remote shell) qui
correspond grosso-modo à telnet. Comme nous le verrons, SSH permet bien plus de
choses que telnet. Il permet aussi de transférer des fichiers de façon sécurisée
(fiable et cryptée) via les protocoles scp et sftp.

SSH existe en deux versions majeures 1 et 2 qui sont incompatibles. La version 2

est la plus sécurisée et à utiliser à chaque fois que c'est possible.

L'utilitaire client ssh existe sous Linux et est assez bien documenté. Pour le
moment nous nous concentrerons sur les clients gratuits Windows que
sont Putty et SSH Secure Shell Client.

I.1. Putty

Putty est un client SSH développé par Simon Tatham. La site officiel
de Putty est ici. On peut y télécharger la dernière version. Les utilitaires de la
suite Putty se trouvant ici sont peut-être un peu anciens (à vérifier) mais tout à fait
fonctionnels. Ils sont regroupés comme une archive zip ici. Les différents utilitaires
de cette suite sont :

 plink : client SSH en ligne de commandes.

Taper simplement plink pour avoir une liste d'options disponibles. Pour se
connecter à allegro avec plink, il suffit de taper plink allegro.iut.univ-aix.fr ;
 pscp : client scp en ligne de commandes.
Permet de copier un fichier depuis ou vers un serveur en créant une
connexion SSH.
Par exemple pscp c:\Documents and Settings\Cyril\truc.txt
[email protected]:machin.txt copie le fichier truc.txt sur le compte
de cpb d'allegro en l'appelant machin.txt ;
 psftp : client sftp en ligne de commandes.
Il permet de faire à peu près la même chose que ftp.
 putty : client SSH évolué.
Permet de créer des sessions et de les configurer de façon graphique.
  puttygen : utilitaire permettant de créer/modifier des clés.
 pageant : utilitaire permettant de communiquer les clés quand c'est
nécessaire.

Il existe plusieurs méthodes pour ouvrir une session SSH. Les plus courantes
sont l'utilisation de son mot de passe, ou l'utilisation d'une paire de clés. La seconde
solution est la plus sécurisée. Nous allons voir comment créer des clés et les
utiliser. Auparavant, rapatriez les utilitaires putty sur votre PC.

I.1.a. Création des clés :

 Lancer l'utilitaire puttygen et cocher le bouton radio SSH2 RSA puis cliquer
sur Generate.
 L'utilitaire demande alors de bouger la souris de manière aléatoire pour
pouvoir créer la clé.
 Une fois la paire de clés générée, il faut renseigner le champ comment et
les passphrases. Le champ comment est libre et sera affiché à chaque fois
que la passphrase vous sera demandée. On peut donc mettre une indication
pour se souvenir de la passphrase. La passphrase protège la clé privée et est
très importante. Elle ne doit pas être courte, doit comporter des ponctuations
et alterner des minuscules et des majuscules :
  Sauver les clés publiques et privées sur le PC pour constituer votre
trousseau.
 Ne pas sortir de la fenêtre puttygen car on va en avoir besoin.

I.1.b. Déposer la clé publique sur allégro.

 Sur allegro, créer le répertoire .ssh. Attention, ce répertoire et tout ce qu'il

contient doit être absolument protégé. Les permissions doivent être nulles
pour le groupe et les autres !
 Se placer dans .ssh
 Créer le fichier authorized_keys et y copier la clé publique (par un copier-
coller de la fenêtre ci-dessus). Attention, ne pas laisser de lignes vides ni de
caractères supplémentaires !
 Sauver le fichier authorized_keys et vérifier les permissions. Il ne doit y
avoir aucun droit pour les membres du groupes ni pour les autres sur le
répertoire .ssh ni sur le fichier authorized_keys.
 Quitter puttygen.

I.1.c. Configurer putty.

 Lancer putty. Dans la rubrique Session, renseigner le champ Host

Name avec allegro.iut.univ-aix.fr et choisir SSH comme Protocol :
 Dans la rubrique Connection, entrer votre nom d'utilisateur dans le
champ Auto-login username :

 Dans la rubrique Connection  SSH choisir 2 comme Preferred SSH

protocol version :
 Dans la rubrique Connection  SSH  Auth, renseigner le champ Private
key file for authentication avec le chemin vers le fichier contenant votre clé
privée.
 Revenir à la rubrique Session, renseigner le champ Saved Session par un
nom parlant (de type Allegro) et sauver :
I.1.d. Démarrer une session

 Toujours dans Putty, ouvrir la session Allegro en cliquant sur Open

 Une fenêtre s'ouvrira pour indiquer la clé de allegro. Cette clé ne devrait pas
changer dans le futur. Si ce message apparaît encore à l'avenir, ce n'est pas
normal... Accepter la clé d'allegro.
 Putty ouvre un terminal et votre passphrase vous est demandée. Si elle est
bien tapée, la session est ouverte. Après plusieurs tentatives
infructueuses, Putty renoncera à utiliser la passphrase et finira par vous
demander votre mot de passe.

I.2. SSH Secure Shell Client

C'est un autre utilitaire permettant de se connecter par SSH. Le site officiel est
celui-ci : http://www.ssh.com/. Le site propose en téléchargement une version
gratuite (3.2) à usage non commercial. On la trouve dans la
rubrique Download puis Non-commercial Versions. Voici un lien direct pour
télécharger le client 3.2.9. Sur les PC, il y a déjà une version d'installée.

I.3. WinScp
 Cet utilitaire est un client scp/sftp graphique. Il permet donc de transférer des
fichiers à distance en utilisant simplement une connexion SSH établie pour
l'occasion. Le site officiel est celui-ci http://winscp.net/eng/index.php. Une version
opérationnelle se trouve ici.

I.4. FileZilla

A l'instar de WinScp, FileZilla est un logiciel permettant de transférer des

fichiers par sftp (mais pas seulement). Le site officiel
est http://filezilla.sourceforge.net/. Une version opérationnelle est ici.

II. Tunnels SSH et redirection de port

SSH n'est pas seulement un Telnet sécurisé. Il propose de multiples utilisations
dont une qui est particulièrement intéressante : la création de tunnels combinée à la
redirection de port (Port forwarding).

II.1. Principe

Supposons que depuis notre ordinateur arthur l'on ait accès à la

machine merlin qui héberge un serveur SSH, ainsi qu'un serveur POP3. On
démarre alors une session SSH distante depuis arthur vers merlin :

où, le client SSH utilise le port TCP 12345 sur arthur . La connexion SSH est
sécurisée : à part une attaque de type "Man in the middle" à l'établissement de la
connexion, le trafic sur cette connexion n'est pas déchiffrable par une tierce
personne.

Si régulièrement on utilise son client de messagerie préféré pour rapatrier son

courrier depuis arthur, alors on établit à chaque fois une connexion avec le
serveur POP3 de merlin :
 où le client de messagerie utilise le port TCP 54321 sur arthur. Ici la
connexion POP3 n'est pas sécurisée : toute la discussion circule en clair. Cela
comprend le nom d'utilisateur et le mot de passe qui circulent en ASCII et peuvent
être "observés" sur le réseau.

Cependant on peut utiliser la connexion SSH établie afin de faire "passer" une ou
plusieurs autres connexions. Cela est possible en créant un tunnel à travers la
connexion SSH :

Sur la figure, le tunnel relie le port TCP 55555 d'arthur au port TCP 110
de merlin. Tout se passe comme si un serveur POP3 était actif sur arthur, en
écoute sur le port 55555. En général, ce serveur n'accepte que des connexions
locales (pas d'une machine autre qu'arthur) et utilise alors l'adresse 127.0.0.1. On
peut toutefois configurer le tunnel pour que le serveur accepte des connexions de
machines distantes (il utiliserait alors son adresse IP). Pour le moment, on
considère que le serveur n'accepte que des connexions locales.

La capture d'écran ci-dessous est le résultat de la commande netstat sur la

machine arthur (192.168.1.100) qui a établi une
connexion SSH avec merlin (139.124.187.4) et un tunnel à partir du port 55555.
Le tunnel n'est pas (encore) utilisé car aucune connexion n'est établie avec ce
serveur. On remarque que rien ici ne permet de savoir qu'il y a un lien entre le
serveur 127.0.0.1:55555 et le client SSH 192.168.1.100:12345 :
 Si un client local à arthur se connecte au port 55555 d'arthur, alors la
connexion est redirigée à travers le tunnel vers le port 110 de merlin. Tout le trafic
sur la connexion SSH étant crypté, la connexion ainsi redirigée est elle aussi
cryptée.

Voici ci-dessous le résultat de la commande netstat lorsque la connexion entre un

client de messagerie (127.0.0.1:3186) est établie avec le "serveur" 127.0.0.1:55555.
 Sur merlin, le serveur SSH qui se trouve à l'autre bout du tunnel doit alors
établir une connexion avec le serveur POP3. Voici le résultat de netstat sur merlin :

Remarquons au passage que la connexion SSH entre merlin (139.124.187.4)

et arthur (192.168.1.100) se fait via la machine (81.82.83.84). En effet l'adresse
d'arthur est une adresse privée, et la machine 81.82.83.84 est un routeur effectuant
du NAT.
II.2. Mise en place du tunneling POP3

II.2.a. Putty

Putty, comme tout client SSH qui se respecte, permet de mettre en place un
tunnel. Cela se fait avant d'ouvrir une session SSH. Pour cela, en plus des
informations nécessaires au démarrage d'une session SSH comme vu
précédemment, il faut renseigner la page Connection  SSH  Tunnels. Dans la
rubrique "Add new forwarded port:", il faut indiquer le port local à rediriger dans
"Source port", et le serveur destination dans "Destination" comme ceci :

puis cliquer sur "Add' afin de valider la saisie :

Remarques (qui ne concernent pas que Putty) :

 La destination est interprétée par le serveur SSH à l'autre bout de la

connexion. L'alias merlin doit être connu de lui. Dans l'exemple, l'autre bout
de la connexion est merlin qui devrait se connaître lui-même... On peut
utiliser un nom complètement qualifié de type merlin.excalibur.org ou
encore une adresse IP.
 La destination n'est pas forcément la même machine que celle sur laquelle
est ouverte la session SSH. En effet, on peut créer un tunnel pour contacter
un serveur sur une machine que l'on ne pourrait pas atteindre directement.
C'est une possibilité particulièrement intéressante de SSH.

Supposons que le serveur POP3 n'est pas hébergé par merlin mais
par guenievre et qu'un firewall empêche arthur d'accéder à guenievre. La
solution consiste à établir une session SSH entre arthur et merlin et
d'utiliser cette session pour réaliser un port forwarding depuis (par exemple)
le port 55555 d'arthur vers le port 110 de guenievre (atteint via merlin) :
 Pour cela, il suffit d'indiquer en destination guenievre:110 (ou le nom
complet ou l'adresse IP à la place de guenievre).

Attention : la connexion entre merlin et guenievre n'est pas cryptée. Il

est alors possible à quelqu'un situé
entre merlin et guenievre d'espionner cette connexion.

 On peut mettre en place plusieurs tunnels sur une même connexion SSH.
 On peut mettre bout à bout les tunnels.
 Il est possible de mettre en place un tunnel sans que la session SSH n'ouvre
un terminal.

II.2.b. SSH Secure Shell Client

La mise en place d'un tunnel se fait aussi avant d'ouvrir la session SSH. On peut
le faire pour un profil précis en l'éditant par le menu File  Profiles Edit
Profiles et en choisissant le profil puis l'onglet Tunneling :
 On peut aussi réaliser le tunnel sans passer par un profil, directement par la
rubrique Tunneling de la fenêtre Settings accessible depuis le menu Edit :
II.2.c. Utilitaire ssh (sous Linux)

Sous Linux, il existe l'utilitaire ssh (utilisé au cours du TP 6). Celui-ci admet un
grand nombre d'options. Celle permettant de mettre en place un tunnel est l'option -
L local_port:machine_distante:port_machine_distante.

Dans notre cas, si le nom d'utilisateur sur merlin est toto, alors la ligne de
commande est :
[cyril@arthur ~]$ ssh [email protected] -L 55555:merlin:110

Un avantage du ssh en ligne de commandes est la possibilité de rajouter des

redirections de ports. Cela se fait en tapant la séquence spéciale ~C en début de
ligne (le ~ est le caractère d'échappement qui peut être modifié sur la ligne de
commande en utilisant l'option -e). On peut ensuite entrer des nouvelles
commandes -L.
Exemple :
On utilise ici le caractère @ comme caractère d'échappement.
[cyril@arthur ~]$ ssh [email protected] -e '@'
[email protected]'s password:

[toto@merlin ~]$ @C
ssh> -L 55555:merlin:110
Forwarding port.

[toto@merlin ~]$ @?
Supported escape sequences:
@. - terminate connection
@C - open a command line
@R - Request rekey (SSH protocol 2 only)
@^Z - suspend ssh
@# - list forwarded connections
@& - background ssh (when waiting for connections to terminate)
@? - this message
@@ - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

[toto@merlin ~]$ @#
The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5)

II.2. Configuration d'Outlook Express pour le tunnel POP3

Le client de messagerie doit être configuré pour utiliser le tunnel afin de relever
le courrier situé sur merlin. Pour cela, il faut indiquer que le serveur POP3 est situé
sur la machine locale et écoute sur le port 55555 (on peut bien entendu utiliser un
autre port ;-)). Sur Outlook Express, après avoir créé un compte de messagerie, il
faut que le serveur de courrier entrant soit localhost. On le vérifie dans le
menu Outils Comptes puis en ouvrant les Propriétés du nouveau compte,
onglet Serveurs :
On entre le port local (qui est par défaut 110 pour POP3) dans l'onglet Avancé :
II.3. Exercices

1. En utilisant Putty, mettre en place un tunnel SSH entre votre machine

et allegro, qui depuis votre port local 33333 permette d'accéder au
serveur HTTP d'allegro.

Aide : l'URL à taper dans le navigateur doit être http:://localhost:33333. On accède

alors aux pages des profs (par exemple de Frédéric Dumas) en
tapant http://localhost:33333/~dumas/ (le dernier / est nécessaire !). Cette
manipulation faite depuis chez vous vous permet de vous connecter sur les sites des
professeurs de l'IUT...

2. En utilisant SSH Secure Shell Client, faire la même chose mais en passant
par la machine oralinux.

III. Le système X-Window

 Le système X-Window repose sur le protocole X qui a été développé au milieu
des années 1980. Ce protocole permet d'établir des relations entre des
clients X (aterm, xterm, xclock, xbiff, xemacs, xeyes etc.) et des serveurs X qui ont
la charge de gérer l'affichage des fenêtres, la gestion des claviers et des souris, etc.

Si allegro dispose bien de son (ou ses) serveur(s) X (actuellement en version

11), nous ne l'utilisons jamais ! En effet, chaque PC des salles de TP dispose de son
propre serveur X : l'application X-Win32.

Le rôle de X-Win32 est de dessiner des fenêtres (les clients) qui ont été
exécutées sur un ordinateur distant (généralement allegro pour nous), de gérer les
événements claviers et souris qui se produisent sur la fenêtre X-Win32, de rendre
compte aux clients des événements qui sont leur sont survenus (clic de souris,
touche tapée, etc.) et de redessiner les fenêtres lorsque les clients le lui demandent
(suite à l'insertion de caractères, au tracé d'un graphique, etc.).

III.1. Fonctionnement du système à l'IUT

Lorsque vous lancez X-Win32 sur un PC de l'IUT il y a deux possibilités :

 soit X-Win32 est configuré pour fonctionner en mode Query XDCMP sur
allegro, auquel cas une demande de connexion est adressée directement à
allegro qui lance alors un client X qui gère l'invite de connexion. En réalité,
il s'agit d'un serveur xdm (X Display Manager) qui se comporte comme un
client. À ce stade, notre serveur doit afficher la fenêtre du client et lui
renverra les informations tapées. Si le client est satisfait de ce qui est tapé,
une véritable session est lancée contenant un gestionnaire de fenêtres (en
principe GNUStep), et les différentes fenêtres que vous avez souhaité lancer
au démarrage. Sur GNUStep, la description de ces fenêtres est sauvée dans le
fichier ~/GNUstep/Defaults/WMState. Comme dit précédemment, chaque
fenêtre est un client X. Le gestionnaire de fenêtre est lui-même un
client X dont le rôle est de proposer un certain bureau ainsi qu'un "Look and
Feel" (une apparence des fenêtres).
 soit X-Win32 est configuré pour fonctionner en mode broadcast XDCMP.
Dans ce cas, il diffuse une requête (donc en broadcast) demandant s'il existe
des machine qui ont un serveur XDM prêt à accepter une tentative de login.
Une liste de machines est alors dressée. Lorsqu'on en choisi une, tout se
passe comme le mode Query XDCMP.

III.2. La notion de DISPLAY et des autorisations d'affichage

Puisque sur allegro, il y plusieurs clients X qui tournent en même temps,

comment savent-ils quel serveur contacter pour être affichés ? C'est la variable
d'environnement DISPLAY qui le leur dit. Lorsque vous vous êtes logés en
utilisant X-Win32, alors celui-ci a créé la variable d'environnement DISPLAY qui
précise le serveur à contacter pour afficher les fenêtres, ainsi que le terminal dont il
s'agit.

La variable DISPLAY contient une chaîne de la

forme : machine:numero_display.numero_ecran, où :

 machine est le nom ou l'adresse de la machine hébergeant le serveur. Elle

peut être vide si le serveur est local.
 numero_display est le numéro commençant à 0 et désignant la paire
clavier/souris de l'utilisateur. En général, il n'y en a qu'une par machine,
donc c'est 0.
 numero_ecran est le numéro commençant à 0 et désignant l'écran de
l'utilisateur car il peut y en avoir plusieurs.

Une alternative à la variable DISPLAY est l'utilisation de l'option -

display machine:numero_display.numero_ecran que de nombreux
clients X proposent.
Exemple :

Sur la machine D174, après s'être logé par X-Win32, la

variable DISPLAY devrait contenir : D174:0.0. En laçant la commande aterm,
celle-ci que le serveur à contacter est sur D174 et que c'est celui gérant le
display 0.0. Sans la variable DISPLAY, on aurait le même résultat en tapant aterm -
display d174:0.0.

Dans les deux cas, il faut être autorisé à afficher des fenêtres sur le serveur. X-
Win32 gère ceci de façon transparente en émettant un MAGIC-COOKIE que les
clients doivent utiliser dans leurs échanges avec le serveur.

Une autre solution est d'indiquer au serveur X les machines qui sont susceptibles
d'être la source de clients X qui lui demanderont d'afficher des fenêtres. Dans X-
Win32, cela se fait avant de lancer le serveur, en précisant les machines dans X-
Config, rubrique Sécurité.

Sous Linux (et Unix), lorsqu'un serveur X est actif, on indique ces machines par
la commande xhost :

 xhost +machine ajoute machine à la liste des machines autorisées à

demander des affichages X.
 xhost -machine la retire de la liste.

Bien entendu, utiliser xhost ou l'autorisation par X-Win32 est très dangereux car
cela permet à n'importe qui de lancer des applications sur son serveur X, depuis la
machine autorisée.
 Seule l'utilisation des MAGIC-COOKIE permet un niveau de sécurité suffisant.

III.3. Redirection X11

Cette partie explique comment utiliser X-Win32 (ou n'importe quel serveur X)
de façon à lancer des fenêtres sur allegro depuis chez soi et les afficher sur son
ordinateur préféré :-) (certains diront mieux vaut tard que jamais lol).

Bien que la méthode xhost soit possible, il faut l'éviter car même si l'on ne craint
pas (quelle erreur !) que quelqu'un lance une application sur notre machine, il faut
savoir que la connexion entre le client et le serveur X est en clair. Autrement dit, on
peut observer tous les caractères qui sont tapés sur la fenêtre en question...

La méthode indiquée ici est bien plus sécurisée car nous allons utiliser un
tunnel SSH pour rediriger ces connexions. Cela se demande par la redirection X11.

III.3.a. Configuration de X-Win32

Il n'y a pas de session X-Win32 en tant que telle à établir. Tout se passe en
arrière plan pour X-Win32. Il faut d'abord lancer l'utilitaire X-Config et dans la
partie Mode fenêtre de l'onglet Fenêtre, choisir Multiple (il y aura une fenêtre
Windows par client X lancé) comme ci-dessous :

Puis, dans l'onglet Sécurité, il faut ajouter localhost dans la liste des
clients xhost autorisés, et cocher les cases Contrôle d'accès et Utiliser XAuth pour
activer les MAGIC-COOKIES :
 Cliquer ensuite sur OK pour sauver les changements. Lancer X-Win32 sans
lancer de session.

Attention : si vous avez des sessions pré-enregistrées, la première est sûrement

lancée automatiquement. Pour la fermer sans quitter X-Win32, faire un clic droit
sur la barre du haut et choisir Réinitialiser.

L'icône X-Win32 apparaît alors dans les applications systèmes en bas à droite de
l'écran :
III.3.b. Configuration d'un client SSH (Putty) pour la redirection X11

Si elle a déjà été créée, charger la session correspondant à allegro depuis la

rubrique Session. Si elle n'a pas été créée, renseigner la partie Host
Name avec allegro.iut.univ-aix.fr et cocher le bouton radio SSH de Protocol :
 Dans la rubrique Connection SSH, cocher Enable compression et 2
comme Preferred SSH protocol version :
 Dans la rubrique Connection SSH Tunnels, cocher Enable X11
forwarding et indiquer localhost:0 en tant que X display location :
Enfin, sauver la session :
 Ouvrir une session sur allegro. On peut alors vérifier avec netstat qu'une
connexion SSH est bien établie :
On peut alors lancer un aterm depuis la session putty :
 On peut au passage vérifier le contenu de la variable DISPLAY sur la
session Putty ou dans le aterm : elle devrait contenir allegro:10.0. On peut à
nouveau vérifier les connexions sur notre machine locale. Il y a une connexion
supplémentaire entre notre aterm 127.0.0.1:3050 et X-Win32 127.0.0.1:6000 :
 Un netstat sur allegro nous montre les connexions correspondantes. Il y a celle
entre la machine locale (xxxxxxx:3030) et le serveur SSH (139.124.187.4:22), et la
connexion entre le aterm (127.0.0.1:42895) et le port redirigé (127.0.0.1:6010) qui
correspond au display allegro:10.0 :
 Encore une fois, on se rend compte que la machine locale est en fait derrière
un NAT. Après avoir lancé 2 aterms, on peut regarder à nouveau les connexions
actives sur la machine locale :
 Enfin, on peut vérifier que le forwarding X11 a bien été réalisé en faisant un clic
droit sur la barre de la fenêtre Putty, et en choisissant Event Log :
III.3. Exercices

Si vous pouvez utiliser X-Config sur votre poste, réalisez un forward X11 et
lancez des fenêtres depuis allegro.