TP Sur SSH I. Introduction à SSH

TP Sur SSH
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 scpet
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 à
tapenad avec plink, il suffit de taper plink tapenad.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\Documents\truc.txt
[email protected]:machin.txt copie le fichier
truc.txt sur le compte de dumas.f 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 orangead.
•
•
•
•
•
Sur orangead, créer le répertoire .ssh si il n'existe pas. 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
tapenad.iut.univ-aix.fr et choisir SSH comme Protocol :
•
Dans la rubrique Connection Data, 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 Orangead) et sauver :
I.1.d. Démarrer une session
•
•
•
Toujours dans Putty, ouvrir la session Tapenad en cliquant sur Open
Une fenêtre s'ouvrira pour indiquer la clé de Orangead. 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é
de Tapenad.
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.
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
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
orangead doit être connu de lui. Dans l'exemple, l'autre bout de la connexion est orangead
qui devrait se connaître lui-même... On peut utiliser un nom complètement qualifié de type
orangead.esil.univmed.fr 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. Utilitaire ssh (sous Linux)
Sous Linux, il existe l'utilitaire ssh. 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]'spassword:
[toto@merlin~]$ @C
ssh> -L 55555:merlin:110
Forwardingport.
[toto@merlin~]$ @?
Supportedescape sequences:
@. - terminateconnection
@C - open a command line
@R - Requestrekey(SSH protocol2 only)
@^Z - suspend ssh
@# - listforwardedconnections
@& - background ssh (when waitingforconnectionsto terminate)
@? - thismessage
@@ - send the escape characterby typingittwice
(Notethatescapesare onlyrecognizedimmediatelyafternewline.)
[toto@merlin~]$ @#
The followingconnectionsare open:
#0 client-session(t4r0 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 POP3est 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 Tapenad, qui
depuis votre port local 5000 permette d'accéder à un serveur netcat lancé sur le port
6000. (nc -lp 6000)
2. En utilisant Putty, vous pouvez aussi ouvrir un port distant, c'est à dire ouvrir sur la machine
du bout du Tunnel un port vers la machine originaire du tunnel. Cela s'appele le remote
forwarding port.
1. Lancer un serveur netcat sur un port local de votre PC.
2. Trouver le nom de votre PC avec la commande hostname.
3. Configurer un tunnel Putty avec un Remote port et non plus un Local port vers votre
PC
4. Ouvrir la session putty
5. Faire telnet sur le port local choisi sur Tapenad (remarque : on peut pour agrémenter
l'expérience changer de serveur avec ssh et faire le telnet depuis un autre serveur vers
tapenad)
3. Mettre deux tunnels bout à bout :
1. Lancer nc sur un port local du PC
2. Ouvrir Putty avec une redirection d'un remote port de Orangead vers votre PC
3. Se connecter sur Sardinad avec SSH
4. Configurer une redirection d'un Local port sur Sardinad vers le port Remote Port de
Orangead à travers un tunnel allant vers Leningrad.
5. Faire un telnet sur le port local de Sardinad ...
Le résultat doit être que le port local de Sardinad doit être redirigée dans le tunnel SSH vers
Leningrad, de Leningrad le message doit circuler en clair vers Orangead ou il est redirigé une
troisième fois vers le PC à travers un second tunnel SSH pour arriver sur le NC du PC !!!