|
IUT Info Aix-en-Provence |
© Cyril Pain-Barre |
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.
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 :
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
cpb@allegro.iut.univ-aix.fr:machin.txt copie le fichier truc.txt sur le compte de cpb
d'allegro en l'appelant machin.txt ;
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.
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.
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.
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.
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).
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.
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 :
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.
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 :
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 toto@merlin.excalibur.org -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.
On utilise ici le caractère @ comme caractère d'échappement.
[cyril@arthur ~]$ ssh toto@merlin.excalibur.org -e '@'
toto@merlin.excalibur.org'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)
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é :
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...
En utilisant SSH Secure Shell Client, faire la même chose mais en passant par la machine oralinux.
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.).
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.
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.
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.
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.
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 :
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 :
Si vous pouvez utiliser X-Config sur votre poste, réalisez un forward X11 et lancez des fenêtres depuis allegro.