Contenu:

Installation de ssh, côté serveur
Installation de ssh, côté client
Utilisation de ssh-agent et ssh-add
Port forwarding
Ssh et X Window

Installation de ssh, côté serveur

Pour faire de votre machine un serveur SSH, c'est à dire que les utilisateurs d'autre machines puissent lancer des commandes sur votre ordinateur tout en ayant la garantie que les données échangées entre ces deux points ne soient pas lisibles par une tierce partie, il faut procéder comme suit:

Installation et utilisation de ssh, côté client

Pour établir une connexion encryptée qui permettra d'exécuter de manière plus sûre des commandes sur un serveur SSH, il faut procéder comme suit:

Comme indiqué, il faut réaliser l'étape ci-dessus en étant root. Par contre les étapes suivantes doivent être effectuées par chaque utilisateur individuellement:

Si vous utilisez SSH comme indiqué ci-dessus, vous serez bien vite ennuyé de devoir sans cesse entrer la passphrase permettant de lire votre clef privée et vous commencerez à regretter rsh et rlogin. Heureusement, il y a une solution: utilisez ssh-agent et ssh-add. Ceci est l'objet du paragraphe suivant.

Utilisation de ssh-agent et ssh-add

Le principe des programmes ssh-agent et ssh-add est le suivant: ssh-agent est un démon dont le double rôle est d'intercepter votre clef privée lorsque le programme ad hoc ssh-add l'aura lue (après vous avoir demandé votre passphrase une seule et unique fois), puis de transmettre cette clef aux processus dont il est l'ancêtre lorsque ceux-ci le demandent. Typiquement il s'agira des commandes ssh ou slogin qui à travers ce procédé n'auront plus besoin de vous demander sans cesse d'entrer la passphrase. ssh-agent ne peut offrir ce service qu'à ses descendants parce que seuls ces derniers peuvent hériter du socket que SSH utilise à cet effet.

Dans la pratique, une des configurations suivantes est typique:

Port forwarding

Avant d'expliquer l'influence que peut avoir SSH dans l'utilisation de X Window, il faut traiter du port forwarding.

Les services disponibles sur un serveur se distinguent par le port sur lequel ils "écoutent" les requêtes provenant des clients. Par exemple, les démons httpd, rlogind et telnetd utilisent traditionnellement les port TCP 80, 513 et 23, respectivement. D'autres numéros de port d'usage courant sont listés dans le fichier /etc/services, avec leur nom tel qu'il est utilisé par diverses routines et utilitaires (netstat, lsof, etc.) Le serveur sshd utilise quant à lui le port 22, proche du port 23 de telnetd pour exprimer que le service offert (sessions interactives à distance) est comparable. La grosse différence est bien sûr la confidentialité des données échangées, obtenue par l'encryptage de la connexion.

Mais SSH est également capable de fournir cet encryptage à d'autres services par le biais du port forwarding (options -L et -R de la commande ssh), de la manière suivante. Supposons que sur la machine HOST2, j'entre la commande: 

       HOST2:   /usr/local/bin/ssh -L p1:HOST4:p2 HOST3
ou que sur la machine HOST3, j'entre la commande: 
       HOST3:   /usr/local/bin/ssh -R p1:HOST4:p2 HOST2
alors j'aurais la situation suivante: 


                    XXXXXXXXX>  connexion encryptée
                    --------->  connexion simple

         +-------------+                  +-------------+
         |             |                  |             |
         |             |                  |             |
         |    HOST 1   |                  |    HOST 4   |
         |             |                  |             |
         |             |                  |             |
         +-------------+                  +-------------+
                |                                ^ p2
                |                                |
                |                                |
                |                                |
             p1 V                                |
         +-------------+                  +-------------+
         |      |      |                  |      ^      |
         |      |      |                  |      |      |
         |      `----->|XXXXXXXXXXXXXXXXX>|------'      |
         | HOST 2      |                  |      HOST 3 |
         |             |                  |             |
         +-------------+                  +-------------+
c'est à dire qu'en me connectant depuis la machine HOST1 sur le port p1 de la machine HOST2, cette connexion sera transférée (forwarding) vers le port p2 de la machine HOST4, via HOST3.

Comme on le voit sur la figure ci-dessus, les connexions entre HOST1 et HOST2 ainsi qu'entre HOST3 et HOST4 ne seront pas encryptées. C'est pourquoi dans les applications, on a toujours HOST1 = HOST2 et HOST3 = HOST4: 

       HOST2:   /usr/local/bin/ssh -L p1:HOST3:p2 HOST3
       HOST3:   /usr/local/bin/ssh -R p1:HOST3:p2 HOST2
et sur HOST2, on se connecte localement au port p1 pour aboutir à la situation suivante: 


             ___                                ___ 
            |   |                              |   |
            |   V p1                           |   V p2
         +--+----------+                  +----+--------+
         |  |   |      |                  |    ^        |
         |  ^   |      |                  |    |        |
         |      `----->|XXXXXXXXXXXXXXXXX>|----'        |
         | HOST 2      |                  |      HOST 3 |
         |             |                  |             |
         +-------------+                  +-------------+
De cette manière, je peux mettre en place une connexion encryptée entre HOST2 et n'importe quel service (c'est à dire n'importe quel port p2) de HOST3.

Exemple pratique, je travaille sur HOST2 et je veux effectuer un transfert FTP entre HOST2 et HOST3 sans que mon mot de passe ne soit visible sur le réseau:

Attention: le fonctionnement de FTP fait que cette connexion encryptée n'est pas utilisée pour transférer les fichiers, uniquement les commandes de FTP et le mot de passe.

Quelques remarques pour conclure ce paragraphe:

SSH et X Window

SSH met en place automatiquement le port forwarding décrit ci-dessus pour que les échanges du protocole X Window se fasse par une connexion encryptée.

Il faut bien se rendre compte à quel point ce service que nous rend SSH est précieux et indispensable si nous travaillons dans un environnement X Window. La situation suivante est typique. Je travaille sur ma station (machine1) où s'affichent les fenêtres clientes de mon serveur X. Conscient que les pirates vont peut-être "renifler" le câble, j'utilise la commande ssh pour ouvrir une session sur une machine remote, machine2. Je dois y éditer un fichier et j'ai l'habitude de le faire avec un outil X, xedit par exemple. Je fais donc: 

          setenv DISPLAY machine1:0
          /usr/local/bin/X11/xedit <fichier>
Problème: le dialogue X entre les deux machines utilise sa propre connexion TCP/IP et ne passe pas par le canal encrypté de ma session SSH: les éventuels pirates peuvent espionner toute ma session d'édition du fichier (ce peut être assez grave si j'édite par exemple /etc/passwd car ils pourront essayer de le cracker). De même pour une commande "xterm -display machine1:0" ou équivalente: les pirates peuvent suivre tout ce que je tape au clavier, y compris le mot de passe si j'utilise su pour devenir le root de machine2.

Pour éviter cela et pour que les clients X s'exécutant sur la machine remote machine2 dialoguent avec votre machine locale machine1 (dont vous avez le display sous les yeux) à travers la connexion encryptée mise en place par SSH, il faut utiliser la valeur de la variable DISPLAY figurant automatiquement dans votre environnement sur la machine2 si vous y ouvrez une session interactive par la commande ssh.

Cette valeur est de la forme machine2:n (où n est un petit nombre entier) et le fait que son utilisation provoque l'affichage des fenêtres sur machine1 (et non machine2) est une indication que le port forwarding est en jeu.

Rappelons en effet que les clients X se basent sur la forme de la variable d'environnement DISPLAY pour trouver le chemin du serveur X où dessiner leurs fenêtres. La convention est la suivante: pour une valeur de cette variable de la forme "machine:n", le client se connecte à l'adresse machine au port 6000 + n. Ainsi une variable DISPLAY de la forme machine2:n sur la machine machine2 indique que les clients X se connectent localement pour atteindre en fait la machine machine1, ce qui est bien le comportement typique du port forwarding de SSH.

Dans la pratique, l'utilisation sûre de X Window à travers SSH passe par les précautions suivantes:

Martin Ouwehand

Updated: Fri May 28 16:45:01 METDST 1999