UE31 - M3102 (Services Réseaux) : Enoncé TP 3

Transcription

C. Pain-Barre
Département Informatique, Aix
UE31 - M3102 : Services Réseaux
Enoncé du TP 3
Services SSH et TELNET
Table des matières
1
Préparation de la séance
Exercice 1 (Démarrage d’un lab Marionnet et d’une VM XP) . . . . . . . . . . . . . . . . . . . . . . .
2
Introduction à SSH
Exercice 2 (Vérification du service SSH (sshd) de m2) . . . . . . . . . . . . . . .
2.1 Utilisation du client ssh . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Authentification d’un serveur SSH . . . . . . . . . . . . . . . . . . . . . . .
2.2.A Authentification d’un serveur inconnu . . . . . . . . . . . . . . . . .
Exercice 3 (Première connexion SSH sur m2 depuis m1) . . . . . . .
2.2.B Enregistrement de la clé publique du serveur côté client . . . . . . . .
2.2.C Hashage des fichiers known_hosts . . . . . . . . . . . . . . . . . . .
Exercice 4 (fichier known_hosts de bob sur m1) . . . . . . . . . . . .
2.2.D Emplacement des clés d’un serveur SSH . . . . . . . . . . . . . . . .
Exercice 5 (Étude des clés RSA privée et publique de m2) . . . . . .
2.2.E Serveur approuvé et clé(s) de session . . . . . . . . . . . . . . . . .
2.2.F Contrôler manuellement la clé publique du serveur . . . . . . . . . .
2.2.G Supprimer manuellement la clé publique d’un serveur . . . . . . . .
2.3 Authentification de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.A Authentification utilisateur par mot de passe . . . . . . . . . . . . . .
2.3.B Authentification utilisateur par paire de clés . . . . . . . . . . . . . .
2.4 Création d’une paire de clés sous Linux . . . . . . . . . . . . . . . . . . . .
Exercice 6 (Génération d’une paire de clés pour bob sur m1 avec ssh-keygen)
2.5 Déposer sa clé publique sur le serveur . . . . . . . . . . . . . . . . . . . . .
Exercice 7 (dépôt manuel de la clé publique de bob sur m2) . . . . . . . . . .
2.6 Préparation à l’utilisation de la paire de clés . . . . . . . . . . . . . . . . . .
Exercice 8 (mise en conformité des droits) . . . . . . . . . . . . . . . . . . .
2.7 Connexion avec la paire de clés . . . . . . . . . . . . . . . . . . . . . . . . .
Exercice 9 (Connexion sur m2 par paire de clés) . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
5
5
6
6
6
7
7
8
8
8
9
9
9
9
10
11
11
12
12
12
13
13
Possibilités offertes par SSH
3.1 Exécution de commandes à distance par ssh . . . . . . .
Exercice 10 (exécution de commandes distantes par SSH)
3.2 Copie de fichiers/répertoires par scp . . . . . . . . . . .
Exercice 11 (copie sécurisée par scp) . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
15
15
16
3
IUT Aix-Marseille - INFO Aix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26/9/2016
3
3
- C. Pain-Barre
UE31 - M3102 : Services Réseaux
Enoncé du TP 3
2/33
4
SSH et la redirection de ports (tunneling)
17
4.1 Principe du tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Mise en place de la redirection de port local avec ssh . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Mise en place de la redirection de port distant avec ssh . . . . . . . . . . . . . . . . . . . . . . . 20
5
SSH et la redirection X11
20
Exercice 12 (X11 forwarding de m3 vers le PC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6
Et SSH sur Windows ?
7
Jouons un peu avec SSH (et HTTP)
22
Exercice 13 (Service SSH sur m2 et tunneling SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Exercice 14 (Service HTTP sur m2 et tunneling SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
21
Compléments
23
8
Étude des faiblesses de TELNET
23
Exercice 15 (Activation du service TELNET sur m2) . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Exercice 16 (Analyse du trafic TELNET) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9
Introduction au chiffrement
9.0.A Critique du chiffrement symétrique .
9.1 Le chiffrement asymétrique . . . . . . . . . .
9.1.A Paires de clés et trousseau . . . . . .
9.1.B Cryptage/Décryptage par paire de clés
9.1.C Signature/vérification par paire de clés
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
26
27
27
10 Attaque man-in-the-middle
28
11 Le fournisseur de passphrase ssh-agent
29
12 Transfert de fichiers par sftp
30
Exercice 17 (transfert de fichiers par sftp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
13 Profils et options de ssh
C. Pain-Barre -
26/9/2016
31
3/33
1
Enoncé du TP 3
Préparation de la séance
Exercice 1 (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 1.
1. Télécharger le fichier m3102_tpssh_lab1.mar, l’ouvrir dans Marionnet et cliquer sur Tout Démarrer.
Outre le hub H1 dont on ne s’occupera pas, les équipements de ce réseau virtuel sont :
• m1 : machine Linux d’adresse 10.0.2.15/24 ;
• G1 : routeur d’accès vers Internet, qui possède l’adresse 10.0.2.2/24 dans Marionnet
• B1 : représente une machine (virtuelle) Windows XP que l’on va créer et intégrer ci-après avec
l’adresse 10.0.2.100/24
2. Télécharger le script m3102_labssh_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 (commencer à lire la section 2 le temps
qu’elle démarre. . .)
3. Une fois la VM XP démarrée, se loger en tant que iutinfo (compte Administrateur sans mot de passe).
Pour qu’elle occupe le rôle de B1, la configurer avec l’adresse 10.0.2.100/24 et G1 comme passerelle
(routeur par défaut). Pour cela, deux possibilités :
• 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 métrique
avec adresse-ip = 10.0.2.100, masque = 255.255.255.0, passerelle = 10.0.2.2
et métrique = 20 (valeur arbitraire. . .).
• 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
4. Vérifier que la configuration de cette VM XP est correcte avec un ping de m2 depuis l’invite de commande
[Corrigé]
F IGURE 1 – Environnement de travail dans Marionnet
26/9/2016
- C. Pain-Barre
2
Enoncé du TP 3
4/33
Introduction à SSH
Le protocole SSH (pour Secure SHell) étend considérablement le service offert par TELNET, le protocole de
terminal virtuel pour le travail à distance. Il remplace aussi rsh (remote shell), qui étendait TELNET avec des
facilités pour le travail distant entre environnements Unix.
Une importante faiblesse historique de TELNET (et de rsh) est que le trafic entre le client et le serveur n’est
pas chiffré et peut être intercepté, révélant toute l’activité de l’utilisateur, ainsi que son nom d’utilisateur et son
mot de passe. Une étude de cette faiblesse de TELNET est proposée en exercices complémentaires en section 8.
Cette faiblesse est corrigée dans SSH qui établit un canal de transmission full-duplex fiable et chiffré (crypté)
entre le client et le serveur. Pour cela, SSH utilise le chiffrement asymétrique pour crypter certains échanges puis
utilise un chiffrement symétrique une fois les paramètres de la communication négociés. Des informations complémentaires sur le chiffrement figurent en section 9.
La figure 2 montre cette première différence entre TELNET et SSH, où les serveurs TELNET et SSH de
bagheera utilisent les ports TCP qui leur sont réservés : 23 pour TELNET, et 22 pour SSH.
#54321
connexion TELNET non chiffrée
#23
#12345
connexion SSH chiffrée
#22
mowgli
bagheera
F IGURE 2 – bagheera héberge un serveur TELNET (port 23) et un serveur SSH (port 22). Le port des
clients TELNET et SSH de mowgli est quelconque. La connexion TELNET n’est pas chiffrée
mais la connexion SSH l’est.
Mais SSH ajoute bien plus de fonctionnalités que TELNET ! Il offre notamment, via son sous-système
SCP/SFTP, un service de transfert de fichiers de type FTP, mais chiffré.
SSH existe en deux versions majeures 1 et 2 qui sont incompatibles. La version 2 est la plus sécurisée et il est
maintenant déconseillé d’utiliser la version 1.
i
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.
Exercice 2 (Vérification du service SSH (sshd) de m2)
1. Sur m2, se loger en root (mot de passe root) et utiliser netstat pour lister les services en écoute sur TCP,
et vérifier que le service SSH est bien activé, en écoute sur le port 22
2. Ajouter à netstat l’option -p afin de constater que le service SSH est assuré par le démon sshd (situé dans
/usr/sbin)
[Corrigé]
C. Pain-Barre -
26/9/2016
5/33
Enoncé du TP 3
2.1
Utilisation du client ssh
Nous allons étudier 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.
2.2
Authentification d’un serveur SSH
Pour é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).
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
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
transmise aux clients pour authentifier le serveur et est un élément du chiffrement de la connexion.
2.2.A
Authentification d’un serveur inconnu
Lorsque qu’un client SSH se connecte à un serveur inconnu, il ne peut vérifier la clé publique que le serveur lui
transmet. Selon la configuration du client, 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 :
$ 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)?
i
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.
M
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 (voir section 10). Une possibilité de
contrôle de cette clé est présentée à la section 2.2.F.
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
6/33
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é.
Exercice 3 (Première connexion SSH sur m2 depuis m1)
1. Se loger en bob (mot de passe eponge) sur m1. Utiliser ssh pour initier une connexion SSH sur m2 en tant
que l’utilisateur milou, mais en répondant no à la question demandant si l’on veut poursuivre la connexion
2. En répondant no précédemment, on a refusé la clé publique (du serveur) de m2 et le client ssh s’est arrêté.
Recommencer et répondre yes à la même question puis entrer tintin comme mot de passe de milou sur
m2. Le prompt de m2 devrait s’afficher sur cette connexion SSH maintenant effective.
3. Depuis ce shell en tant que milou sur m2, utiliser netstat pour afficher la liste des connexions TCP, et voir
apparaître celle de cette session SSH
4. Terminer la connexion avec exit pour revenir au shell de m1
5. Recommencer une nouvelle connexion SSH avec m2 et observer qu’il n’est plus demandé de valider la
clé du serveur. En effet, la clé publique de m2 a été sauvegardée car l’on a approuvé son identité. Ne pas
continuer la connexion (en tapant Entrée à chaque demande du mot de passe) pour revenir à m1
[Corrigé]
2.2.B
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).
i
2.2.C
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. . .
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 -
26/9/2016
7/33
Enoncé du TP 3
i
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)
Exercice 4 (fichier known_hosts de bob sur m1)
Sur m1 :
1. utiliser cat pour afficher le fichier ~/.ssh/known_hosts de bob qui ne devrait contenir qu’une seule
ligne car seul m2 a été approuvé par bob
2. exécuter la commande ssh-keygen -F 10.0.2.10 qui devrait renvoyer une information similaire
3. Exécuter ssh-keygen -l -f .ssh/known_hosts pour afficher les empreintes des clés publiques
des serveurs approuvés par bob. Seule devrait apparaître celle qu’on a validé lors de la connexion à m2
[Corrigé]
2.2.D
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_key
• ssh_host_key.pub
• ssh_host_dsa_key
• ssh_host_dsa_key.pub
• ssh_host_rsa_key
• ssh_host_rsa_key.pub
Ces 6 fichiers définissent 3 paires de clés :
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
8/33
• 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.
Exercice 5 (Étude des clés RSA privée et publique de m2)
En root sur m2 :
1. Utiliser cat pour afficher le fichier /etc/ssh/ssh_host_rsa_key qui contient la clé RSA privée du
serveur
2. De même, afficher le fichier /etc/ssh/ssh_host_rsa_key.pub contenant la clé RSA publique du
serveur
3. Exécuter ensuite ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub pour afficher l’empreinte (fingerprint) de cette clé. Noter que c’est la même clé qui est stockée dans le fichier known_hosts
de bob sur m1.
[Corrigé]
2.2.E
Serveur approuvé et clé(s) de session
Si le client SSH approuve la clé publique du serveur (car contenue dans le fichier known_hosts ou approuvée
manuellement par l’utilisateur), il l’utilise pour négocier avec le serveur les clés et les algorithmes à employer
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é). Cette clé de session sera utilisée ensuite dans les échanges
par un chiffrement symétrique. Le serveur est le seul qui peut décrypter la clé de session car il est le seul à
posséder la clé privée associée à la clé publique qui a servi au chiffrement. 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.
-
2.2.F
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 (expliquée en compléments du TP dans la section 10).
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, sur le serveur, la même commande que dans l’exercice 5 :
allegro$ 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 d’allegro
correspond bien à ce qui a été reçu en section 2.2.A et l’on peut être rassuré.
i
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. . .
C. Pain-Barre -
26/9/2016
9/33
Enoncé du TP 3
2.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.
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
2.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.
2.3.A
Authentification utilisateur par mot de passe
C’est l’authentification que nous avons utilisée à l’exercice 3. 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é.
-
2.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. . .
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
10/33
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.
2.4
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.
i
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 -
26/9/2016
11/33
Enoncé du TP 3
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): 8
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 6 (Génération d’une paire de clés pour bob sur m1 avec ssh-keygen)
Sur m1, en tant que bob :
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.
[Corrigé]
2.5
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.
i
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.
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
12/33
Exercice 7 (dépôt manuel de la clé publique de bob sur m2)
1. Sur le PC, ouvrir un éditeur de texte et copier-coller la clé publique de bob sur m1 qui devrait être affichée
sur le terminal (le contenu de son fichier ~/.ssh/id_rsa.pub)
2. En tant que bob sur m1, se connecter en SSH comme milou sur m2
3. Sur cette connexion (milou@m2), créer le répertoire .ssh (dans le répertoire personnel de milou)
4. Créer le fichier authorized_keys dans .ssh en exécutant simplement
milou@m2:~$ cat > ~/.ssh/authorized_keys
ou en utilisant vi si vous préférez
5. Sélectionner (pour la copier) la ligne placée précédemment dans l’éditeur de texte (la clé publique de bob)
6. Coller ce contenu sur le terminal de milou@m2. si vous utilisez cat. Faire bien attention que le tout constitue bien une seule ligne et se termine par un retour à la ligne.
i
Si vous utilisez vi n’oubliez pas de taper i pour passer en mode insertion avant de coller !
7. Taper CTRL-D pour terminer cat (ou sauver le fichier et quitter vi)
8. Afficher le fichier pour voir si tout est correct
[Corrigé]
2.6
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.
i
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 8 (mise en conformité des droits)
Faire le nécessaire pour mettre en conformité les droits des fichiers de milou sur m2, puis quitter la connexion
SSH milou@m2 pour préparer les fichiers de bob sur m1.
[Corrigé]
C. Pain-Barre -
26/9/2016
13/33
-
2.7
Enoncé du TP 3
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.
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-clé.
Dans notre cas, nous ne devrions avoir besoin d’aucune de ces options.
Exercice 9 (Connexion sur m2 par paire de clés)
1. En tant que bob sur m1 se connecter en SSH comme milou sur m2. La passphrase devrait vous être
demandé pour débloquer la clé privée.
M
Si le 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 milou@m2
3. En tant que bob@m1, exécuter les commandes suivantes et entrer la passphrase de la clé privée de bob
lorsque demandé :
bob@m1:~$ eval $(ssh-agent)
bob@m1:~$ ssh-add
Un message annonçant l’ajout de l’identité de bob doit s’afficher. À partir de ce terminal, la passphrase de
la clé privée de bob est mémorisée par l’agent ssh-agent et ne sera plus demandée.
i
Plus d’information sur l’agent ssh-agent est disponible en compléments dans la section 11.
4. Recommencer la connexion SSH milou@m2. Cette fois, la passphrase ne devrait pas être demandée. . .
5. Terminer une nouvelle fois cette session milou@m2
[Corrigé]
3
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 :
26/9/2016
- C. Pain-Barre
•
•
•
•
•
•
i
3.1
Enoncé du TP 3
14/33
l’exécution de commandes à distance (section 3.1)
la copie sécurisée de fichiers/répertoires par la commande scp (section 3.2)
un transfert de fichiers de type FTP mais sécurisé par la commande sftp (section 12)
la redirection de ports locaux ou distants par tunneling (section 4)
la redirection X11 (affichage de fenêtres graphiques) (section 5)
la définition de profils qui paramètrent le client ssh via le fichier $HOME/.ssh/config (section 13)
À 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.
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 chiffrée. On complète alors le synopsis de
ssh.
Synopsis
ssh {-o options-ssh} [-i fichier-clé] [-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).
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
C. Pain-Barre -
26/9/2016
15/33
Enoncé du TP 3
ê
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 10 (exécution de commandes distantes par SSH)
Depuis bob@m1 :
1. exécuter une commande à distance par SSH pour faire afficher les informations détaillées sur le fichier
authorized_keys de milou sur m2
2. ajouter une ou plusieurs commande(s) à distance (sur une seule connexion SSH) pour afficher aussi le
contenu du fichier
[Corrigé]
3.2
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-clé] [-C] [[utilisateur @]serveur:]source
{[[utilisateur @]serveur:]source} [[utilisateur @]serveur:]destination
M
Les : qui suivent serveur sont obligatoires !
Les options -o, -i et -C sont celles vues précédemment.
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
16/33
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 13, page 31)
-
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
ê
copie dans le répertoire de travail le fichier public/unix/cigale.txt d’allegro
pc$ ls *.txt
bidule.txt cigale.txt truc.txt
pc$ scp -C *.txt cpb@allegro:tmp
bidule.txt
cigale.txt
truc.txt
ê
100%
100%
100%
6
677
6
0.0KB/s
0.7KB/s
0.0KB/s
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
ê
00:00
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.
C. Pain-Barre -
26/9/2016
17/33
Enoncé du TP 3
Exercice 11 (copie sécurisée par scp)
Depuis le terminal bob@m1 utiliser scp (avec milou@m2) pour :
1. copier dans le répertoire de travail tous les fichiers d’extension .txt contenus dans le répertoire personnel
de milou sur m2. Il ne devrait y avoir que mon_fichier.txt
2. copier récursivement le répertoire docs de bob sur m1 dans le répertoire personnel de milou sur m2 en le
nommant bobdocs
[Corrigé]
-
4
SSH offre aussi un service similaire à FTP via son sous-système SFTP. Son utilisation via la commande
sftp est reportée en compléments du TP en section 12.
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).
4.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 3, où le client
SSH utilise le port TCP 12345 sur mowgli.
#12345
connexion SSH
#22
mowgli
bagheera
F IGURE 3 – 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 4, 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 4 – Connexions SSH et POP3
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
18/33
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 5.
#55555
#110
tunnel pour connexion POP3
#12345
mowgli
connexion SSH
#22
bagheera
F IGURE 5 – 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.
i
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 :
C. Pain-Barre -
26/9/2016
19/33
Enoncé du TP 3
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).
-
4.2
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.
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 présentation des options de SSH et des fichiers de configuration est déportée en compléments dans la
section 13. À 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 6.
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
#54321
20/33
#5678
#110
tunnel pour connexion POP3
connexion normale non cryptée
#12345
connexion SSH
mowgli
#22
bagheera
baloo
F IGURE 6 – 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).
M
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).
4.3
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
5
SSH et la redirection X11
L’une des importantes facilités offertes par SSH pour le monde Unix, est la possibilité d’exécuter à distance
des applications graphiques qui s’affichent sur l’hôte du client. Ce service s’appelle la redirection X11 (X11 forwarding) puisque la gestion graphique sous Unix utilise des serveurs et clients X (version 11).
C. Pain-Barre -
26/9/2016
21/33
Enoncé du TP 3
L’option ssh qui demande une redirection X11 (X11 forwarding) est l’option 2 -X. On empêche cette redirection (si elle est activée par défaut dans un fichier de configuration) par l’option -x.
En utilisant cette option, on peut exécuter des applications graphiques à distance dont toutes les informations
sont véhiculées via des tunnels de la connexion SSH, et sont donc chiffrées.
i
L’affichage d’applications graphiques à distance nécessite que le client dispose d’un serveur X, ce qui
n’est pas le cas par défaut sur Windows.
Exercice 12 (X11 forwarding de m3 vers le PC)
1. Se loger en root sur m3 et exécuter unghostify eth42 puis ifconfig pour déterminer l’adresse de
cette interface cachée de m3
2. Sur un terminal du PC, vous connecter par SSH en root sur m3 en tapant :
pc:~$ ssh root@ip-cachée-de-m3
3. Puis, sur cette session SSH sur m3, taper
m3:~$ wireshark &
ce qui devrait afficher une erreur (la fenêtre ne peut s’afficher car la redirection X11 n’est pas activée)
4. Quitter cette session SSH sur m3, et la réouvrir en ajoutant l’option -X :
pc:~$ ssh -X root@ip-cachée-de-m3
Relancer alors wireshark qui devrait s’afficher.
[Corrigé]
6
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.
2. Il existe aussi l’option -Y qui sécurise encore plus la méthode mais l’explication sort du cadre de ce TP, d’autant que selon la
distribution -Y est utilisée par défaut. Le lecteur intéressé pourra se renseigner sur le sujet. Un premier pas serait d’aller faire un tour sur
le site http://www.hsc.fr/ressources/breves/ssh-x11.html et notamment la démo flash http://www.hsc.fr/
~davy/breves/ssh.html
26/9/2016
- C. Pain-Barre
7
Enoncé du TP 3
22/33
Jouons un peu avec SSH (et HTTP)
Exercice 13 (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.
1. Sur la VM XP, utiliser Putty pour accéder à m2 en SSH en tant que milou. Une fois logé, terminer aussitôt
la session SSH.
2. 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
3. Sur la VM XP, utiliser à nouveau Putty pour tenter d’accéder à m2 en SSH. Cette fois, ce ne devrait pas
être possible.
4. Vérifier que l’accès SSH sur m2 en milou depuis m1 reste possible, puis terminer aussitôt la session SSH.
5. 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 redirection 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 en tant que bob (mot de
passe eponge)
6. 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 ! Se connecter en tant que milou (mais
la clé n’est pas disponible depuis la machine XP). Pouvez-vous expliquer ce qu’il s’est passé, alors qu’on
n’avait pas accès au serveur SSH de m2 depuis la VM XP ?
7. 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 14 (Service HTTP sur m2 et tunneling SSH)
1. Si ce n’est pas déjà fait, se loger en root sur m2 (mot de passe root) et démarrer le serveur Web apache2
en tapant :
# /etc/init.d/apache2 start
Le fichier de configuration de ce serveur est /etc/apache2/apache2.conf. Il contient les directives
suivantes :
C. Pain-Barre -
26/9/2016
23/33
Enoncé du TP 3
<Location />
Order deny,allow
Deny from 10.0.2.100
</Location>
qui empêchent l’accès au serveur Web de m2 depuis la VM XP
2. Sur m2, utiliser netstat pour s’assurer que le serveur Web est bien démarré
3. Sur m1 en tant que bob, taper :
bob@m1:~$ lynx http://10.0.2.10
pour s’assurer que le serveur Web de m2 est opérationnel (la fenêtre doit afficher «It works!»). Quitter lynx
avec q puis y pour confirmer.
i
lynx est un navigateur Web en mode texte !
4. Sur le wireshark de m3 (lancé à l’exercice 12), commencer une capture des trames sur l’interface eth0
5. 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.
6. Sur la VM XP, utiliser les possibilités de redirection de port offertes par SSH (et Putty) afin de contourner
ces restrictions et accéder au serveur Web de m2
7. Arrêter la capture de m3. Filtrer les trames pour ne retenir que celles de la connexion au serveur Web de
m2. Cliquer sur la dernière et sélectionner Follow TCP Stream. On peut remarquer en voyant ainsi s’afficher
le dialogue avec le serveur Web de m2 que la connexion entre m1 et m2 n’est pas cryptée (mais elle est
redirigée sur le tunnel SSH entre la VM XP et m1).
[Corrigé]
Compléments
8
Étude des faiblesses de TELNET
Exercice 15 (Activation du service TELNET sur m2)
Dans cet exercice, on va activer le service TELNET sur m2 et permettre à root de s’y connecter.
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
/usr/sbin/in.telnetd
pour la décommenter et modifier 2 paramètres :
telnet
i
stream
tcp
nowait
root /usr/sbin/tcpd
/usr/sbin/telnetd
Ce faisant, on corrige l’utilisateur qui démarre le service TELNET, ainsi que le nom de
l’exécutable du serveur
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
24/33
(b) recharger la configuration du démon inetd en tapant :
m2# /etc/init.d/openbsd-inetd reload
Le service devrait être maintenant opérationnel.
(c) utiliser netstat pour lister les services en écoute sur TCP, et vérifier que le service TELNET est bien
activé, en écoute sur le port 23
(d) Ajouter l’option -p à netstat pour connaître les exécutables correspondants à ces services, et remarquer que c’est inetd qui écoute sur le port 23
-
En effet, nous avons activé TELNET via inetd qui lancera le serveur (l’exécutable
/usr/sbin/telnetd indiqué dans le fichier /etc/inetd.conf) lorsqu’un client se
connectera au service. Ainsi, inetd ne lance un service que lorqu’il est sollicité, ce qui
économise les ressources.
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 :
# Terminaux virtuels
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 pour vérifier que c’est possible (le prompt de m2 doit bien
s’afficher).
6. Sur cette session TELNET sur m2 :
(a) utiliser netstat pour afficher la connexion TCP utilisée pour cette session
(b) utiliser à nouveau l’option -p de netstat pour vérifier que c’est bien telnetd qui utilise cette connexion
sur m2 (mais c’est toujours inetd qui écoute sur le port 23)
(c) utiliser passwd pour changer le mot de passe de root en damned, puis terminer la session TELNET
en tapant exit.
[Corrigé]
Exercice 16 (Analyse du trafic TELNET)
Dans cet exercice, on pourra (à nouveau) constater que TELNET est un protocole manquant de sécurité. . .
1. Sur m2, exécuter la commande suivante :
# tcpdump -A -i eth0 tcp dst port 23
qui demande d’afficher en ASCII (-A) le contenu des trames parvenant à l’interface eth0 (-i) et qui
contiennent un segment TCP destiné à un serveur TELNET (23 comme port destination du segment TCP).
Autrement dit, cette commande va permettre de visualiser les envois du client vers le serveur TELNET.
-
C. Pain-Barre -
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). Vous pouvez tester en remplaçant le switch par un hub, ajouter
une VM Linux sur ce Hub, et capturer les trames échangées par m1 et m2 depuis cette nouvelle
VM. . .
26/9/2016
25/33
Enoncé du TP 3
2. Sur m3, exécuter unghostify eth42 puis ifconfig pour déterminer l’adresse de cette interface cachée
de m3
3. Sur un terminal du PC, vous connecter par SSH en root sur m3 en tapant :
pc:~$ ssh -X root@ip-cachée-de-m3
4. Puis, sur cette session SSH sur m3, taper
m3:~$ wireshark &
puis démarrer une capture sur l’interface eth0
5. Depuis m1, se loger en root sur m2 avec telnet
6. Arrêter la capture tcpdump de m2. Observer les informations affichées par cette capture, et remarquer 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 ont été transmis en clair !. . .
Si vous ne le voyez pas, pas de panique ! Arrêter la capture du wireshark de m3, filtrer les trames pour ne
garder que celles impliquant le port TCP 23 (avec tcp.port == 23), puis sur l’une d’elles, sélectionner
Follow TCP Stream. . .
i
On comprend bien pourquoi l’accès root via TELNET est désactivé par défaut. On ne peut
espérer plus de sécurité en se logeant par TELNET avec un autre utilisateur pour passer ensuite
root car tout est transmis en clair. . .
7. Terminer la session TELNET sur m2
[Corrigé]
9
Introduction au 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 introduire et critiquer le chiffrement symétrique.
9.0.A
Critique du chiffrement symétrique
Pour le chiffrement symétrique, un fichier (ou flux de données) 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 7.
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.
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
26/33
clé partagée entre
l’émetteur et le récepteur
abc
efg
ijk
cryptage
décryptage
010
101
010
transmission
010
101
010
récepteur
émetteur
abc
efg
ijk
F IGURE 7 – Chiffrement symétrique : même clé pour le cryptage/décryptage
9.1
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.
i
9.1.A
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.
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 -
26/9/2016
27/33
Enoncé du TP 3
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.
9.1.B
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.
niquée
abc
efg
ijk
abc
efg
ijk
émetteur
clé privée que seul le
récepteur possède
cryptage (clé publique)
décryptage (clé privée)
010
101
010
transmission
010
101
010
récepteur
la
u
comm
e a été
u
q
li
b
clé pu
clé publique communiquée
aux émetteurs potentiels
de documents cryptés
etteur
à l’ém
F IGURE 8 – 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 8. 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.
9.1.C
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 9 :
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)
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
clé publique communiquée
aux récepteurs potentiels
de documents signés
la clé
publiq
28/33
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
signature (clé privée)
vérification (clé publique)
abc
efg
ijk
abc
efg
ijk
transmission
S
S
F IGURE 9 – Signature d’un document avec la clé privée de l’émetteur. Le récepteur vérifie avec la clé
publique correspondante.
10
Attaque man-in-the-middle
Si l’on approuve la clé publique du serveur sans la vérifier, on s’expose à se connecter à une machine qui
aurait usurpé l’IP du serveur (mise en place par un attaquant pour voler les mots de passe, par exemple) ou à 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 10.
client
attaquant
connexion
serveur
connexion
SSH
mowgli
SSH
sherekhan
bagheera
F IGURE 10 – 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. . .
i
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.
C. Pain-Barre -
26/9/2016
29/33
11
Enoncé du TP 3
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 :
$ 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
i
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.
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
30/33
Synopsis
ssh-add [fichier-clé]
où fichier-clé 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.
i
12
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.
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.
M
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.
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 :répertoire
[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 répertoire 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.
C. Pain-Barre -
26/9/2016
31/33
Enoncé du TP 3
Exercice 17 (transfert de fichiers par sftp)
Sur le terminal bob@m1 :
1. afficher les pages de manuel de sftp pour avoir la liste des commandes internes
2. utiliser sftp pour établir une connexion ssh/sftp sur m2 en tant que milou
3. Récupérer le fichier /etc/passwd
4. Quitter la session sftp.
[Corrigé]
13
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.
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
26/9/2016
- C. Pain-Barre
Enoncé du TP 3
32/33
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)
• 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.
C. Pain-Barre -
26/9/2016
33/33
Enoncé du TP 3
i
i
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.
26/9/2016
- C. Pain-Barre

UE31 - M3102 (Services Réseaux) : Enoncé TP 3

Transcription

Documents pareils

Configuration de la connexion au réseau Wifi de l`IUT de Bayonne

Configuration de la connexion au réseau Wifi de l`IUT de Bayonne

Etape 4: Créer la paire de clés ()

Prise en main SSH - 3Kernels

Le don d`organe en Crise : #SSH

voir la documentation ici

Partie I: Première utilisation de SSH

Connexion au serveur sesame-mips

Mini-PC : Gnu/Linux : SSH : Tunnelliser une connexion VNC par

Contrôle de la DreamBox à travers un canal SSH