UE31 - M3102 : Services Réseaux
Enoncé du TP 2
Services SSH et TELNET
IUT Aix-Marseille - INFO Aix
C. Pain-Barre
Table des matières
1
2
Introduction à SSH
1.1 Notion de chiffrement . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.A Critique du chiffrement symétrique . . . . . . . . . . . . . . . . .
1.1.B Le chiffrement asymétrique . . . . . . . . . . . . . . . . . . . . .
1.1.B.1 Paires de clés et trousseau . . . . . . . . . . . . . . . . .
1.1.B.2 Cryptage/Décryptage par paire de clés . . . . . . . . . .
1.1.B.3 Signature/vérification par paire de clés . . . . . . . . . .
1.2 Authentification d’un serveur SSH . . . . . . . . . . . . . . . . . . . . . .
1.2.A Emplacement des clés d’un serveur SSH . . . . . . . . . . . . . . .
1.2.B Procédure d’authentification du serveur et cryptage de la connexion
1.2.C Authentification du serveur lors de la première connexion . . . . .
1.2.D Enregistrement de la clé publique du serveur côté client . . . . . . .
1.2.E Hashage des fichiers known_hosts . . . . . . . . . . . . . . . . . .
1.2.F Contrôler manuellement la clé publique du serveur . . . . . . . . .
1.2.G Supprimer manuellement la clé publique d’un serveur . . . . . . .
1.3 Authentification de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . .
1.3.A Authentification utilisateur par mot de passe . . . . . . . . . . . . .
1.3.B Authentification utilisateur par paire de clés . . . . . . . . . . . . .
1.4 Connexion à allegro avec mot de passe . . . . . . . . . . . . . . . . . . . .
Exercice 1 (connexion SSH sur allegro) . . . . . . . . . . . . . . . . . . .
1.5 Création d’une paire de clés sous Linux . . . . . . . . . . . . . . . . . . .
Exercice 2 (Génération d’une paire de clés avec ssh-keygen) . . . . . . . .
1.6 Déposer sa clé publique sur le serveur . . . . . . . . . . . . . . . . . . . .
Exercice 3 (dépôt manuel de la clé publique sur allegro) . . . . . . . . . . .
1.7 Préparation à l’utilisation de la paire de clés . . . . . . . . . . . . . . . . .
Exercice 4 (mise en conformité des droits) . . . . . . . . . . . . . . . . . .
1.8 Connexion avec la paire de clés . . . . . . . . . . . . . . . . . . . . . . . .
Exercice 5 (Connexion sur allegro par paire de clés) . . . . . . . . . . . . .
1.9 Le fournisseur de passphrase ssh-agent . . . . . . . . . . . . . . . . . . . .
Exercice 6 (utilisation de ssh-agent) . . . . . . . . . . . . . . . . . . . . .
Possibilités offertes par SSH
2.1 Exécution de commandes à distance par ssh . .
Exercice 7 (exécution de commandes distantes)
2.2 Copie de fichiers/répertoires par scp . . . . . .
Exercice 8 (copie sécurisée par scp) . . . . . .
2.3 Transfert de fichiers par sftp . . . . . . . . . .
Exercice 9 (transfert de fichiers par sftp) . . . .
2.4 Profils et options de ssh . . . . . . . . . . . . .
IUT Aix-Marseille - INFO Aix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23/12/2014
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
4
4
5
5
6
7
7
7
8
8
9
9
10
10
10
11
11
12
13
13
14
14
14
15
15
15
16
.
.
.
.
.
.
.
17
17
18
19
20
20
21
21
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
2/31
3
SSH et la redirection de ports (tunneling)
24
3.1 Principe du tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Mise en place de la redirection de port local avec ssh . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Mise en place de la redirection de port distant avec ssh . . . . . . . . . . . . . . . . . . . . . . . 27
4
Et SSH sur Windows ?
5
Jouons un peu avec les services TELNET, SSH et HTTP
Exercice 10 (Démarrage d’un lab Marionnet et d’une VM XP)
Exercice 11 (Activation du service TELNET sur m2) . . . . .
Exercice 12 (Service SSH sur m2 et tunneling SSH) . . . . . .
Exercice 13 (Service HTTP sur m2 et tunneling SSH) . . . . .
C. Pain-Barre -
23/12/2014
27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
28
29
30
31
IUT Aix-Marseille - INFO Aix
3/31
1
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
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 sous-modules 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.
Une différence notable entre TELNET (ou rsh) et SSH est que ce dernier établit un canal de transmission
full-duplex fiable et crypté entre le client et le serveur. Ainsi, alors que tout le trafic dans le protocole TELNET
passe en clair sur le réseau (y compris le nom d’utilisateur et son mot de passe), en SSH ce trafic est crypté. Il est
donc beaucoup plus sécurisé.
Avant d’établir le canal crypté, SSH prévoit une authentification du serveur par le client. Puis, lorsque ce
canal est établi, c’est au serveur qu’il incombe d’authentifier l’utilisateur qui souhaite se loger (ou utiliser ses
fonctionnalités).
SSH utilise le chiffrement asymétrique pour crypter certains échanges puis utilise un cryptage symétrique une
fois les paramètres de la communication négociés.
Pour illustrer certaines notions de SSH, nous utiliserons dans un premier temps le client SSH le plus
utilisé sur Linux : ssh. Le serveur SSH sous Linux est généralement sshd.
1.1
Notion de chiffrement
Il existe deux approches au chiffrement : le chiffrement symétrique et le chiffrement asymétrique. Avant de
présenter le chiffrement asymétrique, on va d’abord critiquer le chiffrement symétrique.
1.1.A
Critique du chiffrement symétrique
Pour le chiffrement symétrique, un fichier est crypté/décrypté à l’aide d’une unique clé. Ainsi, lorsqu’on
communique un fichier crypté à quelqu’un, cette personne doit posséder la clé qui a permis le cryptage pour
pouvoir décrypter le fichier. Le principe est illustré par la figure 1.
clé partagée entre
l’émetteur et le récepteur
abc
efg
ijk
récepteur
émetteur
abc
efg
ijk
cryptage
décryptage
010
101
010
transmission
010
101
010
F IGURE 1 – Chiffrement symétrique : même clé pour le cryptage/décryptage
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
4/31
Le problème est que quiconque possède cette clé sera en mesure de décrypter les données confidentielles.
Ainsi, si la personne à qui on a communiqué notre clé n’est pas très prudente, on court le risque de perdre la
confidentialité de nos transmissions. D’autre part, on peut très bien envoyer un fichier crypté à quelqu’un mais
souhaiter que cette personne ne puisse pas décrypter les autres fichiers que l’on crypte. Dans ce cas, il faut utiliser
une clé spécialement pour l’échange avec cette personne. C’est déjà pénible mais ce n’est pas tout : comment
transmettre une clé, en étant sûr que personne ne la récupère et puisse ainsi lire les données transmises ? Les
moyens de communication étant régulièrement "écoutés" par différentes "organisations" (si ce n’était pas le cas,
ce ne serait pas la peine de mettre en place un cryptage des données. . .), que reste-t-il ? une communication en
mains propres ?
Manifestement, cette méthode de chiffrement pose de nombreux problèmes et on comprend pourquoi elle est
de moins en moins utilisée seule.
1.1.B
Le chiffrement asymétrique
Le chiffrement asymétrique est une méthode de chiffrement qui apporte une solution intéressante aux problèmes de gestion de clé que connaît le chiffrement symétrique.
Il nécessite l’emploi d’une paire de clés :
• une clé privée qui, comme son nom l’indique, doit demeurer privée et jamais communiquée. Néanmoins,
elle doit être stockée sur l’ordinateur qu’utilise son créateur (possesseur). Celui-ci doit donc impérativement la protéger au mieux, notamment par l’intermédiaire d’une "passphrase" et en la rangeant dans un
répertoire et un fichier inaccessibles aux autres.
• une clé publique qui, elle, peut être communiquée au reste du monde, sans aucun risque de dévoiler la
clé privée. En effet, si les deux clés sont étroitement liées, il n’est pas possible de fabriquer la clé privée à
partir de la clé publique. En revanche, si la clé publique est perdue, il sera possible de la générer à partir
de la clé privée.
Le chiffrement asymétrique permet le cryptage mais aussi la signature numérique de documents, qui ont
des objectifs différents :
• cryptage : il s’agit de protéger un document en le cryptant. Seuls les détenteurs d’une clé appropriée
pourront le décrypter et le lire ;
• signature : il s’agit d’authentifier un document ainsi que son rédacteur.
Le terme chiffrement est souvent employé dans les documentations à la place de cryptage. Par la suite,
nous l’employons dans son sens large, recouvrant la signature.
1.1.B.1
Paires de clés et trousseau
Différents utilitaires existent pour créer un paire de clés publique et privée, notamment l’outil libre gpg —
abréviation de GnuPG (The GNU Privacy Guard)— qui est disponible à la fois pour Linux et Windows.
En utilisant gpg, on crée un trousseau de clé comportant une clé privée et la clé publique associée. En outre,
gpg gère aussi les clés publiques que nous ont communiquées les personnes avec lesquelles on désire crypter/signer les échanges.
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
5/31
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
gpg pourra alors être utilisé pour crypter/décrypter et/ou signer/vérifier des documents. Nous n’étudions ici
que les principes du chiffrement et non la génération de clés ni les opérations de cryptage/décryptage ou signature/vérification avec gpg.
On supposera par la suite que les personnes impliquées dans les échanges ont à leur disposition un tel outil.
1.1.B.2
Cryptage/Décryptage par paire de clés
Pour envoyer un document crypté à quelqu’un, l’émetteur doit posséder la clé publique du récepteur. Des
serveurs de clés (publiques) existent sur Internet afin de faciliter la distribution des clés publiques.
clé publique communiquée
aux émetteurs potentiels
de documents cryptés
ur
émette
ée à l’
u
uniq
comm
clé privée que seul le
récepteur possède
abc
efg
ijk
émetteur
abc
efg
ijk
cryptage (clé publique)
décryptage (clé privée)
010
101
010
transmission
010
101
010
récepteur
la clé
té
ue a é
publiq
F IGURE 2 – Cryptage asymétrique avec la clé publique du destinataire qui décryptera avec sa clé privée.
La méthode de cryptage asymétrique est illustrée par le schéma de la figure 2. L’émetteur crypte le document
à l’aide de la clé publique du récepteur. Seule la personne possédant la clé privée peut décrypter le document
crypté. Ainsi, lorsque le récepteur reçoit le document crypté, il le décrypte à l’aide de sa clé privée.
1.1.B.3
Signature/vérification par paire de clés
La signature numérique de document a pour objectif de prouver au récepteur que le document a bien été envoyé par l’émetteur annoncé, et qu’il n’a pas été modifié pendant son transport.
D’un autre côté, la signature numérique assure la non-répudiation : l’émetteur ne peut nier avoir envoyé le
document.
Cette signature est généralement générée par l’algorithme DSA (Digital Signature Algorithm). Le principe de
son utilisation est le suivant, illustré par la figure 3 :
1. L’émetteur calcule une empreinte (fingerprint) du document par une fonction de hashage. La fonction de
hashage doit être telle qu’une modification minime du document produit une empreinte différente et qu’il
est impossible de produire un document à partir d’une empreinte. L’algorithme de hashage généralement
utilisé est SHA1. Il existe aussi MD5 réputé plus faible que SHA1
2. L’émetteur crypte l’empreinte avec sa clé privée par une méthode qui rend possible son décryptage par la
clé publique associée
3. Le récepteur décrypte l’empreinte avec la clé publique de l’émetteur (authentification de l’émetteur)
4. Le récepteur calcule l’empreinte du message et la compare à celle obtenue à l’étape précédente (vérification
de la non modification du message)
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
Enonc´e du TP 2
clé publique communiquée
aux récepteurs potentiels
de documents signés
la clé
publiq
6/31
ue a é
té com
muniq
uée au
clé privée que seul
l’émetteur possède
récepte
ur
émetteur
abc
efg
ijk
abc
efg
ijk
récepteur
UE31 - M3102 : Services R´eseaux
signature (clé privée)
vérification (clé publique)
abc
efg
ijk
abc
efg
ijk
transmission
S
S
F IGURE 3 – Signature d’un document avec la clé privée de l’émetteur. Le récepteur vérifie avec la clé
publique correspondante.
1.2
Authentification d’un serveur SSH
Il s’agit de s’assurer que le client se connecte au bon serveur et non pas à une machine qui aurait usurpé l’IP du
serveur (mise en place par un attaquant pour voler les mots de passe, par exemple) ni à la machine d’un attaquant
située sur le trajet menant au serveur, qui servirait à intercepter ou modifier nos messages. Cette dernière attaque,
de type man-in-the-middle, est illustrée par la figure 4.
client
attaquant
connexion
serveur
connexion
SSH
mowgli
SSH
sherekhan
bagheera
F IGURE 4 – Attaque de type man-in-the-middle
Le principe de cette attaque est le suivant :
• Le client (sur mowgli) veut établir une connexion SSH sur bagheera
• Sur le chemin emprunté par les datagrammes IP se trouve la machine sherekhan de l’attaquant qui intercepte la demande de connexion et répond à la place de bagheera
• L’attaquant établit aussi une connexion SSH entre sherekhan et bagheera
• Lorsque le client s’identifie (pensant avoir à faire à bagheera), il communique son nom d’utilisateur et
son mot de passe qui sont récupérés par l’attaquant
• L’attaquant utilise ces informations pour s’identifier sur bagheera
• Deux connexions SSH sont alors établies, l’une mowgli↔sherekhan et l’autre sherekhan↔bagheera
• L’attaquant fait transiter (automatiquement) les commandes du client vers le serveur, ainsi que les réponses du serveur vers le client, éventuellement en modifiant certaines choses. . .
Cette attaque ne peut en principe être possible que lors de la première connexion du client. Si elle
réussit, elle peut être reproductible.
Pour authentifier le serveur et initier la connexion, SSH utilise une paire de clés publique/clé privée et un
mécanisme de chiffrement asymétrique. Lors de l’installation du serveur SSH, une paire de clés est générée. Elle
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
7/31
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
doit rester la même tant que l’administrateur n’a pas détecté un risque de vol de la clé privée. La clé publique est
destinée à être transmise à tout client qui en fait la demande.
1.2.A
Emplacement des clés d’un serveur SSH
Les clés publiques et privées d’un serveur SSH sous Linux sont situées dans le répertoire /etc/ssh et sont
contenues dans les fichiers :
• ssh_host_dsa_key
• ssh_host_dsa_key.pub
• ssh_host_rsa_key
• ssh_host_rsa_key.pub
• ssh_host_key
• ssh_host_key.pub
Ces 6 fichiers définissent 3 paires de clés :
• les ssh_host_key* définissent les clés pour SSH version 1 (obsolète)
• les ssh_host_dsa_key* définissent les clés DSA pour SSH version 2
• les ssh_host_rsa_key* définissent les clés RSA pour SSH version 2 : ce sont les clés les plus employées.
Les clés publiques sont dans les fichiers d’extension .pub et sont lisibles par tous. Les autres fichiers contiennent
les clés privées et ne sont accessibles qu’à root.
1.2.B
Procédure d’authentification du serveur et cryptage de la connexion
Lors de la connexion du client, le serveur lui renvoie sa clé publique. Le client vérifie alors que cette clé
correspond bien à celle du serveur qu’il aura au préalable stocké dans un fichier de configuration (voir plus loin).
Si c’est le cas, le serveur est authentifié et sa clé publique sera utilisée par le client pour négocier avec le serveur
les clés et les algorithmes utilisés pour crypter les transmissions. En particulier, le client transmet au serveur une
clé de session cryptée avec la clé publique du serveur (ainsi que l’algorithme utilisé) qui sera utilisée ensuite dans
les échanges par un chiffrement symétrique. Le serveur étant le seul à détenir la clé privée, il est le seul qui peut
décrypter la clé de session. La clé de session et les algorithmes seront renégociés régulièrement au cours de la
communication SSH. Notons qu’il y normalement une clé de session par sens de transmission.
✍
1.2.C
La clé publique du serveur est très importante car elle permet d’authentifier le serveur et de lui transmettre la clé de session. Si l’on connaît la clé publique du serveur, cette méthode rend impossible
l’attaque de type man-in-the-middle.
Authentification du serveur lors de la première connexion
Lors de la première connexion du client, celui-ci ne connaît pas la clé publique du serveur et ne peut donc pas
être sûr d’avoir à faire au bon serveur. Selon la configuration du client SSH, celui-ci peut aller jusqu’à refuser le
dialogue avec un serveur inconnu. Dans la grande majorité des cas, le client SSH informe l’utilisateur qu’il ne
peut assurer l’authenticité du serveur et lui demande s’il doit continuer comme dans l’exemple suivant :
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
8/31
$ ssh allegro.iut.univ-aix.fr
The authenticity of host 'allegro.iut.univ-aix.fr (139.124.187.4)' can't be established.
RSA key fingerprint is 93:92:5c:40:21:e5:67:e0:9f:53:11:1f:ec:b1:36:52.
Are you sure you want to continue connecting (yes/no)?
Le nom, l’adresse et les clés d’allegro ont changé depuis la rédaction de ce TP. . .
Il revient donc à l’utilisateur de s’assurer que le serveur est le bon ! L’idéal serait que la clé publique du
serveur soit communiquée au préalable à l’utilisateur (par exemple sur une page Web) mais ce n’est généralement
pas le cas.
La plupart des utilisateurs n’ayant aucun moyen de la vérifier, l’acceptent sans autre vérification,
ce qui les expose aux attaques de type man-in-the-middle. Une possibilité de contrôle de cette clé
est présentée un peu plus loin.
Cette acceptation se fait en répondant yes à la question posée précédemment comme sur l’exemple suivant :
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'allegro.iut.univ-aix.fr,139.124.187.4' (RSA) to the list of known hosts.
Suite à l’acceptation de la clé publique, le serveur est considéré comme authentifié (il devra néanmoins être
capable de décrypter les messages – notamment la clé de session – cryptée avec la clé publique annoncée).
1.2.D
Enregistrement de la clé publique du serveur côté client
La ligne Warning: qui suit l’acceptation de l’utilisateur indique que l’"identité" du serveur (nom, adresse,
clé publique) est enregistrée dans le fichier $HOME/.ssh/known_hosts (de l’utilisateur). Pour les connexions
futures, le serveur devrait être automatiquement reconnu grâce à ce fichier. Si le serveur est connu mais que la
clé publique annoncée n’est pas la même (elle peut avoir changé ou une attaque man-in-the-middle est en cours),
l’utilisateur en sera averti et selon la configuration du client SSH, celui-ci refusera de continuer (mais, le cas
échéant, on pourra modifier le fichier $HOME/.ssh/known_hosts pour enlever la ligne concernant l’ancienne
clé du serveur puis recommencer la connexion).
Il est possible pour l’administrateur système de renseigner le fichier /etc/ssh/ssh_known_hosts
pour contenir les identités de serveurs auxquels les utilisateurs peuvent se connecter. Cela leur évite de
les authentifier eux-mêmes. . .
1.2.E
Hashage des fichiers known_hosts
Selon l’installation du client SSH, les fichiers known_hosts contiennent les clés publiques des serveurs plus
ou moins en clair. Par exemple, la clé d’allegro serait stockée ainsi (sur une ligne) :
$ ssh-keygen -F allegro
allegro,139.124.187.4 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAntyWXC9hVDfBxhXLQ933/
bWLxEQualfiv65C0FnWb6EQ1Ww13ye1tbCUb4lFgbkoAtSgLRld4/2olbw0Gt37XMW2w95VzeqB66nr
aXORQAdk+svyFGGJe5OJ3dCizw0t7LEk0SZ9iLxPF9la1Y+g9P2LCzv+PGvkiuG7lr4dIv6NKTg8oZE
LxWA2QV/cEBOjuIxRo5CgXWFt1eEj43ARJEr0vqRaMLbUlsBJ9p9CPhbu+ZPnPffoHtlRWSobsd2Psu
BcWDXHrACF7EZwr2Og/W8O4wIUqmxIlnGvdQcx0tx54uSL5g/VeN7+8AI1nypcP1Ib+260UttwrvYqN
NdRgQ==
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
9/31
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
Dans cet exemple, le nom court du serveur a été suffisant mais il est possible de devoir utiliser son nom
complet.
Or, on voit que l’adresse IP d’allegro apparaît. Ce n’est pas très sûr car les utilisateurs ont tendance à avoir
le même mot de passe sur les ordinateurs qu’ils utilisent. Si un attaquant a réussi à voler le mot de passe d’un
utilisateur, alors en consultant ce fichier, il sait que cet utilisateur a probablement le même mot de passe sur les
serveurs qu’il contient et peut tenter de s’y introduire. C’est pourquoi généralement les fichiers known_hosts
sont hashés et il n’est pas possible de retrouver les noms ou adresses des serveurs correspondants. En cas de
hashage (comme sur une Debian récente), l’identité d’allegro est stockée par la ligne suivante :
$ ssh-keygen -F allegro
|1|pvSbQKVwGqNFKnsm84Dc6KZ+pVQ=|tgobOSbewGa5WvJ5LQ659BAs0yw= ssh-rsa AAAAB3NzaC
1yc2EAAAABIwAAAQEAntyWXC9hVDfBxhXLQ933/bWLxEQualfiv65C0FnWb6EQ1Ww13ye1tbCUb4lFg
bkoAtSgLRld4/2olbw0Gt37XMW2w95VzeqB66nraXORQAdk+svyFGGJe5OJ3dCizw0t7LEk0SZ9iLxP
F9la1Y+g9P2LCzv+PGvkiuG7lr4dIv6NKTg8oZELxWA2QV/cEBOjuIxRo5CgXWFt1eEj43ARJEr0vqR
aMLbUlsBJ9p9CPhbu+ZPnPffoHtlRWSobsd2PsuBcWDXHrACF7EZwr2Og/W8O4wIUqmxIlnGvdQcx0t
x54uSL5g/VeN7+8AI1nypcP1Ib+260UttwrvYqNNdRgQ==
Dans les deux cas, on peut afficher l’empreinte de la clé publique d’un serveur en ajoutant l’option -l :
$ ssh-keygen -F allegro -l
# Host allegro found: line 1 type RSA
2048 93:92:5c:40:21:e5:67:e0:9f:53:11:1f:ec:b1:36:52 |1|pvSbQKVwGqNFKnsm84Dc6KZ
+pVQ=|tgobOSbewGa5WvJ5LQ659BAs0yw= (RSA)
1.2.F
Contrôler manuellement la clé publique du serveur
Lors d’une première connexion où l’on a dû accepter manuellement la clé du serveur, il est conseillé, une fois
logé en SSH (après s’être authentifié auprès du serveur), de vérifier l’empreinte de cette clé directement sur le
serveur, afin d’être [à peu près] sûr qu’on discute bien avec la machine qui nous a répondu. Cela se vérifie en
tapant la commande suivante :
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
2048 93:92:5c:40:21:e5:67:e0:9f:53:11:1f:ec:b1:36:52 /etc/ssh/ssh_host_rsa_key.pub (RSA)
où le fichier à utiliser doit correspondre au type de clé indiqué lors de la connexion. Ici, l’empreinte correspond
bien et l’on peut être rassuré.
En cas d’attaque man-in-the-middle, l’attaquant doit intercepter cette commande et répondre par l’empreinte de sa machine (celle communiquée au départ). S’il le fait, là, on est mal. . .
1.2.G
Supprimer manuellement la clé publique d’un serveur
Il arrive (malheureusement trop souvent) qu’un serveur ait changé sa clé publique, généralement suite à une
réinstallation alors que l’administrateur n’a pas pris soin de remettre l’ancienne clé. Dans ce cas, lors d’une nouvelle connexion, on a toutes les chances de voir notre client ssh refuser de continuer.
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
10/31
Si l’on est sûr que le changement de clé est normal et non dû à une attaque, il faut alors supprimer du fichier
$HOME/.ssh/known_hosts la clé publique du serveur. Un moyen simple de faire ça (en particulier si le fichier
est hashé) est d’utiliser la commande suivante :
$ ssh-keygen -R serveur
1.3
Authentification de l’utilisateur
Sur le canal crypté établi précédemment, le serveur communique au client les différentes méthodes d’authentification de l’utilisateur qu’il accepte. Il y en a plusieurs. Détaillons celle par mot de passe et celle par paire de
clés publique/privée.
1.3.A
Authentification utilisateur par mot de passe
Le client communique le nom d’utilisateur et un mot de passe que l’utilisateur lui aura indiqués. Si le mot de
passe est correct, le serveur réussit à ouvrir un shell avec l’identité de l’utilisateur, et celui-ci est alors authentifié.
✍
1.3.B
Cette méthode a l’inconvénient majeur de faire transiter le mot de passe de l’utilisateur. Si le serveur
contacté n’est pas le bon (rappelons-nous de la pertinence de l’authentification du serveur), alors le
mot de passe peut être facilement volé.
D’autre part, il est possible que le mot de passe soit volé simplement en regardant par dessus l’épaule
de l’utilisateur pendant qu’il le tape, ou même par un logiciel (keylogger) qui intercepte les frappes au
clavier. . .
Authentification utilisateur par paire de clés
Dans ce contexte, le mot de passe utilisateur ne sera pas transmis au serveur (sauf lors de la première
connexion). Pour cela, l’utilisateur doit au préalable :
• générer une paire de clés publique/privée qui sera utilisée pour l’authentification. La clé privée doit être
protégée par une passphrase (sa taille peut être bien plus grande qu’un mot de passe unix)
• déposer sa clé publique sur le serveur (cette étape nécessite généralement une identification par mot de
passe)
• configurer le client pour utiliser sa clé privée. Cette étape n’est pas nécessaire avec les clients SSH récents
sous Linux.
La méthode d’authentification par paire de clés diffère entre SSH1 et SSH2 mais dans les deux cas le client
SSH demandera à l’utilisateur la passphrase qui protège sa clé privée pour l’utiliser. En SSH2 (il faut éviter SSH1
qui est vulnérable à l’attaque man-in-the-middle 1 ), le client va signer l’identification de session SSH avec la clé
privée de l’utilisateur puis l’envoyer au serveur. Le serveur consulte alors le fichier ~/.ssh/authorized_keys
de l’utilisateur à la recherche d’une clé publique correspondante. S’il en trouve une et que la signature de l’identifiant de session est correcte, l’utilisateur est authentifié.
1. Il existe des attaques man-in-the-middle qui réussissent en forçant le client et le serveur à utiliser SSH1. . .
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
11/31
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
Bien qu’en apparence plus lourde (car la passphrase est plus longue que le mot de passe), cette méthode n’a
que des avantages par rapport à la précédente et devrait être utilisée chaque fois que c’est possible. En effet :
• le mot de passe ne circulant pas (sauf la fois où l’on dépose la clé publique), il ne peut être intercepté
• cette méthode d’authentification (en SSH2) est immunisée contre les attaques man-in-the-middle car
les identifiants de session font partie des informations signées. L’attaquant ayant des identifiants pour les
deux connexions ne peut pas utiliser ce qui vient d’une connexion pour le rediriger sur l’autre qui utilise
un autre identifiant
• même si quelqu’un nous observe quand on tape la passphrase, il y a peu de chances qu’il puisse s’en
souvenir car elle doit être longue
• même si la passphrase est volée, il faut aussi voler la clé privée or elle est contenue dans un répertoire
protégé de l’utilisateur
• il est possible d’utiliser un "agent" SSH dont le rôle est de débloquer la clé privée chaque fois que le client
SSH en a besoin. Dans ce cas, on fournit une seule fois la passphrase à cet agent qui s’en souviendra
durant la session de l’utilisateur pour toutes les connexions SSH qui suivent.
1.4
Connexion à allegro avec mot de passe
Nous commencerons par une connexion à allegro en utilisant l’authentification par mot de passe. Pour cela, il
faut utiliser ssh, le client SSH sous Linux. Celui-ci accepte de nombreuses options dont certaines seront étudiées
au cours de ce TP. Pour une simple connexion à un serveur, 3 syntaxes sont utilisables.
Synopsis
ssh -l utilisateur {-o options-ssh} serveur
ssh {-o options-ssh} utilisateur @serveur
ssh {-o options-ssh} serveur
Les deux premières formes sont équivalentes et doivent être utilisées pour préciser utilisateur comme nom
d’utilisateur si celui-ci diffère entre le client et le serveur. La dernière forme est utilisable si le nom d’utilisateur
est le même sur le serveur que sur le client.
L’option -o permet d’indiquer des options en suivant la syntaxe du fichier de configuration de ssh. Nous y
reviendrons quand nous présenterons ces fichiers.
Exercice 1 (connexion SSH sur allegro)
1. Ouvrir un terminal sur le PC
2. Taper ls -a pour voir si le répertoire .ssh existe. Pour les besoins du TP, supprimer ce répertoire (ou
éventuellement le renommer)
3. Utiliser ssh pour se connecter à allegro (dont le nom complet est allegro.aix.univ-amu.fr) en utilisant le nom
d’utilisateur/mot de passe qui vous ont été communiqués
4. Répondre yes quand l’authentification de la clé publique d’allegro vous est demandée
5. Entrer votre mot de passe quand cela est demandé
6. Une fois logé, vérifier que la clé annoncée est bien celle d’allegro
✍
Laisser cette connexion active, on va s’en servir plus tard.
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
12/31
7. Dans un autre terminal (du PC), vérifier que le répertoire .ssh a bien été (re)créé dans votre répertoire
personnel
8. Consulter ce répertoire, il devrait y avoir le fichier known_hosts
9. Afficher ce fichier, il devrait être hashé
10. Exploiter ce fichier pour faire afficher l’empreinte de la clé d’allegro
[Corrigé]
1.5
Création d’une paire de clés sous Linux
La création d’une paire de clés se fait avec ssh-keygen, qui a de multiples usages. Pour la création de clés,
son synopsis est le suivant.
Synopsis
ssh-keygen -b taille -t type -C commentaire -f fichier
où :
• -b taille précise la taille en bits de la clé à créer. On prendra de préférence une clé de 2048 bits (les clés
DSA sont limitées à 1024 bits)
• -t type précise le type de clé à créer où type peut être :
rsa1 pour l’utilisation de SSH1 (à éviter)
rsa pour une clé RSA en SSH2 (à préférer car plus rapide que DSA)
dsa pour une clé DSA en SSH2 (inventé quand RSA était sous licence, rarement utilisé aujourd’hui)
on utilisera donc une clé de type rsa
• -C commentaire (où commentaire est un seul mot mais on peut éventuellement protéger les espaces)
permettra d’identifier la clé de manière à se rappeler pourquoi on l’a créée (on peut créer différentes clés
pour différents usages)
• -f fichier est la référence du fichier où placer la clé privée. La clé publique associée sera placée dans le
fichier fichier.pub. Si l’on ne précise pas cette option, le fichier par défaut est créé dans le répertoire
$HOME/.ssh et porte un nom différent selon le type de clé :
identity pour RSA de SSH1
id_rsa pour RSA de SSH2
id_dsa pour DSA de SSH2
Cette option n’est utile que si l’on crée plusieurs paires de clés pour des usages différents.
En principe, les clients SSH Linux récents utilisent par défaut les bons paramètres. Mais on utilisera
tout de même dans ce qui suit les options -b, -t et -C.
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
13/31
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
Exemple 1
Voici un exemple de création de clés avec ssh-keygen :
$ ssh-keygen -b 2048 -t rsa -C "pour l'iut"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/cpb/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): la passphrase non affichée
Enter same passphrase again: la passphrase non affichée
Your identification has been saved in /home/cpb/.ssh/id_rsa.
Your public key has been saved in /home/cpb/.ssh/id_rsa.pub.
The key fingerprint is:
2b:2d:f0:79:55:27:6e:fb:8a:5b:f5:1a:7b:20:8f:25 pour l'iut
Comme on le voit, l’utilisateur est invité à entrer une passphrase (et la confirmer) qui protégera (le fichier
contenant) la clé privée. Elle peut être vide mais ce n’est pas conseillé car la clé ne serait pas protégée. La
passphrase devrait contenir au moins 16 caractères comprenant des caractères non alphabétiques. Elle ne devrait
pas être une phrase d’un livre ni d’une chanson. Et l’on doit être capable de s’en souvenir ! Il n’y a aucun
moyen de retrouver la passphrase si on l’a oubliée. Les clés qui en dépendent peuvent alors être mises à la
poubelle et il faut régénérer une paire de clés.
Exercice 2 (Génération d’une paire de clés avec ssh-keygen)
Sur un terminal du PC :
1. Générer une clé RSA (SSH2) de 2048 bits avec ssh-keygen. Penser à entrer une passphrase.
2. Consulter le contenu du répertoire ~/.ssh. Il devrait y avoir les fichiers id_rsa (clé privée) et
id_rsa.pub (clé publique)
3. Ces fichiers sont des fichiers texte. Les faire afficher.
Pas besoin de corrigé. . .
1.6
Déposer sa clé publique sur le serveur
Il s’agit de déposer uniquement sa clé publique sur le serveur pour qu’elle soit utilisée. Cette clé doit être
placée dans le fichier $HOME/.ssh/authorized_keys de l’utilisateur sur le serveur.
Ce fichier peut contenir plusieurs clés publiques, à raison d’une par ligne, car l’utilisateur peut disposer
de plusieurs clés privées (réparties éventuellement sur des ordinateurs différents).
Il y a plusieurs méthodes pour placer la clé publique dans ce fichier :
• manuelle : l’utilisateur édite lui même le fichier et y copie-colle la clé
• semi-automatique : l’utilisateur transfère le fichier contenant la clé publique et le renomme ou l’ajoute au
fichier authorized_keys
• automatique : l’utilisateur utilise la commande ssh-copy-id qui se charge de tout
Dans un premier temps, nous allons utiliser la méthode manuelle.
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
14/31
Exercice 3 (dépôt manuel de la clé publique sur allegro)
1. Sur allegro (via la connexion SSH), créer le répertoire .ssh dans votre répertoire personnel
2. Créer le fichier authorized_keys dans .ssh à l’aide d’un éditeur ou en exécutant simplement :
cat > ~/.ssh/authorized_keys
3. Sur le PC, afficher le fichier id_rsa.pub
4. Sélectionner le contenu du fichier qui a été affiché (ça le copie)
5. Coller ce contenu dans l’éditeur (si vous utilisez vi, n’oubliez pas de taper i d’abord pour passer en mode
insertion) ou directement sur le terminal si vous utilisez cat. Faire bien attention que le tout constitue bien
une seule ligne et se termine par un retour à la ligne.
6. Sauver le fichier ou taper CTRL-D si vous utilisez cat
7. Afficher le fichier pour voir si tout est correct
Pas besoin de corrigé. . .
1.7
Préparation à l’utilisation de la paire de clés
Pour le moment, on ne peut probablement pas utiliser la paire de clés. En effet, SSH est très capricieux
concernant les fichiers/répertoires des utilisateurs. En particulier, côtés client et serveur, il faut :
• que le répertoire personnel de l’utilisateur soit inaccessible en écriture aux membres du groupe et aux
autres. Il faut s’en assurer en exécutant chmod go-w ~ sur les deux machines
• que le répertoire .ssh soit complètement inaccessible pour les membres du groupe et les autres, et pleinement accessible pour l’utilisateur. Il faut s’en assurer en exécutant chmod 700 ~/.ssh sur les deux
machines
• que les fichiers du répertoire .ssh soient totalement inaccessibles pour les membres du groupe et les
autres. Il faut s’en assurer en exécutant chmod go-rw ~/.ssh/* sur les deux machines.
En réalité, pour ce dernier point il faut surtout protéger la clé privée. Les autres fichiers peuvent
être accessibles en lecture mais cela n’a pas d’intérêt (bien au contraire).
Exercice 4 (mise en conformité des droits)
Faire le nécessaire pour mettre en conformité les droits côtés client et serveur.
Pas besoin de corrigé. . .
✍
La commande ssh-copy-id est un script qui se charge de transférer la clé publique et de créer le
répertoire .ssh s’il n’existe pas côté serveur, le tout avec les bonnes permissions. En revanche, il ne
modifie pas les permissions de ce qui existe (notamment celles du répertoire personnel de l’utilisateur)
ni celles de la machine cliente. Son utilisation est quand même bien pratique.
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
15/31
1.8
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
Connexion avec la paire de clés
La version de ssh actuelle sous Linux est configurée pour tenter l’authentification par paire de clés (RSA
SSH2) avant celle par mot de passe. Dans le doute on peut préciser l’option -o PreferredAuthentications=
publickey. Une autre option intéressante est celle précisant (le fichier de) la clé privée à utiliser au cas où on en
a plusieurs. Cette option est -i fichier-cl´e.
Dans notre cas, nous ne devrions avoir besoin d’aucune de ces options.
Exercice 5 (Connexion sur allegro par paire de clés)
1. Sur le PC, sur le terminal où il n’y a pas la connexion SSH avec allegro, tenter une connexion SSH avec
allegro.
Si c’est votre mot de passe qui est demandé et non la passphrase, c’est que l’authentification
par paire de clés a échoué. Vous avez mal réalisé l’une des étapes précédentes (copie de la
clé publique et/ou mise en conformité des droits). Dans ce cas, faire ce qu’il faut pour
corriger le problème et retenter la connexion.
2. Terminer la connexion SSH sur allegro en tapant CTRL-D .
Pas besoin de corrigé. . .
1.9
Le fournisseur de passphrase ssh-agent
Si l’on est consciencieux, on a utilisé une longue passphrase qui est fastidieuse à taper. Or, si l’on se connecte
à nouveau au serveur en utilisant un autre terminal, la passphrase nous sera encore demandée pour débloquer la
clé privée.
C’est là qu’intervient l’agent ssh-agent. C’est un processus qui s’exécute en tâche de fond et à qui on communique la passphrase qui lui permet de débloquer la clé privée. Ceci fait, chaque fois que ssh a besoin de la clé
privée, c’est à ssh-agent qu’elle la demandera, sans intervention de l’utilisateur. Ainsi, on ne la tape qu’une fois
par session (entendre par là session gnome, kde ou autre).
Dans les distributions récentes, ssh-agent est lancé dès que l’utilisateur ouvre une session. Il n’a donc rien à
faire pour l’utiliser. Dans les distributions anciennes, c’est un peu plus compliqué. Il faut :
• lancer manuellement ssh-agent par une méthode particulière. En bash, il faut exécuter :
$ eval $(ssh-agent)
Cette commande exécute ssh-agent et crée les variables d’environnement SSH_AGENT_PID et
SSH_AUTH_SOCK dont ssh a besoin pour contacter l’agent
• Sur le terminal depuis lequel la commande précédente a été tapée, tout est configuré pour utiliser l’agent
• Si l’on exécute d’autres terminaux depuis ce terminal, alors ils bénéficieront aussi de ces variables et l’on
pourra utiliser l’agent
• En revanche, si on ouvre un autre terminal depuis le bureau, les variables précédentes ne seront pas
connues. Il faudra alors les créer pour utiliser l’agent. Pour cela, le plus simple est de taper ssh-agent -s
sur le terminal où l’agent a été lancé, ce qui affiche les commandes bash à exécuter dans un autre terminal
pour utiliser l’agent :
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
16/31
$ ssh-agent -s
SSH_AUTH_SOCK=/tmp/ssh-LhGscH2261/agent.2261; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2307; export SSH_AGENT_PID;
echo Agent pid 2307;
où la dernière ligne a peu d’intérêt. . .
Une autre possibilité est d’afficher ces variables sur le terminal où l’agent a été lancé, en tapant par
exemple :
$ set | grep '^SSH'
SSH_AGENT_PID=2307
SSH_AUTH_SOCK=/tmp/ssh-LhGscH2261/agent.2261
puis, sur le nouveau terminal, il faudra taper :
$ export SSH_AGENT_PID=2307
$ export SSH_AUTH_SOCK=/tmp/ssh-LhGscH2261/agent.2261
On comprend pourquoi dans les distributions récentes l’agent est exécuté avant le bureau de manière à
ce que les variables soient connues par tous les processus exécutés par l’utilisateur. . ..
L’agent étant exécuté, il reste à lui communiquer la passphrase de la clé qu’on veut utiliser. Pour cela, il faut
utiliser la commande ssh-add. Bien qu’admettant un certain nombre d’options, l’utilisation qu’on en fait est des
plus basiques.
Synopsis
ssh-add [fichier-cl´e ]
où fichier-cl´e est optionnel et est la référence du fichier contenant la clé privée qu’on souhaite utiliser. Par défaut,
le fichier utilisé est $HOME/.ssh/id_rsa (ça tombe bien, non ?). L’agent demande alors la passphrase servant
à débloquer la clé correspondante.
Comme son nom ne l’indique pas, ssh-add permet aussi de supprimer la gestion de certaines clés par
l’agent. Consulter le manuel de cette commande pour les options disponibles.
Exercice 6 (utilisation de ssh-agent)
1. Sur le PC (sur le terminal où la connexion SSH est terminée), exécuter ssh-add
2. Communiquer la passphrase à l’agent
3. Ouvrir un nouveau terminal à partir du bureau
4. Depuis ce terminal, se connecter à allegro par ssh. Aucune passphrase ne doit être demandée et la connexion
doit réussir
5. Terminer la connexion sur allegro en tapant CTRL-D ou exit
Pas besoin de corrigé. . .
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
17/31
2
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
Possibilités offertes par SSH
Les utilisations possibles de SSH sont trop nombreuses pour être toutes énumérées ici. Se reporter au manuel
de ssh pour avoir une liste plus détaillée. Pour une utilisation courante que nous étudierons ici, on peut ne retenir
que :
• l’exécution de commandes à distance
• la copie sécurisée de fichiers/répertoires par la commande scp
• un transfert de fichiers de type FTP mais sécurisé par la commande sftp
• la redirection de ports locaux ou distants par tunneling
• la redirection X11 (affichage de fenêtres graphiques)
• la définition de profils qui paramètrent le client ssh via le fichier $HOME/.ssh/config
À cela peut s’ajouter la création de tunnels de type VPN mais cela nécessite les droits d’administrateur
côté client et serveur car les tunnels créent des interfaces réseau virtuelles et modifient les tables de
routage.
2.1
Exécution de commandes à distance par ssh
La possibilité d’exécuter des commandes à distance via le réseau, comme s’il s’agissait de commandes locales a été historiquement offerte sous Unix par la commande rsh et s’apparente à l’appel de procédure à distance
(Remote Procedure Call). rsh est maintenant obsolète car n’est pas sécurisée.
ssh assure le même service que rsh mais à travers la connexion sécurisée. On complète alors le synopsis de
ssh.
Synopsis
ssh {-o options-ssh} [-i fichier-cl´e ] [-l utilisateur ] [-C] [-t] [utilisateur @]serveur [commande]
Ainsi, ce qui suit le serveur est la commande à exécuter sur le serveur, à la place d’un login-shell. La commande peut être limitée à un seul mot (comme ls) ou prendre des options ou arguments (comme ls -l rep).
Mais elle peut être aussi une succession de commandes (comme cd rep ; ls -l | less) mais dans ce cas il
faut protéger les caractères spéciaux. Le mieux est donc d’encadrer commande par des guillemets ou des quotes.
L’entrée standard et les sorties de commande sont redirigées pour être celles de ssh.
Les options -o, -i et -l sont celles vues précédemment.
L’option -C est introduite ici mais n’est pas spécifique à l’exécution d’une commande à distance : elle demande une compression de ce qui est transféré. Elle est utile s’il y a beaucoup de données qui circulent (dans un
sens ou dans l’autre).
L’option -t demande la création d’un terminal et doit être utilisée si commande nécessite une interaction avec
l’utilisateur (comme ls -l | less).
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
18/31
Exemple 2
Pour ces exemples, ssh-agent est actif et connaît la passphrase :
pc$ ssh [email protected] 'ls -l public/unix/a*.txt'
-rw-r--r-- 1 cpb prof 4840 Mar 16 16:44 public/unix/a_decouper.txt
-rw-r--r-- 1 cpb prof 446 Sep 6 2005 public/unix/acrostiche.txt
-rw-r--r-- 1 cpb prof 422 Sep 5 2002 public/unix/amphi.txt
-rw-r--r-- 1 cpb prof 1168 Sep 5 2002 public/unix/amphigouri.txt
➪
affiche les informations détaillées des fichiers commençant par a et se terminant par .txt sur le
répertoire public/unix d’allegro
pc$ ssh [email protected] 'ls -l public/unix/a*.txt' > fichiers.txt
➪
même chose que précédemment mais place le résultat dans le fichier fichiers.txt
pc$ ssh -t [email protected] 'ls -l public/unix | less'
...
➪
affiche en paginant les informations détaillées du répertoire public/unix d’allegro. Cela nécessite
l’emploi de l’option -t
pc$ cat fic | ssh [email protected] 'cat > fic.sve && echo "ok"'
ok
➪
une façon de copier le fichier fic sur allegro. . .
Exercice 7 (exécution de commandes distantes)
Sur le PC, depuis le terminal précédent (où la connexion avec allegro est terminée), utiliser l’exécution de
commandes à distance pour :
1. faire afficher le contenu du fichier cigale.txt du répertoire de l’utilisateur cpb sur allegro
2. créer un répertoire tpres sur allegro, y créer le fichier toustxt contenant la concaténation de tous les
fichiers d’extension .txt de ~cpb/public/unix, puis de faire afficher les informations détaillées sur ce
fichier
3. copier le contenu du fichier (contenant la clé publique) ~/.ssh/id_rsa.pub du PC dans le répertoire
tpres
d’allegro, puis le faire afficher, et le supprimer.
[Corrigé]
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
19/31
2.2
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
Copie de fichiers/répertoires par scp
La copie de fichiers à distance via le réseau a été historiquement offerte sous Unix par la commande rcp
(remote copy). rcp est obsolète car n’est pas sécurisée et est maintenant supplantée par scp (secure copy).
La commande scp est analogue à la commande cp et suit les mêmes principes concernant le traitement des
sources et de la destination, sauf que ces fichiers/répertoires sont situés sur des ordinateurs (éventuellement)
différents. Par cela, scp établit une connexion SSH afin de copier des fichiers ou répertoires d’un ordinateur à
l’autre. scp utilisant ssh, les options -i et -C sont aussi reconnues par scp qui les lui communique. Certaines
options sont néanmoins spécifiques à scp.
Synopsis
scp [-rp] {-o options-ssh} [-i fichier-cl´e ] [-C] [[utilisateur @]serveur:]source
{[[utilisateur @]serveur:]source} [[utilisateur @]serveur:]destination
Les : qui suivent serveur sont obligatoires !
Les options -o, -i et -C sont celles vues précédemment.
L’option -r demande une copie récursive et doit être utilisée si une source est un répertoire.
L’option -p demande que les fichiers obtenus par la copie aient les mêmes dates de modification et d’accès,
ainsi que les mêmes permissions que les fichiers d’origine.
Comme le laisse entendre le synopsis, scp peut même copier des fichiers entre deux ordinateurs différents de
l’ordinateur depuis lequel la commande est exécutée ! Malheureusement, cette possibilité n’est pas aussi simple
que ça à mettre en œuvre car il faut que l’authentification entre les hôtes distants soit automatique, ce qui nécessite :
• que la clé publique soit déjà déposée sur l’hôte destination de la copie
• que la clé privée soit utilisable par l’hôte source de la copie. Cela est rendu possible en utilisant l’option
ForwardAgent yes de ssh mais cette option ne peut pas être passée par l’option -o de scp. Il faut utiliser
un profil spécifique qui l’active (voir section 2.4, page 21)
✍
Il est possible d’utiliser les motifs de noms de fichiers pour la copie. Cependant, ces motifs sont interprétés par le bash courant. Ce n’est pas un problème si les sources sont locales mais si elles sont
distantes, il faut protéger ces motifs pour qu’ils soient interprétés par l’hôte distant (voir exemples).
Exemple 3
Pour ces exemples, ssh-agent est actif et connaît la passphrase :
pc$ scp [email protected]:public/unix/cigale.txt .
cigale.txt
100% 677
0.7KB/s
➪
00:00
copie dans le répertoire de travail le fichier public/unix/cigale.txt d’allegro
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
pc$ ls *.txt
bidule.txt cigale.txt truc.txt
pc$ scp -C *.txt cpb@allegro:tmp
bidule.txt
cigale.txt
truc.txt
➪
Enonc´e du TP 2
100%
100%
100%
20/31
6
677
6
00:00
00:00
00:00
copie les fichiers du répertoire de travail se terminant par .txt dans le répertoire tmp d’allegro. La
compression des transferts est activée.
pc$ mkdir textes
pc$ scp -Cp 'cpb@allegro:public/unix/a*.txt' textes
a_decouper.txt
100% 4840
acrostiche.txt
100% 446
amphi.txt
100% 422
amphigouri.txt
100% 1168
➪
0.0KB/s
0.7KB/s
0.0KB/s
4.7KB/s
0.4KB/s
0.4KB/s
1.1KB/s
00:00
00:00
00:00
00:00
copie (avec compression) les fichiers du répertoire public/unix de allegro commençant par a et se
terminant par .txt dans le répertoire textes. Les fichiers obtenus ont les mêmes droits et les mêmes
dates que les fichiers d’origine. Le motif a*.txt est protégé car il doit être interprété sur allegro et
non localement.
Exercice 8 (copie sécurisée par scp)
Depuis le terminal précédent, utiliser scp pour :
1. copier dans votre répertoire de travail les fichiers commençant par c du répertoire ~cpb/public/unix
d’allegro
2. copier récursivement dans votre répertoire de travail votre répertoire tpres d’allegro en le nommant
tpres.sve et en préservant les dates et les permissions des fichiers d’origine.
Vérifier son existence.
[Corrigé]
2.3
Transfert de fichiers par sftp
La commande sftp (secure file transfer program) est une alternative sécurisée à l’emploi de FTP qui ne l’est
pas. Comme scp, sftp utilise ssh pour ses transferts. Comme (la commande) ftp, sftp est par défaut interactif et
propose des commandes internes similaires.
sftp ne permet pas de transférer des répertoires (du moins simplement).
On peut utiliser sftp pour des objectifs différents, chacun ayant sa propre syntaxe.
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
21/31
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
Synopsis
sftp
sftp
sftp
sftp
[-C]
[-C]
[-C]
[-C]
{-o
{-o
{-o
{-o
options-ssh}
options-ssh}
options-ssh}
options-ssh}
[utilisateur @]serveur
[utilisateur @]serveur :r´epertoire
[utilisateur @]serveur :source [destination]
-b fic-commandes [utilisateur @]serveur
La première forme sert pour se connecter au serveur et travailler en mode interactif (à la manière de ftp).
La deuxième forme est identique à la première mais on se place directement dans r´epertoire sur le serveur.
La troisième forme est non interactive et permet simplement de copier le fichier source dans destination. C’est
donc une utilisation similaire à scp mais plus limitée.
La quatrième forme est non interactive et demande à sftp d’exécuter les commandes internes (sftp) contenues
dans le fichier fic-commandes. Elle est pratique pour automatiser des transferts. Elle nécessite une authentification
par paire de clés.
Les options -C et -o sont celles vues précédemment. On remarque l’absence d’option -i mais il existe une
option-ssh qui la remplace (voir plus loin).
✍
La liste des commandes internes sftp est trop longue pour être décrite ici, consulter le manuel en ligne
pour les connaître. Une autre possibilité est de taper la commande interne help sur le prompt de sftp.
Exercice 9 (transfert de fichiers par sftp)
1. Dans un nouveau terminal du PC, afficher les pages de manuel de sftp pour avoir la liste des commandes
internes
2. Dans un autre terminal (du PC), utiliser sftp pour établir une connexion ssh/sftp sur allegro
3. Récupérer le fichier fruit.price qui devrait se trouver dans le répertoire ~cpb/public/unix
4. Quitter la session sftp.
[Corrigé]
2.4
Profils et options de ssh
Lorsqu’elle est utilisée, directement ou indirectement par scp ou sftp, ssh prend en compte les options qui
lui sont communiquées, soit sur la ligne de commandes, soit par l’intermédiaire de fichiers de configuration. Son
traitement des options suit l’ordre suivant :
1. les options de la ligne de commande : celles indiquées par l’option -o option-ssh
2. les options du fichier de configuration utilisateur $HOME/.ssh/config
3. les options du fichier de configuration commun à tous les utilisateurs /etc/ssh/ssh_config
Une option pouvant figurer aussi bien sur la ligne de commandes que dans les fichiers de configuration, la première trouvée est celle retenue.
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
22/31
Les fichiers de configuration sont organisés en sections où chaque section débute par le mot clé Host suivi
d’un motif. Dans le synopsis des commandes précédentes (ssh, scp, sftp), si serveur correspond au motif, alors
les options de la section correspondante s’appliquent pour la connexion (sauf si elles sont redéfinies sur la ligne
de commandes).
✍
Une section permet donc de définir des profils SSH, chacun avec ses propres options.
Le motif peut prendre plusieurs formes : adresses IP ou chaînes (de type nom DNS). Il peut contenir * qui représente n’importe quelle chaîne de caractères, ou ? qui représente n’importe quel caractère (ou chiffre dans une
adresse IP). On peut donc définir un profil pour les connexions concernant n’importe quel serveur se terminant
par .univ-aix.fr en commençant une section par Host *.univ-aix.fr (aucune résolution DNS n’est faite
à ce stade, il s’agit juste de comparer serveur et le motif).
Une utilisation très courante de la définition d’une section est la possibilité de définir différents profils pour
des connexions vers un même ordinateur. Cela se fait en combinant le mot clé Host et le mot clé Hostname
comme dans l’exemple si-dessous.
Exemple 4
Si $HOME/.ssh/config contient les lignes suivantes :
Host iut1
Hostname allegro.iut.univ-aix.fr
Options spécifiques au profil iut1
Host iut2
Hostname allegro.iut.univ-aix.fr
Options spécifiques au profil iut2
Alors, en utilisant iut1 en lieu et place de serveur, on utilisera les options du profil iut1 pour se connecter
à allegro, alors que si l’on utilise iut2 on se connectera toujours à allegro mais en utilisant les options du profil
iut2.
Enfin, une section d’ordre général peut être définie en utilisant Host *. Toutes les options de cette section
s’appliquent aux connexions, sauf les options ayant déjà été définies sur la ligne de commande ou définies par
une section précédente qui correspondait.
✍
Cette section, si elle est utilisée, doit normalement être placée en fin des fichiers de configuration
$HOME/.ssh/config et/ou /etc/ssh/ssh_config.
Parmi les options possibles pouvant figurer dans les sections, certaines nous intéressent particulièrement :
• User suivi du nom d’utilisateur sur le serveur. Cela évite d’utiliser l’option -l de ssh ou les spécifications
de type utilisateur @
• IdentityFile suivi du chemin absolu du fichier contenant la clé privée à utiliser (même rôle que
l’option -i de ssh et de scp)
• Port suivi du numéro de port du serveur SSH sur la machine distante. Par défaut, cette option vaut 22
• Compression suivi de yes ou no selon que l’on veut ou non activer la compression (même rôle que
l’option -C)
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
23/31
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
• ForwardAgent suivi de yes ou no selon que l’on veut ou non que l’agent ssh local puisse débloquer
la clé privée pour un ssh exécuté à distance (via une connexion SSH). Cette option doit être activée pour
pouvoir réaliser une copie entre hôtes distants par scp.
Celles qui suivent ont généralement des valeurs par défaut adéquates mais on peut les spécifier au cas où :
• HashKnownHosts suivi de yes ou no selon que l’on veut ou non que le fichier known_hosts soit
hashé. Sur Debian, cette option est activée par défaut dans /etc/ssh/ssh_config
• PasswordAuthentication suivi de yes ou no selon que l’on souhaite ou non utiliser l’authentification par mot de passe. Cette option est active par défaut et vaut yes
• PreferredAuthentications permet d’indiquer un ordre de préférence pour l’authentification de
l’utilisateur. Nous n’avons vu ici que les authentifications password et publickey. On peut définir
l’ordre publickey,password (qui est déjà celui par défaut)
• Protocol permet d’indiquer un ordre de préférence sur la version de SSH à utiliser. Par défaut, vaut
2,1 (si SSH2 n’est pas disponible, bascule en SSH1) mais on peut totalement désactiver l’emploi du
SSH1 en indiquant seulement 2
• PubkeyAuthentication suivi de yes ou no selon que l’on souhaite ou non utiliser l’authentification par paire de clés. Le défaut est yes
• StrictHostKeyChecking suivi de yes, no ou ask. Si c’est yes, ssh refusera de se connecter à un
serveur dont la clé publique n’existe pas dans les fichiers $HOME/.ssh/known_hosts et /etc/ssh/ssh_know
Si c’est no, ssh ajoutera la clé publique d’un serveur inconnu dans le fichier $HOME/.ssh/known_hosts
sans demander l’autorisation à l’utilisateur et si la clé du serveur a changé, l’utilisateur en sera averti. Si
c’est ask, alors ssh demandera à l’utilisateur s’il doit ajouter la clé publique d’un serveur inconnu ou
pas, et refusera de se conecter à un serveur dont la clé a changé. Par défaut cette option vaut ask.
Quelle que soit la valeur de l’option précédente, la clé publique du serveur sera toujours vérifiée.
Les options sont trop nombreuses pour être décrites dans ce document, exécuter man ssh_config
pour afficher le manuel qui les décrit toutes. Nous en verrons celles qui concernent la redirection de
port et de X11 dans la suite.
L’option -o de ssh, scp et sftp
Cette option permet de spécifier une option ssh à l’aide d’un mot clé utilisé précédemment. Cependant dans
ce cas, on ne sépare pas le mot clé de sa valeur par des blancs mais par le signe =.
✍
Pas toutes les options de ssh peuvent être modifiées avec l’option -o. Par exemple, ForwardAgent
n’est pas activable par l’option -o de scp et le seul moyen de l’utiliser avec cette commande est de
créer un profil qui l’active.
✍
On pourra remarquer que c’est le seul moyen de spécifier un fichier clé privée pour la commande sftp.
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
3
Enonc´e du TP 2
24/31
SSH et la redirection de ports (tunneling)
Ainsi que nous l’avons vu par l’intermédiaire de scp et de sftp, SSH est bien plus qu’un TELNET sécurisé.
Il propose de multiples autres utilisations dont une qui est particulièrement intéressante : la création de tunnels
combinée à la redirection de port (Port forwarding).
3.1
Principe du tunneling
Supposons que depuis notre ordinateur mowgli l’on ait accès à la machine bagheera qui héberge un serveur
SSH, ainsi qu’un serveur POP3 (protocole simple permettant de gérer une boîte aux lettres électronique). On
démarre alors une session SSH distante depuis mowgli vers bagheera comme illustré par la figure 5, où le client
SSH utilise le port TCP 12345 sur mowgli.
#12345
connexion SSH
#22
mowgli
bagheera
F IGURE 5 – Connexion SSH standard
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.
Laissons de côté un instant cette connexion. Si régulièrement on utilise son client de messagerie préféré pour
rapatrier son courrier contenu sur bagheera depuis mowgli, alors on établit à chaque fois une connexion avec le
serveur POP3 de bagheera, comme illustré par la figure 6, où le client de messagerie POP3 utilise le port TCP
54321 sur mowgli, et la connexion se fait sur le port 110 (serveur POP3).
#54321
connexion POP3
#110
#12345
connexion SSH
#22
mowgli
bagheera
F IGURE 6 – Connexions SSH et POP3
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, comme illustré par la figure 7.
#55555
#110
tunnel pour connexion POP3
#12345
mowgli
connexion SSH
#22
bagheera
F IGURE 7 – Connexion POP3 à travers un tunnel SSH
Sur la figure, le tunnel SSH relie le port TCP 55555 de mowgli au port TCP 110 de bagheera. Tout se passe
comme si un serveur POP3 était actif sur mowgli, en écoute sur le port 55555.
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
25/31
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
En général, ce "serveur" n’accepte que des connexions locales (pas d’une machine autre que mowgli) 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.
Ci-dessous on voit un extrait du résultat de la commande netstat sur la machine mowgli
(139.124.187.34) qui a établi une connexion SSH avec bagheera (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
139.124.187.34:12345 :
mowgli$ netstat -tan
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale
Adresse distante
tcp
0
0 127.0.0.1:55555
0.0.0.0:*
tcp
0
0 0.0.0.0:80
0.0.0.0:*
tcp
0
0 139.124.187.34:12345
139.124.187.4:22
Etat
LISTEN
LISTEN
ESTABLISHED
Si un client local à mowgli se connecte au port 55555 de mowgli, alors la connexion est redirigée à travers
le tunnel SSH vers le port 110 de bagheera. 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
(139.124.187.34:55326) est établie avec le "serveur" 127.0.0.1:55555 sur mowgli :
mowgli$ netstat -tan
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale
Adresse distante
tcp
0
0 127.0.0.1:55555
0.0.0.0:*
tcp
0
0 0.0.0.0:80
0.0.0.0:*
tcp
0
0 139.124.187.34:12345
139.124.187.4:22
tcp
0
0 127.0.0.1:55555
127.0.0.1:55326
tcp
0
0 127.0.0.1:55326
127.0.0.1:55555
Etat
LISTEN
LISTEN
ESTABLISHED
ESTABLISHED
ESTABLISHED
Sur bagheera, le serveur SSH qui se trouve à l’autre bout du tunnel doit alors établir une connexion avec le
serveur POP3. Voici l’affichage avec netstat des connexions TCP actives sur bagheera :
bagheera$ netstat -tn
Connexions Internet actives (sans serveurs)
Proto Recv-Q Send-Q Local Address
tcp
0
0 139.124.187.4:110
tcp
0
0 139.124.187.4:46204
tcp
0
0 139.124.187.4:22
Foreign Address
139.124.187.4:46204
139.124.187.4:110
139.124.187.34:12345
State
ESTABLISHED
ESTABLISHED
ESTABLISHED
On voit bien que bagheera (139.124.187.4) a établi une connexion vers son port 110 à partir de son port
46204 (utilisé pour l’occasion par le serveur SSH), ceci pour contacter le serveur POP3. Les échanges de cette
connexion sont redirigés à travers la connexion SSH puis sur mowgli (139.124.187.34) entre le port 55555
(détenu par le client SSH) et le port 55326 (du client de messagerie).
✍
La précédente opération s’appelle la redirection de port local (local port forwarding). Il existe aussi
la redirection de port distant (remote port forwading) qui a un objectif similaire.
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
3.2
Enonc´e du TP 2
26/31
Mise en place de la redirection de port local avec ssh
Pour mettre en place la redirection de port local il faut utiliser l’option -L de ssh sur la ligne de commandes.
La syntaxe de cette option est la suivante :
-L port local:machine distante:port distant
Ainsi, dans l’exemple précédent, la mise en place de la connexion SSH et de la redirection de port se fait sur
mowgli par la ligne de commandes suivante :
mowgli$ ssh -L 55555:bagheera:110 bagheera
Redirection de port local et fichier de configuration
À la liste des options figurant dans les sections des fichiers $HOME/.ssh/config et /etc/ssh/
ssh_config, on peut ajouter l’option LocalForward demandant de réaliser la redirection de port local :
LocalForward port local:machine distante:port distant
Quelques remarques importantes :
• machine distante est interprété par le serveur SSH à l’autre bout de la connexion. Dans l’exemple, l’autre
bout de la connexion est bagheera qui devrait se connaître lui-même. . .On aurait tout aussi bien pu utiliser
localhost à la place de bagheera. On peut aussi utiliser un nom long de type bagheera.jungle.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 bagheera mais par baloo et qu’un firewall empêche
mowgli d’accéder à baloo (ou simplement à son port TCP 110). La solution consiste à établir une session
SSH entre mowgli et bagheera et d’utiliser cette session pour réaliser un port forwarding depuis (par
exemple) le port 55555 de mowgli vers le port 110 de baloo (atteint via bagheera) comme l’illustre la
figure 8.
#54321
#5678
#110
tunnel pour connexion POP3
connexion normale non cryptée
#12345
mowgli
connexion SSH
#22
bagheera
baloo
F IGURE 8 – Connexion POP3 par rebond via le tunnel SSH
Pour cela, il suffit d’indiquer en destination baloo:110 (ou le nom complet ou l’adresse IP à la place
de baloo).
la connexion entre bagheera et baloo n’est pas cryptée. Il est alors possible à quelqu’un
situé entre bagheera et baloo 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 (exécute un
login-shell).
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
27/31
3.3
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
Mise en place de la redirection de port distant avec ssh
Cette redirection est assez rarement utilisée. Elle produit l’effet inverse, à savoir rediriger les connexions
provenant d’un port du serveur sur le port d’un ordinateur (peut être celui du client). Elle est utile lorsque l’on
veut utiliser un client sur le serveur SSH mais qu’un firewall empêche la connexion de ce client, alors qu’elle est
possible à partir du client SSH.
Pour mettre en place la redirection de port distant il faut utiliser l’option -R de ssh sur la ligne de commandes.
Sa syntaxe est la suivante :
-R port serveur :machine:port
Si un client sur le serveur SSH se connecte au port port serveur alors la connexion est redirigée sur la
connexion SSH et le client SSH établit une connexion (non sécurisée) sur le port port de machine.
✍
machine est cette fois interprété par le client SSH et non par le serveur.
Redirection de port distant et fichier de configuration
À la liste des options figurant dans les sections des fichiers $HOME/.ssh/config et /etc/ssh/
ssh_config, on peut ajouter l’option RemoteForward demandant de réaliser la redirection de port distant :
RemoteForward port serveur :machine:port
4
Et SSH sur Windows ?
Des clients (et des serveurs) SSH existent sous Windows. On peut faire la même chose avec ces clients que ce
que l’on peut faire avec ssh.
Le plus célèbre d’entre eux est Putty. La suite Putty est composée de divers exécutables :
• plink : correspond à ssh
• pscp : correspond à scp
• psftp : correspond à sftp
• puttygen : correspond à ssh-keygen
• pageant : correspond à ssh-agent
• putty : un client ssh avec une interface graphique permettant de configurer des tunnels et des redirections
X11, et sauver ces configurations dans des profils.
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
28/31
F IGURE 9 – Environnement de travail dans Marionnet
5
Jouons un peu avec les services TELNET, SSH et HTTP
Exercice 10 (Démarrage d’un lab Marionnet et d’une VM XP)
Nous allons travailler sur des machines virtuelles mises en réseau dans le simulateur Marionnet, conformément
à la figure 9.
1. Télécharger le fichier m3102_tp2_lab1.mar, l’ouvrir dans Marionnet et cliquer sur Tout Démarrer.
Outre le switch S1 dont on ne s’occupera pas, les équipements de ce réseau virtuel sont :
• m1 : machine linux non encore configurée ;
• m2 : machine linux d’adresse 10.0.2.10/24 ;
• B1 : machine Windows XP non encore intégrée au réseau virtuel
• G1 : routeur d’accès vers Internet, qui possède l’adresse 10.0.2.2/24 dans Marionnet
2. Télécharger le script m3102_tp2_mkxp4mario.bash et l’exécuter pour créer et démarrer la machine
virtuelle Windows XP qui est représentée par B1 dans Marionnet
3. Une fois m1 démarrée, s’y loger en tant que root (mot de passe root) et la configurer :
(a) en affectant l’adresse IP 10.0.2.15/24 à son interface eth0
(b) en lui donannt G1 comme routeur par défaut
4. Vérifier que la configuration de m1 est correcte avec un ping de m2
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
29/31
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
5. Une fois la VM XP démarrée, se loger en tant que iutinfo (compte Administrateur sans mot de passe) et
la configurer avec l’adresse 10.0.2.100/24 et G1 comme passerelle (routeur par défaut) pour jouer le
rôle de B1. Pour cela, deux possibilités :
• soit aller dans le menu Démarrer −→ Panneau de Configuration, puis Connexions réseau et doublecliquer sur la carte Connexion au réseau local. Sur la fenêtre qui s’affiche, cliquer sur Propriétés, puis sélectionner Protocole Internet (TCP/IP) et cliquer sur Propriétés. Sélectionner Utiliser
l’adresse IP suivante et renseigner les champs correspondants
• soit en ouvrant un invite de commandes (menu Démarrer −→ Exécuter. . .) et utiliser netsh (sur une
seule ligne) :
C:\>netsh int ip set address "Connexion au réseau local"
static adresse-ip masque passerelle m´etrique
où l’on prendra 20 (valeur arbitraire. . .) comme m´etrique.
6. Vérifier que la configuration de cette VM XP est correcte avec un ping de m2 depuis l’invite de commande
[Corrigé]
Exercice 11 (Activation du service TELNET sur m2)
Dans cet exercice, on va activer le service TELNET sur m2 et permettre à root de s’y conecter. On pourra
constater à nouveau que ce service manque de sécurité. . .
1. Sur m2, se loger en tant que root (mot de passe root)
2. Pour activer le service TELNET sur m2, on va utiliser le super-serveur inetd :
(a) éditer avec vi son fichier /etc/inetd.conf, et modifier la ligne :
#<off># telnet
stream
tcp
nowait
telnetd /usr/sbin/tcpd
tcp
nowait
root /usr/sbin/tcpd
/usr/sbin/in.telnetd
pour qu’elle devienne :
telnet
stream
/usr/sbin/telnetd
(b) recharger la configuration du démon inetd en tapant :
m2# /etc/init.d/openbsd-inetd reload
Le service devrait être maintenant opérationnel.
3. Depuis m1, tenter de se loger en root sur m2 avec telnet. On devrait remarquer que le service est bien actif
(demande un login), mais que l’accès en root est pour le moment impossible
4. Sur m2, éditer le fichier /etc/securetty pour ajouter les lignes :
pts/0
pts/1
pts/2
qui autorisent root à se loger par TELNET sur les 3 terminaux virtuels correspondants
5. Depuis m1, se loger en root sur m2 avec telnet juste pour vérifier que c’est possible puis quitter la session
TELNET en tapant exit.
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
UE31 - M3102 : Services R´eseaux
Enonc´e du TP 2
30/31
6. Sur m2, exécuter la commande suivante :
# tcpdump -A -i eth0 tcp dst port 23
qui demande d’afficher en ASCII le contenu des trames parvenant à l’interface eth0 et qui contiennent un
segment TCP destiné à un serveur TELNET. Autrement dit, cette commande va permettre de visualiser les
envois du client vers le serveur TELNET.
✍
Sur le principe, la visualisation de ce traffic peut se faire avec cette commande depuis n’importe
quelle machine qui voit passer ces trames, soit parce qu’elle est sur le trajet (routeur), soit parce
que le réseau fonctionne par inondation comme l’Ethernet partagé (ce qui serait le cas si on avait
un hub à la place du switch)
7. Placer les fenêtres de m1 et m2 côte à côte. Depuis m1, se loger en root sur m2 avec telnet, tout en
observant sur m2 le dernier caractère de certains segments transmis lors de l’authentification. On devrait
pouvoir reconstituer le nom de l’utilisateur et son mot de passe, car ils sont transmis en clair !. . .
8. Arrêter la capture et sortir de la session TELNET. On a pu comprendre pourquoi l’accès root via TELNET
est désactivé par défaut. On va voir qu’on ne peut espérer plus de sécurité en se logeant avec un utilisateur
pour passer ensuite root.
9. Sur m2, créer un utilisateur toto en tapant :
m2# adduser toto
et en lui donnant un mot de passe simple, tel que truc
10. Exécuter à nouveau la même commande tcpdump sur m2
11. Depuis m1, se loger en toto sur m2 avec telnet, tout en vérifiant que la capture est opérationnelle
12. Une fois logé en toto sur m2, exécuter su pour passer root. Son mot de passe est alors demandé. Le saisir
et remarquer qu’il est toujours transmis en clair. . .
13. Terminer la session TELNET, et arrêter la capture.
[Corrigé]
Exercice 12 (Service SSH sur m2 et tunneling SSH)
Cet exercice a principalement pour but d’illustrer le principe des tunnels SSH et de la redirection de ports.
Sur m2 un serveur SSH est déjà actif.
1. Quelle modification de la commande tcpdump précédente faudrait-il faire pour capturer le traffic à destination du serveur SSH ? On fera l’économie de cette capture car on ne verrait pas grand chose d’exploitable. . .
2. Vérifier que l’accès SSH sur m2 depuis m1 est bien possible, puis terminer aussitôt la session SSH.
3. Sur la VM XP, utiliser Putty pour accéder à m2 en SSH. Une fois logé, terminer aussitôt la session SSH.
4. On va empêcher l’accès SSH à m2 depuis la VM XP. Pour cela, sur m2 éditer le fichier
/etc/hosts.deny et y ajouter la ligne :
sshd : 10.0.2.100
5. Sur la VM XP, utiliser à nouveau Putty pour tenter d’accéder à m2 en SSH. Cette fois, ce ne devrait pas
être possible.
C. Pain-Barre -
23/12/2014
IUT Aix-Marseille - INFO Aix
31/31
Enonc´e du TP 2
UE31 - M3102 : Services R´eseaux
6. Vérifier que l’accès SSH sur m2 depuis m1 reste possible, puis terminer aussitôt la session SSH.
7. Sur la VM XP, configurer Putty de la manière suivante :
• dans la partie Host Name, mettre l’adresse de m1 car on va y ouvrir une session SSH
• dans le menu SSH −→ Tunnels, saisir :
dans Source port : 20000
dans Destination : 10.0.2.10:22
puis cliquer sur Add. On vient de paramétrer une rediction de port local vers le serveur SSH de m2. . .
• Cliquer sur Open, ce qui va établir une connexion SSH sur m1, et s’y loger.
8. Tout en gardant cette connexion SSH, ouvrir à nouveau Putty sur la VM XP et le paramétrer avec :
• Host name : localhost
• Port : 20000
puis cliquer sur Open. Cette fois, on ouvre une session SSH sur m2 ! Pouvez-vous expliquer ce qui s’est
passé, alors qu’on n’avait pas accès au serveur SSH de m2 depuis la VM XP ?
9. La configuration du serveur SSH de m2 se fait en éditant le fichier /etc/ssh/sshd_config. Parcourir
son contenu. Utiliser le man de sshd_config afin de déterminer quelle directive empêche l’authentification par mot de passe (indice : il y Password dans son nom. . .).
[Corrigé]
Exercice 13 (Service HTTP sur m2 et tunneling SSH)
1. Sur m2, éditer le fichier /etc/apache2/apache2.conf et y ajouter la directive suivante :
<Location />
Order deny,allow
Deny from 10.0.2.100
</Location>
Qui empêchera l’accès au serveur Web de m2 depuis la VM XP
2. Toujours sur m2, démarrer le serveur Web en tapant :
# /etc/init.d/apache2 start
3. Sur m1, taper :
# lynx 10.0.2.10
pour s’assurer que le serveur Web de m2 est opérationnel
4. Sur la VM XP, ouvrir un navigateur et tenter d’accéder au site http://10.0.2.10. Ce ne devrait pas être
possible.
Si le site s’affiche quand même, soit vous n’avez pas modifié correctement la configuration
d’apache sur m2, soit vous avez accédé au site depuis la VM Windows avant que cela soit
empêché par la configuration d’apache, et le site est stocké dans le cache du navigateur.
Dans ce dernier cas, vider le cache du navigateur et retenter de charger la page. . .
5. Sur la VM XP, utiliser les possibilités offertes par SSH (et Putty) afin de contourner ces restrictions.
[Corrigé]
IUT Aix-Marseille - INFO Aix
23/12/2014
- C. Pain-Barre
© Copyright 2024 Paperzz
