Enoncé du TP 7 Réseaux

Transcription

1 Enoncé du TP 7 Réseaux Utilisation de services réseaux, NAT/PAT, Filtrage C. Pain-Barre INFO - IUT Aix-en-Provence version du 23/4/ Préparation du TP Au cours de ce TP, nous aurons besoin d un certain environnement que nous allons mettre en place : 1. Sur une fenêtre terminal du PC, taper : $ ssh -X allegro afin de vous loger sur allegro. Nous utiliserons ce terminal plus tard dans la séance ; 2. Sur une autre fenêtre terminal du PC, taper : $ wget $ bash startxp.sh puis laisser la machine virtuelle XP démarrer (il faudra cliquer Ok lorsqu elle démarrera effectivement) ; 3. Sur une dernière fenêtre terminal du PC, taper : $ wget En attendant que tout ce qu on a entrepris se termine, commencez à lire le texte de la section suivante. 4. Lorsque la machine virtuelle XP aura démarré, exécuter firefox (icône sur le Bureau) et aller sur mon site rubrique Réseaux puis : (a) cliquer sur le lien dotnetfx.exe et enregistrer le fichier ; (b) exécuter le fichier téléchargé pour installer le framework.net 1.1. Cela peut prendre du temps, pendant lequel vous pouvez continuer la lecture de la section suivante (revenir de temps en temps sur XP pour voir s il n y a pas à répondre Ok à certains messages) ; (c) cliquer sur le lien Simulateur.exe et enregistrer le fichier sur le Bureau. On se servira du simulateur dans la section 6 2 TELNET TELNET (pour TErminaL NETwork) a été défini par la RFC 854, à laquelle s ajoutent de nombreuses autres RFC définissant des options ou extensions, à commencer par la RFC 855. Ce protocole a été élaboré dans le but de fournir un service de terminal virtuel, qui permet à un utilisateur de travailler à distance sur une station (comme avec SSH). Conçu à l origine sous Unix, TELNET gomme les différences entre les systèmes d exploitation : un utilisateur d un système quelconque peut se loger sur un serveur d un système quelconque. INFO - IUT Aix-en-Provence C. Pain-Barre,

2 Enoncé du TP 7 Réseaux Version du 23/4/2012 2/66 TELNET fonctionne en mode client/serveur et utilise une connexion TCP que le client établit avec le serveur. Dans cette section, sous allons principalement nous intéresser aux clients TELNET qui servent à : se loger à distance sur une station hébergeant un serveur TELNET ; dialoguer à distance avec un serveur quelconque, dont les messages sont formés de caractères ASCII. i Sous Unix et Windows, la commande telnet exécute un client TELNET. Ce n est pas la seule. Par exemple sous Windows, Putty et HyperTerminal en sont d autres, plus élaborés que la commande telnet par défaut du système. 2.I Client telnet pour le terminal virtuel Pour une utilisation de terminal virtuel, permettant de se loger sur un hôte distant hébergeant un serveur TELNET, on exécute la commande : $ telnet hôte où hôte est l adresse IP ou le nom du serveur. Cette commande exécute un client TELNET qui établit une connexion TCP avec le serveur TELNET qui doit être en écoute sur le port TCP 23 de l hôte hôte. Le terminal d où est exécuté le client telnet sert alors aux entrées-sorties avec un programme de login exécuté sur le serveur. L utilisateur est invité à entrer son nom et un mot de passe pour pourvoir exécuter un shell. Le serveur redirige les entrées-sorties du programme de login (et du shell) sur la connexion. TELNET fonctionne en transmettant du texte. La connexion TCP est utilisée pour transmettre les commandes à exécuter sur le shell, ainsi que leur résultat. Tout se passe comme si l utilisateur était installé devant une console de cet hôte. Outre ces données, la connexion sert aussi à transmettre des informations de contrôle. Notamment, le contrôle normalise les échanges de texte qui sont effectués car le client et le serveur peuvent avoir des codages de caractères différents. Le rôle du terminal virtuel (client et serveur) est de servir d interface entre un utilisateur et (un shell sur) un hôte distant, où ce que l utilisateur tape est envoyé au serveur et où ce que le serveur répond est affiché sur le terminal de l utilisateur, jusqu à ce que la connexion soit rompue. i Il est possible d exécuter des applications graphiques à distance lorsqu on est logé avec TELNET sur un hôte. Il faut pour cela exécuter en local un serveur X (afficheur de fenêtres) et paramétrer quelques variables et autorisations d accès. Nous verrons cela avec SSH. Un certain nombre d options peuvent être négociées entre le client et le serveur. Le client telnet offre un mode commande pour son paramétrage et son contrôle, ce qui peut donner lieu à une négociation avec le serveur. Pour entrer dans ce mode, il faut taper la séquence de caractères d échappement.cette séquence est indiquée en début de session TELNET et consiste souvent à maintenir appuyée la touche Ctrl, suivie du caractère ] (crochet fermant que l on saisit à l aide de la touche AltGr ), ou parfois du $ (cas du client telnet de Windows). On entre alors dans le mode de commande du client telnet. On peut ensuite taper help pour avoir une liste de commandes disponibles, et il suffit de taper deux fois sur la touche Entrée pour revenir au terminal virtuel. C. Pain-Barre, INFO - IUT Aix-en-Provence

3 3/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux Exercice 1 (Utilisation de telnet depuis Linux) Depuis un terminal sur votre PC : 1. utiliser telnet pour vous connecter à allegro ; 2. s identifier 3. taper une commande quelconque (telle que ls -l) ; 4. rentrer dans le mode de commande du client (en tapant les 3 touches AltGr + Ctrl + ] ) ; 5. taper help 6. taper deux fois sur Entrée (pour revenir à la session) 7. taper à nouveau une commande ; 8. terminer la connexion soit en tapant Ctrl + D, soit exit, soit en entrant dans le mode de commande et en tapant close ou quit. [Corrigé] TELNET est un service non sécurisé ni crypté. En particulier le nom de l utilisateur et son mot de passe circulent "en clair" dans le réseau. Par conséquent, le service TELNET est de moins en moins autorisé par les administrateurs réseaux qui le remplacent par SSH (secure shell). Notamment, il n est plus possible de se connecter sur une machine du Département Informatique par TELNET, à partir de l extérieur de l IUT. Cependant, TELNET est encore beaucoup utilisé pour administrer à distance certains (vieux) équipements réseaux, ou des équipements légers. Exercice 2 (Utilisation de telnet depuis Windows) Agrandir la fenêtre de la machine virtuelle Windows XP, puis ouvrir un invite de commandes MS-DOS (l interpréteur de commandes Windows) par le Menu Démarrer Exécuter puis taper cmd et Entrée. Sur ce terminal MS-DOS Windows : 1. pour élargir cette fenêtre terminal, effectuer un clic droit sur la barre du haut de la fenêtre et choisir Propriétés puis l onglet Configuration et mettre 150 comme largeur dans la zone Taille Fenêtre ; 2. exécuter telnet sans se connecter à un serveur. On peut remarquer que le caractère d échappement est CTRL-$ (indiqué au début). i Parfois, le client telnet sous Windows est graphique. Il ne dispose pas du mode commandes, mis à part les menus de la fenêtre qu il ouvre. Si c est le cas pour la version installée sur votre poste, explorer ces menus. 3. taper help 4. se connecter à allegro 5. s identifier 6. taper quelques commandes (pwd, cd, ls,...) sur la session TELNET sur allegro 7. entrer dans le mode commandes de telnet INFO - IUT Aix-en-Provence C. Pain-Barre,

4 Enoncé du TP 7 Réseaux Version du 23/4/2012 4/66 8. taper set? 9. utiliser set pour demander un echo local. 10. taper Entrée pour sortir du mode commandes de telnet 11. taper à nouveau quelques commandes (pwd, cd, ls,...), et observer. Les caractères tapés sont écrits 2 fois. i Cette option est utile lorsqu on contacte un serveur autre que TELNET en utilisant le programme telnet (voir ci-après) et que les caractères tapés n apparaissent pas à l écran. 12. quitter telnet [Corrigé] 2.II Telnet comme simple client TCP Le programme client telnet peut être utilisé dans un autre but. En effet, il permet de communiquer avec des serveurs (en utilisant le protocole approprié) qui utilisent TCP comme protocole de transport. Ceci parce que telnet peut se comporter comme un client TCP ordinaire. Il suffit de lui indiquer après l hôte, le port utilisé par le serveur par la ligne de commande suivante : $ telnet hôte port où port est le numéro du port de l application à contacter, ou le nom (ou un alias) du service rendu par cette application tel qu il apparaît dans le fichier /etc/services sur Linux et C:\WINDOWS\system32\drivers\ etc\services (ou C:\WINNT\system32\drivers\etc\services) sur Windows. On en profite pour rappeler ici quelques ports TCP réservés : Num (décimal) Application 7 Serveur echo 13 Serveur daytime 20 Serveur FTP (données) 21 Serveur FTP (commandes) 22 Serveur SSH 23 Serveur TELNET 25 Serveur SMTP (transfert de mail) 53 Serveur DNS 80 Serveur HTTP (www) 119 Serveur NNTP (news) Le client telnet va alors établir une connexion TCP avec le serveur en écoute sur le port port de l hôte hôte. Tout ce que l utilisateur tapera sera transmis au serveur qui l interprétera généralement comme un requête. Tout ce que le serveur enverra sera alors affiché sur le terminal de l utilisateur et correspondra généralement à une réponse à une requête. C. Pain-Barre, INFO - IUT Aix-en-Provence

5 5/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux De nombreux protocoles utilisent les caractères ASCII pour former leurs messages. Les serveurs de ces protocoles peuvent donc être contactés avec telnet. De plus, ces serveurs utilisent ou requièrent généralement que les fins de lignes soient exprimées par la séquence des deux caractères \r (Carriage Return ou CR) et \n (Line Feed ou LF), ce que fait justement telnet. i Pour ne citer que quelques protocoles majeurs qui utilisent des caractères ASCII dans leurs échanges, il y a : HTTP, FTP, SMTP, POP3. Exercice 3 (Utilisation de telnet en client TCP) Depuis un terminal du PC : 1. Utiliser less pour consulter le fichier /etc/services, en particulier le début ; 2. Contacter le serveur daytime de infodoc en utilisant telnet. Celui-ci se contente de renvoyer la date et l heure qu il possède puis ferme la connexion ou reste muet. i Si le serveur ne ferme pas la connexion, entrer dans le mode commandes de telnet pour le faire. 3. Essayer ensuite de contacter le serveur daytime d allegro et de paprika. En revanche, il y a très peu de chances de contacter avec succès un serveur situé à l extérieur de l IUT car ce genre de services est généralement désactivé (ou filtré). 4. Contacter le serveur echo de infodoc. Celui-ci renvoie les caractères qu il reçoit jusqu à ce que la connexion soit rompue. Taper quelques lignes puis terminer la connexion (en passant par le mode commandes de telnet). [Corrigé] 3 Activités réseaux d un hôte 3.I Les services réseau et la sécurité Les applications ou processus ouvrant un port TCP ou UDP sur un système, constituent le premier point d attaque accessible via un réseau TCP/IP (LAN et WAN). Le plus souvent ce sont des erreurs de configuration qui sont à l origine des failles de sécurité dans un réseau. Il est également courant que l administrateur a tout simplement oublié de désactiver un service réseau "sensible", comme par exemple le serveur TELNET installé par défaut par certaines distributions Linux (maintenant obsolètes) ou un serveur HTTP destiné à une utilisation exclusive en Intranet mais par erreur accessible via une adresse IP publique (i.e. à partir d Internet). Et bien sûr, la plupart des virus (vers et chevaux de Troie) communiquent via Internet avec d autres serveurs SMTP, HTTP ou FTP pour pouvoir se propager, pour télécharger des modules supplémentaires ou tout simplement pour déposer les informations qu ils ont pu extraire du système "infecté" sur un serveur distant (listes d adresses , codes d accès, numéro de cartes bancaires, etc.). 3.II Lister l activité réseau avec netstat Les processus utilisant le réseau peuvent être "débusqués" par l administrateur réseau en utilisant la commande netstat, disponible sur Unix et Windows. Elle donne des renseignements très complets sur les fonctionnalités réseau de la station, notamment sur l état des connexions TCP, des ports (TCP ou UDP) utilisés par les INFO - IUT Aix-en-Provence C. Pain-Barre,

6 Enoncé du TP 7 Réseaux Version du 23/4/2012 6/66 applications, et bien d autres choses. Elle admet de nombreuses options comme on peut le constater en consultant le manuel Linux. En particulier, netstat liste l ensemble des sockets TCP, UDP ou Unix ouvertes sur l hôte local : les sockets TCP et UDP sont les adresses des applications utilisant internet. On les appelle les sockets internet et sont identifiées par le triplet : (Adresse IP, Protocole, Port) Tout programme utilisant la pile IP pour communiquer avec Internet doit demander une socket TCP ou UDP pour obtenir une adresse d application ; les sockets unix correspondent à des fichier spéciaux (de type socket) et sont utilisées localement pour des communications entre processus de l hôte. Leur utilisation étant plus performante que les sockets internet, elles sont privilégiées pour les communications locales. Un processus dialoguant avec Internet reçoit ses données via une socket internet. Dans le cas de TCP, les serveurs sont en écoute sur une socket internet afin d accepter les connexions des clients. Lorsqu un client se connecte, le système fournit au serveur une socket internet supplémentaire représentant cette connexion. Lors de la demande de sa socket internet d écoute, le serveur indique à TCP par quelle adresse IP il veut être joignable. S il n a pas de préférence, il indique , voulant dire n importe quelle adresse (any). Un processus utilisant UDP fait de même pour indiquer par quelle adresse il souhaite recevoir des datagrammes. Pour un protocole de transport donné (TCP ou UDP), l adresse d une application est généralement affichée sous le format adresse-ip:port (voir exemple ci-dessous). Exemple 1 Supposons que sur un hôte on obtienne : $ netstat -an Connexions Internet actives (serveurs et établies) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat tcp : :* LISTEN tcp : :* LISTEN... tcp : :22 ESTABLISHED tcp : :80 CLOSE_WAIT... tcp6 0 0 :::22 :::* LISTEN... udp : :* udp : :*... raw : :* 7... Sockets du domaine UNIX actives(serveurs et établies) Proto RefCnt Flags Type State I-Node Chemin unix 2 [ ACC ] STREAM LISTENING /var/run/avahi-daemon/socket... unix 2 [ ] DGRAM unix 3 [ ] STREAM CONNECTE C. Pain-Barre, INFO - IUT Aix-en-Provence

7 7/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux alors dans l ordre, on peut en déduire qu il y a : un serveur en écoute (LISTEN) sur le port TCP 7634 mais qu il ne peut être contacté que par un processus local car il n écvoute que sur l adresse ; un serveur (SSH) en écoute (LISTEN) sur le port TCP 22, en écoute sur toutes ses adresses IP ( ) ; une connexion TCP est en cours (ESTABLISHED) entre un client SSH local d adresse :40413 et le serveur SSH :22 ; le port TCP 22 étant celui des serveurs SSH ; une autre connexion TCP est en cours de terminaison (CLOSE_WAIT) entre un navigateur Web d adresse :48549 et le serveur HTTP :80 ; le serveur SSH accepte aussi IPv6 ; un client DHCP est actif et utilise l adresse :68 ; un serveur TFTP est en écoute sur l adresse :69 ; une socket internet en mode raw est active : il s agit d une socket utilisée par une exécution de la commande ping, reposant sur ICMP (mode raw) ; un serveur local est en écoute sur le fichier /var/run/avahi-daemon/socket pour accepter les connexions d autres processus locaux ; un processus utilise le comme socket unix en mode non connecté (DGRAM) ; un processus local est connecté (avec un autre) via le Exercice 4 (netstat sur linux) Sur un terminal du PC, consulter le manuel en ligne de netstat en tapant : $ man netstat pour étudier ses options -a, -r, -n, -t, -u et -p, puis répondre aux questions suivantes : 1. afficher toutes les sockets ouvertes ; 2. afficher la table de routage uniquement ; 3. afficher la table de routage uniquement mais en désactivant la résolution inverse (et voir les adresses IP et les numéros des ports plutôt que des noms d hôtes et de services) ; 4. l état des connexions TCP uniquement, sans résolution inverse ; 5. l état des sockets UDP 6. l état des sockets UDP avec des informations sur les processus qui les possèdent. En principe, cette dernière information n est disponible que pour root. [Corrigé] Exercice 5 (netstat sur windows) Consulter l aide de netstat sous Windows en tapant : C:> netstat /? pour étudier ses options -a, -r, -p et -n, puis répondre aux questions suivantes : INFO - IUT Aix-en-Provence C. Pain-Barre,

8 Enoncé du TP 7 Réseaux Version du 23/4/2012 8/66 1. afficher toutes les informations disponibles 2. afficher la table de routage uniquement 3. l état des connexions TCP uniquement, sans résolution inverse. [Corrigé] Exercice 6 (netstat sur linux) Sur le PC, lancer Marionnet (menu Applications Education Marionnet) et ouvrir le fichier adm2_linux.mar téléchargé en début de TP. Cliquer ensuite sur Tout Démarrer. L administrateur a remarqué un ralentissement anormal sur son réseau et suspecte une infection de m2 par un processus utilisant Internet. Il pense qu un serveur a été activé à son insu et est à l origine des problèmes. Aidez l administrateur à se débarrasser de ce processus gênant. Pour cela, analyser sur m2 les sockets internet ouvertes. Essayer d utiliser telnet pour discuter avec les serveurs que vous trouverez. Quand vous avez trouvé le processus coupable, tuez le! i Sur m2 vous êtes root et vous pouvez vous servir avantageusement de l option -p de netstat... [Corrigé] 4 Autres outils du bricoleur réseau 4.I nmap : scanner un réseau Un des logiciels favoris des pirates ( ) est un scanner de ports. En effet, les pirates cherchent les services qui sont susceptibles de posséder une faille de sécurité afin de pénétrer un système. Pour cela, ils ont besoin d un bon scanner dans leur trousse à outil. Le plus célèbre est certainement nmap (téléchargeable sur le site Mais le scanner ne sert pas seulement aux pirates!! Il permet aux administrateurs réseaux ( ) de vérifier les ports ouverts sur leurs systèmes et s il n y a pas de service inutile actif ni de backdoor. i nmap est aussi disponible pour Windows (voir site De plus, une interface graphique nommée zenmap est maintenant disponible. Exercice 7 (Utilisation de nmap sur Linux) La documentation de nmap (et le manuel en ligne) est très fourni car elle admet un très grand nombre d options dont certaines ne sont utilisables que par root. Nous nous limiterons à une utilisation des plus basiques, sans option simplement en tapant des commandes de la forme : nmap hôte 1. Utiliser nmap pour vérifier les services ouverts sur votre PC. Comparer avec le résultat de netstat -atn (l état d un serveur en écoute et donc actif est LISTEN ou LISTENING) ; 2. Depuis allegro, utiliser nmap pour vérifier les services ouverts sur votre PC. remarquer que les services locaux (en écoute sur ) ne sont pas détectables ; C. Pain-Barre, INFO - IUT Aix-en-Provence

9 9/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 3. Depuis le PC, utiliser nmap pour vérifier ceux ouverts sur allegro ; 4. Depuis le PC, utiliser nmap pour vérifier ceux ouverts sur infodoc ; 5. Éventuellement, utiliser nmap pour vérifier ceux ouverts sur box si vous connaissez votre adresse IP. [Corrigé] 4.II netcat : un client/serveur à tester Il existe d autre logiciels que telnet pour contacter un serveur quelconque, notamment le logiciel netcat (et son évolution socat). Sous Linux, l exécutable se nomme nc et est généralement situé dans /usr/bin. Comparé par à telnet, l avantage de nc est qu il permet non seulement d envoyer des caractères ASCII sur une connexion mais aussi des données binaires. Il peut aussi servir de client UDP (alors que telnet n utilise que TCP). Enfin, il peut aussi servir de serveur, c est à dire qu il peut être "lié" à un port (TCP ou UDP selon le choix fait) et attendre que des clients lui envoient des données. i nc existe en plusieurs versions. Celle qui est installée sur les PC est la version BSD qui a plus de fonctionnalités que celle installée sur allegro, et qui s utilise un peu différemment. i Il existe aussi un portage de netcat sur Windows, que l on peut trouver sur le site vulnwatch.org/netcat/. Exercice 8 (Utilisation de netcat sur Linux) Sur un terminal du PC, consulter le manuel en ligne de nc en tapant : $ man nc pour étudier ses options -u et -l, puis répondre aux questions suivantes : 1. Utiliser nc pour contacter le serveur TCP daytime de infodoc ; 2. Utiliser nc pour contacter le serveur UDP echo d allegro ; 3. Utiliser nc pour lancer un serveur sur un port que vous choisirez (au dessus de 10000). Sur un autre terminal, par exemple depuis allegro, utiliser telnet pour vous connecter à ce serveur ; 4. Utiliser nc pour lancer un serveur UDP sur un port que vous choisirez (au dessus de 10000). Essayer d utiliser telnet pour le contacter (ça ne marchera pas). Le contacter en laçant un client nc (depuis allegro). [Corrigé] 5 FTP File Transfer Protocol (RFC 959) est un (vieux) protocole de la couche application de TCP/IP, permettant de transférer des fichiers entre des stations. Le programme ftp sur Linux et Windows est un client FTP permettant de contacter un serveur FTP. En tapant : $ ftp hôte où hôte est l adresse IP ou le nom d une station, le client tente d ouvrir une connexion TCP sur le port 21 de l hôte indiqué : INFO - IUT Aix-en-Provence C. Pain-Barre,

10 Enoncé du TP 7 Réseaux Version du 23/4/ /66 Établissement de la connexion de contrôle client FTP connexion de contrôle serveur FTP Hôte local Hôte distant Si le serveur FTP est actif et répond favorablement, une connexion de contrôle est établie. Une "session" FTP vient alors de démarrer et le serveur attend généralement que l utilisateur s authentifie en fournissant un nom d utilisateur et un mot de passe. 5.I Authentification FTP Il y a deux possibilités d authentification : soit on dispose d un compte sur le serveur et l on veut transférer des fichiers depuis ou vers ce compte. Dans ce cas, on saisit son nom d utilisateur et son mot de passe ; soit on ne dispose d aucun compte sur le serveur mais on sait qu il met à disposition certains fichiers que l on peut télécharger ou un répertoire dans lequel on peut déposer (upload) des fichiers. Dans ce cas, il faut utiliser le nom d utilisateur "anonymous" (parfois "guest") et n importe quoi est souvent accepté comme mot de passe (parfois, il n est même pas demandé). i La règle de bonne conduite sur Internet veut cependant qu on indique son adresse comme mot de passe, en particulier si un message du serveur le précise lors de l authentification. Il n y a priori aucune raison de ne pas le faire... 5.II Commandes du client FTP Une fois le login accepté, de nombreuses commandes sont disponibles pour transférer des fichiers (mais pas des répertoires). i Pour obtenir la liste des commandes disponibles proposées par le client ftp, if faut taper : ftp> help ou simplement : ftp>? Pour obtenir une description sur une commande en particulier, taper : ftp>? commande La suite de cette section passe en revue quelques unes des commandes disponibles à partir du client FTP. C. Pain-Barre, INFO - IUT Aix-en-Provence

11 11/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 5.II.A Commandes relatives au transfert de fichiers binary et ascii : permettent de choisir une méthode de transfert selon la nature du fichier à transférer. ftp> binary ftp> ascii Avant de transférer un fichier, il faut en connaître le type : fichier texte ou fichier binaire. FTP ne fournit pas de commande permettant de connaître le type d un fichier avant de le transférer. Soit on sait quel est son type, soit on se base sur son extension ou sur son nom. Par exemple, les fichiers.h,.cxx,.txt,.uu,.ps,.java, readme devraient être des fichiers textes, alors que les fichiers.tar,.tgz,.z,.gz,.exe,.avi,.rar,.zip,.gif,.mp3,.deb,.rpm, devraient être des fichiers binaires. Pourquoi les distinguer? Parce que les fichiers textes doivent subir une modification pour adapter leur codage à celui du système qui les télécharge, alors que les fichiers binaires ne doivent pas être modifiés par le transfert. Ainsi, binary demande que le transfert qui suit soit binaire alors que ascii demande à ce qu il soit en mode texte. passive : permet de basculer du mode actif au mode passif, et inversement (voir get ci-après). ftp> passive Le client FTP sur Windows ne reconnaît pas cette commande. Ce client est donc généralement inutilisable sur un ordinateur qui se trouve derrière un firewall ou une Natbox. Voir explications ci-dessous sur les modes actif et passif. get : permet de demander le transfert d un fichier du serveur vers l hôte local. ftp> get fic-source [fic-destination] où fic-source est la référence du fichier à transférer et fic-destination est le nom qu il portera localement. Le transfert du fichier est opéré sur une connexion de données établie pour l occasion. Il y a deux possibilités pour l établissement de la connexion de données : en mode actif, le client choisit un port (ou se le fait attribuer par TCP) sur lequel il se place en écoute puis, par l intermédiaire de la connexion de contrôle, indique au serveur sur quel port il est joignable. Le serveur se connecte alors au client pour établir la connexion de données. Côté serveur, le port utilisé pour cette connexion est le port 20. Pour la connexion de données en mode actif, le client devient le serveur et le serveur devient le client. Établissement de la connexion de données (mode actif) client FTP connexion de données connexion de contrôle serveur FTP Hôte local Hôte distant INFO - IUT Aix-en-Provence C. Pain-Barre,

12 Enoncé du TP 7 Réseaux Version du 23/4/ /66 Le mode actif est problématique lorsque le client se trouve derrière un NAT/PAT. En effet, il faudrait établir une règle de redirection pour le port écouté par le client. Bien souvent, cette solution n est pas envisageable. Derrière un routeur qui filtre les connexions entrantes (firewall), le problème est similaire. i Certaines Natbox évoluées règlent toutefois le problème du transfert actif en établissant d elles mêmes la règle de redirection nécessaire, lorsqu elles détectent une initiation de ce type de transfert. en mode passif, c est le client qui se connecte au serveur pour établir la connexion de données. Le port utilisé pour cette connexion par le serveur est communiqué au client par l intermédiaire de la connexion de contrôle. Établissement de la connexion de données (mode passif) connexion de données client FTP connexion de contrôle serveur FTP Hôte local Hôte distant Chaque transfert de fichier doit se faire sur une connexion de données différente. Le mode passif est aussi problématique lorsque le serveur se trouve derrière un NAT/PAT ou un firewall. En effet, il faudrait établir une règle de redirection pour le port écouté par le serveur. i Là encore, certaines Natbox évoluées règlent toutefois le problème du transfert passif (côté serveur) en établissant d elles mêmes la règle de redirection nécessaire, lorsqu elles détectent une initiation de ce type de transfert. hash : activer/désactiver la visualisation de l activité de transfert ftp> hash a pour effet de faire afficher par le client un dièse (ou autre caractère selon le client) pour chaque bloc de fichier transféré. La taille du bloc est indiquée en réponse à hash. i les dièses ne sont pas transmis par le serveur ; c est le client qui les écrit en fonction de la quantité d information transférée. C. Pain-Barre, INFO - IUT Aix-en-Provence

13 13/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux mget : permet de demander le transfert de plusieurs fichiers du serveur vers l hôte local. ftp> mget motif {motif} où motif est un motif de nom de fichier. Pour chaque fichier qui correspond au(x) motif(s), l utilisateur est invité à confirmer le transfert, à moins qu il ait demandé un mode sans invite (voir prompt ci-après). Encore une fois, chaque transfert de fichier doit se faire sur une connexion de données différente. prompt : permet de basculer du mode avec invite au mode sans invite. ftp> prompt put : permet de demander le transfert d un fichier de l hôte local vers le serveur. ftp> put fic-source [fic-destination] où fic-source est la référence du fichier à transférer et fic-destination est le nom qu il portera sur le serveur. Il faut bien évidemment avoir les autorisations nécessaires pour déposer un fichier sur le répertoire cible. Le transfert du fichier est opéré sur une connexion de données établie pour l occasion. 5.II.B mput : permet de demander le transfert de plusieurs fichiers de l hôte local vers le serveur. ftp> mput motif {motif} où motif est un motif de nom de fichier. Pour chaque fichier qui correspond au(x) motif(s), l utilisateur est invité à confirmer le transfert, à moins qu il ait demandé un mode sans invite. Commandes de déplacement et de manipulation de fichiers cd : permet de se placer dans un répertoire sur le serveur. Cette commande s utilise comme sur Unix. ftp> cd répertoire lcd : permet de se placer dans un répertoire sur l hôte local. Cette commande s utilise comme sur Unix. ftp> lcd répertoire ls ou dir : permettent d obtenir des informations sur un fichier ou le contenu d un répertoire. ftp> ls [-l] [référence] [fichier-sortie] ftp> dir [référence] [fichier-sortie] dir est équivalent à ls -l. référence est le fichier ou le répertoire sur lequel appliquer la commande et fichier-sortie est une référence d un fichier dans lequel on veut placer le résultat de la commande. Certains sites (comme ftp.inria.fr) conseillent fortement d utiliser ls -l ou dir plutôt qu un simple ls (j avoue ne pas savoir pourquoi, alors si vous le savez, dites-le moi en m envoyant un mail). Les informations fournies par ls (dir) le sont sur une connexion de données. chmod : permet de changer les permissions d un fichier (ou répertoire) sur le serveur ftp> chmod permissions référence INFO - IUT Aix-en-Provence C. Pain-Barre,

14 Enoncé du TP 7 Réseaux Version du 23/4/ /66 rename : permet de renommer un fichier sur le serveur ftp> rename ancien nouveau demande de renommer le fichier (ou répertoire) ancien en nouveau. On ne déplace pas un fichier avec cette commande. De plus, si le fichier nouveau existe déjà, il est écrasé. Si ancien et nouveau sont des répertoires (existants), alors nouveau sera écrasé s il est vide, sinon cela produit une erreur. 5.II.C delete : permet de supprimer un fichier sur le serveur ftp> delete référence Cette commande ne s applique pas aux répertoires. mdelete : permet de supprimer plusieurs fichiers sur le serveur ftp> mdelete motif {motif} À nouveau, cette commande ne s applique pas aux répertoires. mkdir : permet de créer un répertoire sur le serveur ftp> mkdir référence rmdir : permet de supprimer un répertoire sur le serveur ftp> rmdir référence où référence est un répertoire vide.! : permet d exécuter une commande localement. ftp>! [commande] La commande est exécutée dans un shell et son résultat est affiché sur la sortie standard. Cela permet par exemple de pouvoir visualiser un fichier sans quitter la session FTP, de créer localement un répertoire, renommer un fichier, etc. La syntaxe de commande est propre au shell du système du client. Si aucune commande n est fournie, le client FTP exécute un shell et lui cède la place. Lorsque le shell est terminé (par exemple, en tapant une commande shell de type exit), le client FTP reprend la main. Commandes de gestion de la session bye ou exit ou quit : terminer la session FTP et se déconnecter du serveur. ftp> bye ftp> exit ftp> quit close : permet de terminer la session FTP en cours. ftp> close Cette commande ne fait pas quitter du client FTP. open : permet d ouvrir une session FTP ftp> open serveur C. Pain-Barre, INFO - IUT Aix-en-Provence

15 15/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux user : permet de commencer la phase d authentification ftp> user nom Peut s utiliser si l utilisateur ne s est pas encore logé (par exemple après un échec d authentification). Suite à cette commande, il faudra généralement fournir un mot de passe pour s authentifier en tant qu utilisateur nom. 5.III Limitations de FTP FTP n est pas conçu pour télécharger ou déposer une hiérarchie de répertoires (arborescence). Plus simplement, il n est pas possible de demander le transfert d un fichier répertoire (avec son contenu). Cela est très gênant. Pour contourner le problème, les arborescences doivent être archivées dans un fichier unique (et binaire) qui pourra être transféré. Sous Unix (et Linux), les archives sont créées avec l utilitaire tar (tape archiver) et portent généralement l extension.tar,.tgz (si compressée en même temps par gzip) ou.tgz,.taz (si compression par compress). Parfois, l archive est compressée après avoir été créée, et porte une extension de type.tar.gz ou.tar.z. Sous Windows, les archives sont le plus souvent créés (avec compression automatique) en utilisant les logiciels WinZip ou Winrar, et portent l extension.zip ou.rar. i Certains clients FTP (comme la plupart des clients graphiques) permettent de transférer des arborescences. Pour cela, ils parcourent eux-même récursivement l arborescence à télécharger, en faisant une requête LIST pour chaque répertoire rencontré. Si vous n avez pas encore vu l utilitaire tar en cours de systèmes (ni les utilitaires de compression/décompression), vous ne saurez pas télécharger pour le moment une arborescence sans passer par un client graphique. 5.IV Clients FTP graphiques Il existe pléthore de clients FTP graphiques plus ou moins ergonomiques, notamment en offrant une visualisation côte-à-côte du répertoire distant et du répertoire local et en permettant le drag and drop. De plus, ils permettent généralement de transférer des arborescences (ils se chargent de se déplacer dans l arborescence et d en transférer le contenu). Parmi ce genre d outils, on peut citer : WS-FTP sous Windows édité par ipswitch Filezilla sous Windows et Linux gftp sous Linux/Unix 5.V Exercices Exercice 9 (Session FTP avec ftp.rfc-editor.org depuis Linux) Depuis un terminal du PC, utiliser ftp pour se connecter en tant qu utilisateur anonyme au serveur FTP du site officiel des dépôts des RFC, d adresse ftp.rfc-editor.org (ou au serveur ftp.pasteur.fr). Aller dans le répertoire in-notes (sur le serveur pasteur.fr, ce répertoire est dans pub/computing/rfc) et récupérer le fichier rfc1939.txt en mode passif (transfert de fichier texte) avec visualisation de l activité de transfert. Lorsque le fichier a été transféré, fermer la connexion en quittant ftp en tapant quit (ou bye). [Corrigé] INFO - IUT Aix-en-Provence C. Pain-Barre,

16 Enoncé du TP 7 Réseaux Version du 23/4/ /66 Exercice 10 (Dépot d un fichier sur un serveur FTP) Toujours depuis un terminal du PC, utiliser ftp pour se connecter au serveur FTP d allegro en utilisant votre vrai nom d utilisateur. Une fois fait, créer un répertoire rfc dans tp à partir de la session FTP et y déposer le fichier rfc1939.txt. Enfin quitter le client FTP et vérifier que le fichier est bien présent sur allegro. [Corrigé] Exercice 11 (Utilisation de gftp depuis Linux (allegro)) En utilisant gftp depuis allegro, récupérer la RFC 959 depuis le serveur ftp.rfc-editor.org. Cette RFC décrit le protocole FTP. Y jeter un coup d œil puis la mettre de côté. [Corrigé] i Les administrateurs réseaux ferment de plus en plus les services non sécurisés (cryptés) comme FTP. Dans ce cas, il faut utiliser de sous-modules de ssh (secure shell) offrant des services de type FTPcrypté. Les clients de ces sous-modules sont par exemple scp (secure copy), sftp (secure FTP) ou lftp sous Linux. Sous Windows, il existe un logiciel gratuit nomme PSFTP que l on trouve sur le site consacré à PUTTY (un client SSH pour Windows) : uk/~sgtatham/putty/. 5.VI Messages du protocole FTP Le protocole FTP fonctionnant en mode client/serveur, le client envoie un message (requête) au serveur via la connexion de contrôle et le serveur lui retourne une réponse sur cette même connexion. Selon la requête, cela produit l établissement d une connexion de données et un transfert d information (fichier, contenu d un répertoire). Voici ci-dessous quelques messages que le client peut envoyer ainsi que quelques réponses possibles du serveur, le tout étant précisé dans la RFC 959 que vous avez téléchargée : Tous les messages (requête ou réponse) se terminent par les deux caractères \r (Carriage Return ou CR) et \n (Line Feed ou LF). Cependant, les serveurs acceptent généralement les requêtes qui ne se terminent que par LF. USER nom pour indiquer un nom d utilisateur. Si le serveur a besoin d un mot de passe pour cet utilisateur, il enverra une réponse commençant par 331 comme : 331 User name okay, need password. sinon, il acceptera le login par un message commençant par 230 comme : 230 nom user logged in Les réponses des serveurs commencent toutes par un code à trois chiffres suivi d une explication. L explication est libre et est destinée aux humains. En revanche le code n est pas libre car est destiné à être traité par le processus client. Les réponses commencent toujours par un chiffre compris entre 1 et 5. S il vaut 4 ou 5, c est que le serveur indique une erreur, sinon il s agit d une réponse favorable. C. Pain-Barre, INFO - IUT Aix-en-Provence

17 17/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux Parfois, la réponse du serveur tient en plusieurs lignes. Dans ce cas, toutes les lignes ont le même code suivi d un tiret -, sauf la dernière pour laquelle le code est suivi d un espace. PASS mot-de-passe pour indiquer le mot de passe pour cet utilisateur. En réponse, le serveur indique que l authentification est acceptée par un message commençant par 230 comme : 230 User nom logged in. Il indique une erreur d authentification par un message commençant par 530 comme : 530 Login incorrect. CWD répertoire pour changer de répertoire. En réponse, le serveur indique un succès par un message commençant par 250 comme : 250 CWD command successful et une erreur par un message commençant par 550 comme : 550 répertoire: No such file or directory PORT h 1,h 2,h 3,h 4,p 1,p 2 dans le mode actif, le client indique par cette commande sur quel couple adresse/port le serveur doit se connecter pour établir la connexion de données. Les valeurs h 1,h 2,h 3,h 4 indiquent l adresse IP h 1.h 2.h 3.h 4. Le port P en question est indiqué par p 1 et p 2, où P = (p 1 256) + p 2 (p 1 est la valeur de l octet de poids fort de P et p 2 celle de l octet de poids faible). Une réponse favorable du serveur commencera par 200 comme : 200 PORT command successful i L adresse ne correspond pas forcément à celle du client. Ce dernier peut demander au serveur de se connecter à une autre machine, pour peu qu il y ait un processus sur la machine ciblée, en écoute sur le port indiqué. Cependant, la plupart des serveurs refusent cette opération. PASV dans le mode passif, le client indique par cette commande qu il va demander un transfert, et qu il a besoin que le serveur lui indique un couple adresse/port pour se connecter. Une réponse positive commencera par 227 et contiendra le couple adresse/port comme : 227 Entering Passive Mode (82,3,4,5,151,37). Ici, le serveur indique qu il s est mis en attente sur le port (= ) sur la machine d adresse INFO - IUT Aix-en-Provence C. Pain-Barre,

18 Enoncé du TP 7 Réseaux Version du 23/4/ /66 TYPE type LIST pour spécifier un mode de transfert des données. Parmi les types reconnus, il y a A (ascii) et I (image binaire). Une réponse positive du serveur commencera par 200 comme : 200 Type set to type demande au serveur de transférer le contenu (avec détails) du répertoire de travail (sur le serveur). Ce transfert se fait en établissant une connexion de données. Pour cela, cette requête doit être précédée d un message PORT ou PASV. Si le serveur accepte, il enverra un message commençant par 150 comme : 150 Opening ASCII mode data connection for file list Lorsque le transfert est terminé, le serveur envoie un message commençant par 226 comme : 226 Transfer complete. RETR référence demande le transfert du fichier indiqué depuis le serveur vers le client. Ce transfert se fait dans les même conditions que pour LIST. Si le serveur accepte, il enverra un message commençant par 150 comme : 150 Opening ASCII mode data connection for référence (x bytes) Lorsque le transfert est terminé, le serveur envoie un message commençant par 226 comme : 226 Transfer complete. STOR référence QUIT pour indiquer au serveur que l on veut transférer des données, qu il faut sauver dans le fichier référence. Ce transfert se fait dans les même conditions que pour LIST. Si le serveur accepte, il enverra un message commençant par 150 comme : 150 Opening ASCII mode data connection for référence Lorsque le transfert est terminé, le serveur envoie un message commençant par 226 comme : 226 Transfer complete. pour terminer la session. La réponse du serveur commence par 221 comme : 221 Goodbye. C. Pain-Barre, INFO - IUT Aix-en-Provence

19 19/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 5.VII Exercices Exercice 12 (Transfert manuel en mode actif) Depuis un terminal du PC : 1. utiliser telnet pour ouvrir une connexion de contrôle avec le serveur FTP de allegro 2. vous authentifier avec votre vrai nom d utilisateur et votre mot de passe. Attention, il est écrit en clair!! 3. sur un autre terminal du PC, utiliser nc pour se mettre en écoute sur un port que vous choisirez 4. sur la connexion de contrôle, indiquer au serveur sur quel port votre nc est en écoute 5. sur la connexion de contrôle, demander le contenu du répertoire de travail. Celui-ci doit être récupéré par votre "serveur" nc 6. quitter la session FTP. [Corrigé] Exercice 13 (Transfert manuel en mode passif) Utiliser telnet pour ouvrir une connexion de contrôle avec le serveur FTP de ftp.rfc-editor.org (ou ftp.pasteur.fr) puis faites le nécessaire afin de récupérer la RFC 821 (fichier rfc821.txt du répertoire in-notes). La mettre de côté. i Si vous parvenez à établir la connexion de données, le contenu du fichier sera transmis sur cette connexion et écrit sur la sortie standard de nc. Pour créer effectivement le fichier, il faut rediriger la sortie standard de nc... [Corrigé] INFO - IUT Aix-en-Provence C. Pain-Barre,

20 Enoncé du TP 7 Réseaux Version du 23/4/ /66 6 Simulateur : Nat/Pat et firewall Soit l interconnexion de réseaux modélisée dans le simulateur de Pierre Loisel (CERTA) : formée par les 5 réseaux suivants (plus Internet et les FAI) : le réseau /24 constitué des stations st1 et st2 le réseau /24 constitué des stations st1, st3 et st4 le réseau /24 constitué des stations st5, st6, st7 et st8 le réseau /24 constitué des stations st9, st11 et st13 appartenant au vlan 5 Tous les vlans de l exercice sont de niveau 2, ce qui n a pas vraiment d importance pour le sujet traité. le réseau /24 constitué des stations st9, st10, st12 et st14 appartenant au vlan 6 Les stations st1, st5 et st9 ont toutes des cartes d accès distant les reliant à Internet et sont configurées pour servir de routeurs. Cependant les autres stations appartiennent à des réseaux privés et ne peuvent pas encore utiliser Internet. Exercice 14 (Simulation Nat/Pat et firewall) Depuis la machine virtuelle Windows : 1. Dans un navigateur, aller sur le site et récupérer le fichier reseau_depart.xml, puis le charger dans le simulateur de Pierre Loisel 2. En mode Transport, activer le Nat/Pat sur st1, st5 et st9. Pour cela, effectuer un clic droit sur la station, choisir Configuration IP et cocher la case Nat/Pat puis sélectionner l interface publique ppp (qui les relie à Internet) : C. Pain-Barre, INFO - IUT Aix-en-Provence

21 21/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 3. Mise en place de serveurs : (a) faire écouter par st2 son port UDP 69 (serveur TFTP). Pour cela, en mode Transport, faire un clic droit sur st2 puis choisir Tables Ports écoutés puis ajouter le port UDP 69 : (b) faire écouter par st3 son port TCP 22 (serveur SSH) (c) faire écouter par st8 son port TCP 21 (serveur FTP) (d) faire écouter par st12 son port TCP 80 (serveur HTTP) (e) faire écouter par st13 son port TCP 22 (serveur SSH) (f) faire écouter par st14 son port TCP 21 (serveur FTP) 4. Configuration des redirections de port (traductions statiques) sur st1, st5 et st9 : (a) configurer st1 pour que l accès aux serveurs de st2 et st3 soit possible depuis Internet. Pour cela, en mode Transport, faire un clic droit sur st1 puis choisir Tables Table Nat/Pat et ajouter les entrées pour les serveurs de st2 et st3. Pour chaque serveur, il faut remplir une ligne de la table : en spécifiant : le protocole de transport TCP ou UDP l adresse IP privée du serveur (ici de st2 ou st3) le port privé du serveur (celui sur lequel il est en écoute) l adresse IP publique (donc ici de st1) le port public (ici on peut prendre le même que le port du serveur) INFO - IUT Aix-en-Provence C. Pain-Barre,

22 Enoncé du TP 7 Réseaux Version du 23/4/ /66 (b) configurer st5 pour que l accès au serveur de st8 soit possible depuis Internet (c) configurer st9 pour que l accès aux serveurs de st12, st13 et st14 soit possible depuis Internet 5. Vérifier l accessibilité des serveurs depuis n importe quelle station (d un réseau différent) en émettant une requête destinée à ces serveurs et en les faisant répondre (en mode Transport, clic-droit sur une station puis envoyer une requête/répondre à une requête). Pendant la simulation, observer les traductions PAT (adresses et ports) lors de la traversée éventuelle des NATBox st1, st5 et st9. i On rappelle que l envoi de la requête doit se faire vers l IP publique et le port public du serveur ; pas vers les adresses privées Configuration d un firewall (règles de filtrage ou access lists). Les règles de filtrage sont entrées sur une station/routeur en mode Transport en effectuant un clic droit sur la station/routeur puis choisir Tables Règles de filtrage. Chaque règle dicte comment traiter un datagramme UDP ou segment TCP ou message ICMP reçu, et il faut remplir une ligne de la table : en spécifiant pour quels datagrammes elle doit être appliquée : sur quelle carte en entrée (* pour toutes) sur quelle carte en sortie (* pour toutes) pour quel protocole parmi UDP, TCP ou ICMP (* pour tous) pour quel bloc d adresses IP source, indiqué par une adresse et un préfixe (* pour toutes) pour quel port source (* pour tous) pour quel bloc d adresses IP destination, indiqué par une adresse et un préfixe (* pour toutes) pour quel port destination (* pour tous) que faire du datagramme qui correspond à ces critères : Accepter ou Bloquer. Pour un datagramme donné, la première règle qui correspond est celle appliquée. Configurer les règles de st9 pour que : (a) tout le monde puisse atteindre les serveurs de la DMZ (serveur Web sur st12 et serveur FTP sur st14) (b) seul st1 puisse atteindre le serveur SSH (de st13) (c) laisser passer en entrée tout le trafic ICMP (d) bloquer tout autre type de trafic entrant (e) laisser le trafic sortant passer 7. Vérifier que ces règles fonctionnent en tentant d envoyer des requêtes à ces serveurs et en les faisant répondre lorsqu elles arrivent. [Corrigé] C. Pain-Barre, INFO - IUT Aix-en-Provence

23 23/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 7 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. 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. 7.I 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. 7.I.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 le schéma suivant : clé partagée entre l émetteur et le récepteur abc efg ijk abc efg ijk émetteur cryptage transmission décryptage récepteur 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 INFO - IUT Aix-en-Provence C. Pain-Barre,

24 Enoncé du TP 7 Réseaux Version du 23/4/ /66 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. 7.I.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. i 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. 7.I.B.1 Paires de clés et trousseau Différents utilitaires existent pour créer un paire de clés publique et privée. L outil que je préconiserais est gpg abbréviation de GnuPG (The GNU Privacy Guard), 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. 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. Le lecteur intéressé pourra étudier le tutorial sur le chiffrement, bientôt accessible sur C. Pain-Barre, INFO - IUT Aix-en-Provence

25 25/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux mon site ( On supposera par la suite que les personnes impliquées dans les échanges ont à leur disposition un tel outil. 7.I.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 distibution des clés publiques. la clé publique a été communiquée à l émetteur clé publique communiquée aux émetteurs potentiels de documents cryptés clé privée que seul le récepteur possède abc efg ijk abc efg ijk émetteur cryptage (clé publique) décryptage (clé privée) transmission 010 récepteur FIGURE 1 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 1. 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. 7.I.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 2 : 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) INFO - IUT Aix-en-Provence C. Pain-Barre,

26 Enoncé du TP 7 Réseaux Version du 23/4/ /66 clé publique communiquée aux récepteurs potentiels de documents signés clé privée que seul l émetteur possède la clé publique a été communiquée au récepteur abc efg ijk abc efg ijk émetteur abc efg ijk S signature (clé privée) vérification (clé publique) abc efg transmission ijk S récepteur FIGURE 2 Signature d un document avec la clé privée de l émetteur. Le récepteur vérifie avec la clé publique correspondante. 7.II 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 est de type man-in-the-middle et est illustrée par le schéma suivant : client attaquant serveur mowgli connexion SSH Le principe de cette attaque est le suivant : sherekhan connexion SSH Le client (sur mowgli) veut établir une connexion SSH sur bagheera 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. 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 destinée à être transmise à tout client qui en fait la demande. C. Pain-Barre, INFO - IUT Aix-en-Provence

27 27/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 7.II.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. 7.II.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 algorihtmes 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. 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. 7.II.C 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 : $ ssh allegro.iut.univ-aix.fr The authenticity of host allegro.iut.univ-aix.fr ( ) 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)? 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. INFO - IUT Aix-en-Provence C. Pain-Barre,

28 Enoncé du TP 7 Réseaux Version du 23/4/ /66 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, (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). 7.II.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). i 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... 7.II.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, ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAntyWXC9hVDfBxhXLQ933/ bwlxequalfiv65c0fnwb6eq1ww13ye1tbcub4lfgbkoatsglrld4/2olbw0gt37xmw2w95vzeqb66nr axorqadk+svyfggje5oj3dcizw0t7lek0sz9ilxpf9la1y+g9p2lczv+pgvkiug7lr4div6nktg8oze LxWA2QV/cEBOjuIxRo5CgXWFt1eEj43ARJEr0vqRaMLbUlsBJ9p9CPhbu+ZPnPffoHtlRWSobsd2Psu BcWDXHrACF7EZwr2Og/W8O4wIUqmxIlnGvdQcx0tx54uSL5g/VeN7+8AI1nypcP1Ib+260UttwrvYqN NdRgQ== 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 : C. Pain-Barre, INFO - IUT Aix-en-Provence

29 29/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux $ 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== 7.II.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é, 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 :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é. 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... 7.II.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 7.III 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. 7.III.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é. INFO - IUT Aix-en-Provence C. Pain-Barre,

30 Enoncé du TP 7 Réseaux Version du 23/4/ /66 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 qui intercepte les frappes au clavier... 7.III.B 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é. 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 : 7.IV 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. 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. 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, INFO - IUT Aix-en-Provence

31 31/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 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, comme dans notre cas pour le PC et allegro. 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 15 (connexion SSH sur allegro) 1. Ouvrir un terminal sur le PC 2. Taper ls -a pour voir si le répertoire.ssh existe. Ce ne devrait pas être le cas 3. Utiliser ssh pour se connecter à allegro 4. Répondre yes pour l authentification de la clé publique d allegro 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. 7. Dans un autre terminal (du PC), vérifier qu un répertoire.ssh a bien été 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é [Corrigé] 7.V Création d une paire de clés sous Linux La création d une paire de clés se fait en utilisant ssh-keygen. Cette commande a différentes utilités. 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) INFO - IUT Aix-en-Provence C. Pain-Barre,

32 Enoncé du TP 7 Réseaux Version du 23/4/ /66 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. Exemple 2 Voici un exemple de création de clés avec ssh-keygen : $ ssh-keygen -b 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 16 (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. [Corrigé] C. Pain-Barre, INFO - IUT Aix-en-Provence

33 33/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 7.VI 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. Exercice 17 (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 [Corrigé] 7.VII 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 inacessible 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). INFO - IUT Aix-en-Provence C. Pain-Barre,

34 Enoncé du TP 7 Réseaux Version du 23/4/ /66 Exercice 18 (mise en conformité des droits) Faire le nécessaire pour mettre en conformité les droits côtés client et serveur. [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. 7.VIII 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é. Dans notre cas, nous ne devrions avoir besoin d aucune de ces options. Exercice 19 (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 l authentification par paire de clés échoue, c est que 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. [Corrigé] 7.IX 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. Ceci fait, chaque fois que ssh a besoin de débloquer la clé privée, c est ssh-agent qui lui fournit la passphrase. 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 : C. Pain-Barre, INFO - IUT Aix-en-Provence

35 35/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 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, sur un terminal où ces variables sont connues, il faut les faire afficher, par exemple par : $ 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. Synopsis ssh-add [fichier-clé] où fichier-clé 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 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 20 (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 [Corrigé] INFO - IUT Aix-en-Provence C. Pain-Barre,

36 Enoncé du TP 7 Réseaux Version du 23/4/ /66 8 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 i À 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. 8.I 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é] [-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). C. Pain-Barre, INFO - IUT Aix-en-Provence

37 37/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux Exemple 3 Pour ces exemples, ssh-agent est actif et connaît la passphrase : $ ssh cpb@allegro.iut.univ-aix.fr 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 public/unix/acrostiche.txt -rw-r--r-- 1 cpb prof 422 Sep public/unix/amphi.txt -rw-r--r-- 1 cpb prof 1168 Sep 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 $ ssh cpb@allegro.iut.univ-aix.fr 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 $ ssh -t cpb@allegro.iut.univ-aix.fr 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 $ cat fic ssh cpb@allegro.iut.univ-aix.fr cat > fic.sve && echo "ok" ok une façon de copier le fichier fic sur allegro... Exercice 21 (exécution de commandes distantes) Il s agit ici d utiliser l exécution de commandes à distance. Vous devez faire comme si le répertoire net-home n existait pas sur le PC... 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 votre fichier cigale.txt (de votre répertoire tpunix) d allegro 2. se déplacer dans tpunix sur allegro et créer le fichier toustxt contenant la concaténation de tous les fichiers d extension.txt de ce répertoire, puis de faire afficher les informations détaillées sur ce fichier 3. copier le fichier (contenant la clé publique) ~/.ssh/id_rsa.pub du PC dans un répertoire tpres d allegro (éventuellement créé pour l occasion), puis le faire afficher, et le supprimer. [Corrigé] INFO - IUT Aix-en-Provence C. Pain-Barre,

38 Enoncé du TP 7 Réseaux Version du 23/4/ /66 8.II 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é] [-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 8.IV, page 40) 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 4 Pour ces exemples, ssh-agent est actif et connaît la passphrase : $ scp cpb@allegro.iut.univ-aix.fr:public/unix/cigale.txt. cigale.txt 100% KB/s 00:00 copie dans le répertoire de travail le fichier public/unix/cigale.txt d allegro C. Pain-Barre, INFO - IUT Aix-en-Provence

39 39/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux $ ls *.txt bidule.txt cigale.txt truc.txt $ scp -C *.txt cpb@allegro:tmp bidule.txt 100% 6 0.0KB/s 00:00 cigale.txt 100% KB/s 00:00 truc.txt 100% 6 0.0KB/s 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. $ mkdir textes $ scp -Cp cpb@allegro:public/unix/a*.txt textes a_decouper.txt 100% KB/s 00:00 acrostiche.txt 100% KB/s 00:00 amphi.txt 100% KB/s 00:00 amphigouri.txt 100% KB/s 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 22 (copie sécurisée par scp) Il s agit ici d utiliser la copie sécurisée à distance. Vous devez faire comme si le répertoire net-home n existait pas sur le PC... Depuis le terminal précédent, utiliser scp pour : 1. copier dans votre répertoire de travail les fichiers commençant par c de votre répertoire tpunix d allegro 2. copier récursivement dans votre répertoire de travail votre répertoire tpunix d allegro en le nommant letpunix et en préservant les dates et les permissions des fichiers d origine. Vérifier son existence. [Corrigé] 8.III 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. On peut utiliser sftp pour des objectifs différents, chacun ayant sa propre syntaxe. INFO - IUT Aix-en-Provence C. Pain-Barre,

40 Enoncé du TP 7 Réseaux Version du 23/4/ /66 Synopsis sftp [-C] {-o options-ssh} [utilisateur@]serveur sftp [-C] {-o options-ssh} [utilisateur@]serveur:répertoire sftp [-C] {-o options-ssh} [utilisateur@]serveur:source [destination] sftp [-C] {-o options-ssh} -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é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. Exercice 23 (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 votre réperoite tp/tpunix, sinon il est dans mon répertoire public/unix 4. Quitter la session sftp. [Corrigé] i La commande gftp vue précédemment est aussi un client sftp (graphique). 8.IV 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 C. Pain-Barre, INFO - IUT Aix-en-Provence

41 41/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 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 5 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 INFO - IUT Aix-en-Provence C. Pain-Barre,

42 Enoncé du TP 7 Réseaux Version du 23/4/ /66 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. i Quelle que soit la valeur de l option précédente, la clé publique du serveur sera toujours vérifiée. i 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. C. Pain-Barre, INFO - IUT Aix-en-Provence

43 43/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 9 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). 9.I 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. On démarre alors une session SSH distante depuis mowgli vers bagheera : mowgli #12345 connexion SSH #22 bagheera où, le client SSH utilise le port TCP sur mowgli. 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 : #54321 connexion POP3 #110 mowgli #12345 connexion SSH #22 bagheera où le client de messagerie utilise le port TCP sur mowgli. 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 : #55555 tunnel pour connexion POP3 #110 mowgli #12345 connexion SSH #22 bagheera Sur la figure, le tunnel relie le port TCP 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 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 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. INFO - IUT Aix-en-Provence C. Pain-Barre,

44 Enoncé du TP 7 Réseaux Version du 23/4/ /66 Ci-dessous on voit un extrait du résultat de la commande netstat sur la machine mowgli ( ) qui a établi une connexion SSH avec bagheera ( ) et un tunnel à partir du port 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 :55555 et le client SSH :12345 : mowgli$ netstat -tan Connexions Internet actives (serveurs et établies) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat tcp : :* LISTEN tcp : :* LISTEN tcp : :22 ESTABLISHED Si un client local à mowgli se connecte au port de mowgli, alors la connexion est redirigée à travers le tunnel 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 ( :55326) est établie avec le "serveur" :55555 sur mowgli : mowgli$ netstat -tan Connexions Internet actives (serveurs et établies) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat tcp : :* LISTEN tcp : :* LISTEN tcp : :22 ESTABLISHED tcp : :55326 ESTABLISHED tcp : :55555 ESTABLISHED Sur bagheera, le serveur SSH qui se trouve à l autre bout du tunnel doit alors établir une connexion avec le serveur POP3. Voici le résultat de netstat sur bagheera : bagheera$ netstat -tn Connexions Internet actives (sans serveurs) Proto Recv-Q Send-Q Local Address Foreign Address State tcp : :46204 ESTABLISHED tcp : :110 ESTABLISHED tcp : :12345 ESTABLISHED On voit bien que bagheera ( ) a établi une connexion vers son port 110 à partir de son port (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 ( ) entre le port (détenu par le client SSH) et le port (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. 9.II 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 : C. Pain-Barre, INFO - IUT Aix-en-Provence

45 45/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 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 : Quelques remarques importantes : LocalForward port local:machine distante:port distant 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 de mowgli vers le port 110 de baloo (atteint via bagheera) : mowgli #54321 #5678 #110 tunnel pour connexion POP3 connexion normale non cryptée #12345 connexion SSH #22 bagheera baloo 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. 9.III 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). Cas pratique : accès aux pages Web sur allegro de certains enseignants Certains enseignants du Département Informatique ne font pas héberger leurs pages Web sur infodoc qui est le seul serveur Web du Département accessible depuis Internet. À la place, le serveur qu ils utilisent est allegro. Or, le port TCP 80 d allegro n est pas accessible depuis l extérieur de l IUT. Il en résulte que vous ne pouvez accéder à ces pages depuis chez vous. La seule solution est d utiliser une redirection de port local en vous connectant par ssh sur allegro. INFO - IUT Aix-en-Provence C. Pain-Barre,

46 Enoncé du TP 7 Réseaux Version du 23/4/ /66 Par exemple, si vous exécutez depuis chez vous l une des deux commandes suivantes (équivalentes) : $ ssh -L 50000:localhost:80 nnnppp@allegro.iut.univ-aix.fr $ ssh -L 50000:allegro:80 nnnppp@allegro.iut.univ-aix.fr alors, sur votre navigateur, vous pouvez accéder à la page Web du prof trucmuche hébergée sur allegro en utilisant l URL : Le / qui suit trucmuche est obligatoire selon les navigateurs. Mettez-le systématiquement. 9.IV 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 10 Le système X-Window (X11) Le système X-Window est utilisé sur les systèmes de type Unix pour l affichage de fénêtres graphiques. Il est depuis sa création un système client/serveur. Il repose sur le protocole X qui a été développé au milieu des années Ce protocole permet d établir des relations entre des clients X (gnome-terminal, firefox/iceweasel, eclipse, aterm, xterm, xclock, xbiff, xemacs, xeyes, etc.) et des serveurs X qui ont la charge de gérer l affichage des fenêtres, la gestion des claviers et des souris, etc. Ce principe de fonctionnement est illustré par le schéma suivant : C. Pain-Barre, INFO - IUT Aix-en-Provence

47 47/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux écran affichage connexion X Client X périphériques d entrée événements Serveur X connexion X connexion X Client X Client X rattachés à un même ordinateur éventuellement sur des ordinateurs différents 10.I Fonctionnement du système à l IUT Chaque PC des salles de TP dispose de son propre serveur X : Xming ou X-Win32 sous Windows et Xorg (et son exécutable X) sous Linux (Debian). Ce qui nous intéresse ici est l utilisation client/serveur lorsque ceux-ci sont exécutés sur des ordinateurs différents. C est exactement ce qui se passe lorsque vous vous logez sur allegro en mode graphique depuis Windows, ce qui nécessite l emploi de Xming (ou X-Win32) sur Windows. En effet, si allegro dispose bien de son (ou ses) serveur(s) X (actuellement en version 11), nous ne l utilisons jamais, car il ne gère que l écran, le clavier et la souris d allegro qui sont dans une pièce accessible qu aux administrateurs système du Département. Xming est un serveur X fonctionnant sur Windows. Son rôle est de dessiner des fenêtres (les clients) qui ont été exécutées sur un ordinateur distant (généralement allegro pour nous), de gérer les événements claviers et souris qui se produisent sur la fenêtre Xming, de rendre compte aux clients des événements qui se sont produits sur leur fenêtre (clic de souris, touche tapée, etc.) et de redessiner les fenêtres lorsque les clients le lui demandent (suite à l insertion de caractères, au tracé d un graphique, etc.). Lorsque Xming ou X-Win32 est exécuté, il y a deux possibilités pour choisir l ordinateur sur lequel se connecter : soit il est configuré pour fonctionner en mode Query XDCMP sur allegro, auquel cas une demande de connexion est adressée directement à allegro qui lance alors un client X qui gère l invite de connexion. En réalité, il s agit d un serveur xdm 2 (X Display Manager) qui se comporte comme un client. À ce stade, notre serveur sur Windows doit afficher la fenêtre du client et lui renverra les informations tapées. Si le client est satisfait de ce qui est tapé, une véritable session est lancée contenant un gestionnaire de fenêtres (actuellement GNUStep, lancé par la commande wmaker (pour Window Maker)), et les différentes fenêtres que vous avez souhaité lancer au démarrage. Sur GNUStep, la description de ces fenêtres est sauvée dans le fichier ~/GNUstep/Defaults/WMState. Comme dit précédemment, chaque fenêtre est un client X. Le gestionnaire de fenêtre est lui-même un client X dont le rôle est de proposer un certain bureau ainsi qu un "Look and Feel" (une apparence des fenêtres incluant leur décoration : bordure, ascenceur, etc.) ; soit il est configuré pour fonctionner en mode broadcast XDCMP. Dans ce cas, il diffuse une requête (donc en broadcast) demandant s il existe des machines qui ont un serveur XDM (ou un équivalent comme gdm, kdm, etc.) prêt à accepter une tentative de login. Une liste de machines est alors dressée. Lorsqu on en choisit une, tout se passe comme le mode Query XDCMP. 2. Il existe plusieurs serveurs qui jouent ce rôle : sur Debian, ce Display Manager est par défaut celui de gnome et s appelle gdm. INFO - IUT Aix-en-Provence C. Pain-Barre,

48 Enoncé du TP 7 Réseaux Version du 23/4/ /66 i Xming est installé sur les PC de l IUT pour fonctionner en mode Query XDCMP et ne permet pas le mode broadcast XDCMP. En revanche, X-Win32 peut fonctionner dans les deux modes. 10.II La notion de DISPLAY Puisque sur allegro, il y plusieurs clients X qui tournent en même temps, comment savent-ils quel serveur contacter pour être affichés? C est la variable d environnement DISPLAY qui le leur dit. Lorsque vous vous êtes logés en utilisant X-Win32, alors celui-ci a créé la variable d environnement DISPLAY qui précise le serveur à contacter pour afficher les fenêtres, ainsi que le terminal dont il s agit. La variable DISPLAY contient une chaîne de la forme : machine:numéro display.numéro écran où : machine est le nom ou l adresse de la machine hébergeant le serveur. Elle peut être vide si le serveur est local. numéro display est le numéro (commençant à 0) désignant le terminal géré par le serveur X. En général, il n y en a qu une par machine, donc c est 0. numéro écran est le numéro (commençant à 0) de l écran de ce terminal, car il peut y en avoir plusieurs. En général, il n y en a qu une par machine, donc c est 0. Une alternative à la variable DISPLAY est l utilisation de l option : que de nombreux clients X reconnaissent. -display machine:numéro display.numéro écran Exemple 6 Sur la machine b98 (adresse ), après s être logé par Xming, la variable DISPLAY devrait contenir : b98.iut.univ-aix.fr:0.0 En laçant la commande aterm, celle-ci sait que le serveur à contacter est sur b98 et que c est celui gérant le display 0.0. Sans la variable DISPLAY, on aurait le même résultat en tapant : aterm -display b98.iut.univ-aix.fr: III Autorisations d affichage Supposons qu un utilisateur toto ait ouvert une session sur allegro depuis le poste b98 et utilise donc le display b98.iut.univ-aix.fr:0.0. Un autre utilisateur titi en session lui aussi sur allegro depuis le poste b97 peut-il afficher une fenêtre sur le poste b98 simplement en modifiant sa variable DISPLAY ou en utilisant l option -display? Bien sûr que non, car il y aurait un grave problème de sécurité. C. Pain-Barre, INFO - IUT Aix-en-Provence

49 49/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux i À partir du moment où un utilisateur titi a accès au display d un autre utilisateur toto, il peut utiliser des applications (comme xev) lui permettant d espionner ce que fait ou tape toto! Il pourrait aussi exécuter des commandes à la place de toto!! C est pourquoi les displays sont en principe protégés. Exemple 7 Supposons que titi soit sur le poste b97 en session sur allegro et qu il souhaite afficher une fenêtre sur le display de toto (poste b98). Alors, l affichage ne sera pas autorisé comme le montre l exemple suivant : titi@allegro$ DISPLAY=b98.iut.univ-aix.fr:0.0 titi@allegro$ aterm& [1] Xlib: connection to "b98.iut.univ-aix.fr:0.0" refused by server Xlib: No protocol specified aterm: can t open display b98.iut.univ-aix.fr:0.0 [1]+ Exit 1 aterm 10.III.A Changement de contexte d étude Jusque là nous avons parlé de l interaction entre Xming (serveur X sur Windows) et les client X d allegro (Linux). Or, le fait que les utilisateurs se connectent tous sur allegro par ce biais nuierait à la clarté de ce qui va être exposé. Pour ce qui suit, nous changeons de contexte : l utilisateur toto sur le poste b99 a démarré sous Linux (Debian) et a ouvert une session X (par exemple avec le bureau gnome). L utilisateur titi sur le poste b100 a fait de même. Nous allons étudier les possibilités de faire afficher une fenêtre graphique depuis b100 sur le poste b III.B Méthode antique "à la TELNET" en utilisant xhost Cette méthode n est absolument pas à recommander! En premier lieu, il faut savoir que le serveur X gèrant le display d.0 d un ordinateur est en écoute de connexions éventuelles de clients graphiques. Sous Unix, le serveur utilise deux protocoles de transport : un protocole spécifique Unix via les socket unix qui sont des fichiers spéciaux servant à la communication entre processus : dans ce cas le client et le serveur doivent être exécutés sur la même machine (ou partager un répertoire commun qui contient le fichier socket). Ce mode de communication est privilégié quand le client et le serveur sont exécutés sur la même machine car c est le plus rapide. Pour le display d.0, le fichier socket utilisé est /tmp/.x11-unix/xd. Par exemple pour le display 0.0 on a : $ ls -l /tmp/.x11-unix/x0 srwxrwxrwx 1 root root :43 /tmp/.x11-unix/x0 Si la variable DISPLAY n existe pas ou vaut simplement :0.0, le client se connectera au serveur en utilisant ce fichier. INFO - IUT Aix-en-Provence C. Pain-Barre,

50 Enoncé du TP 7 Réseaux Version du 23/4/ /66 TCP : dans ce cas le serveur sera en écoute sur le port d. Ce mode de communication est utilisé lorsque le client et le serveur sont exécutés sur des machines différents. Par exemple, si côté client (b100) la variable DISPLAY vaut b99.iut.univ-aix.fr:0.0 alors le client se connectera au port TCP 6000 de l adresse Ainsi, notre client sur b100 n a pas d autre choix (pour le moment) que de demander une connexion TCP au serveur tournant sur b99. Pour cela, il faut prendre des mesures sur b100 et b99 : sur b100 : titi doit configurer le client pour lui dire où se trouve le serveur : soit en créant la variable d environnement DISPLAY et lui donnant la valeur b99.iut.univ-aix.fr:0.0 en exécutant la commande : titi@b100$ export DISPLAY=b99.iut.univ-aix.fr:0.0 soit en utilisant l option -display b99.iut.univ-aix.fr:0.0 du client sur b99 : toto qui possède le display doit demander au serveur d autoriser les demandes de connexions provenant de b100 en exécutant la commande : toto@b99$ xhost +b100.iut.univ-aix.fr Si toto est inconscient, il peut même demander à son serveur X d autoriser les demandes de connexion provenant de n importe quelle machine en tapant : toto@b99$ xhost + Notons que la commande xhost admet les formes xhost -[adresse] pour retirer une adresse de la liste des ordinateurs autorisés à se connecter au serveur (ou enlever l autorisation globale si aucune adresse n est précisée). Si tout se passe bien, la connexion est établie et le client est accepté par le serveur (sa fenêtre est affichée, si c est un client qui nécessite une fenêtre) : #6000 (serveur) port client connexion X (TCP) b99 b100 Cette méthode n est pas recommandée car elle pose des problèmes de sécurité majeurs : l autorisation par xhost se fait pour un ou plusieurs ordinateurs mais pas pour un utilisateur en particulier. Ainsi, n importe quel utilisateur ayant accès à b100 a aussi accès au display de toto ; la connexion X entre b99 et b100 n est pas chiffrée : tout ce qui passe par cette connexion peut être écouté par une tierce personne (cela comprend les caractères saisis et affichés, les déplacements de souris, etc.). i On comprend alors que sur la plupart des Unix, et notamment sur Debian, l écoute du serveur par TCP est désactivée. Il n est donc maintenant généralement pas possible de contacter un serveur X par TCP. Cette désactivation est faite de façon globale par l option -nolisten tcp passée au serveur X dans le fichier /etx/x11/xinit/xserverrc et/ou dans le fichier de configuration du display manager utilisé (xdm, gdm, etc.) qui se charge d exécuter le serveur X. Cette méthode est néanmoins possible lorsqu on utilise Xming sur Windows et allegro... C. Pain-Barre, INFO - IUT Aix-en-Provence

51 51/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux 10.III.C Méthode utilisant xauth et un secret partagé Bien que plus fine que la précédente, cette méthode n est pas non plus à recommander! Elle nécessite toujours que le serveur soit en écoute par TCP. La différence avec la précédente est que l autorisation ne se fait plus pour un ou plusieurs ordinateurs mais repose sur l utilisation d un secret partagé, appelé magic-cookie. Lorsque toto a démarré sa session graphique et son serveur X, ce dernier a créé un fichier.xauthority dans le répertoire d accueil de toto. Le fichier.xauthority est inaccessible aux membres du groupe et aux autres et contient une clé pour la session (ou serveur) X. C est un fichier binaire qui n est exploitable que par la commande xauth. La commande xauth list permet de voir le contenu de ce fichier : toto@b99$ xauth list B99X/unix:0 MIT-MAGIC-COOKIE-1 2be3d8d46e74438e518d267de4b289a8 localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 2be3d8d46e74438e518d267de4b289a8 On obtient un secret par ligne. Ici, il y a en deux. Chaque secret a la forme suivante : display protocole clé Le protocole utilisé est généralement MIT-MAGIC-COOKIE-1. Pour ce protocole, la clé est codée sur 128 bits, ce qui correspond à 32 digits hexadécimaux. Dans notre cas, les deux lignes désignent les mêmes displays : B99X/unix:0 et localhost.localdomain/unix:0. i La configuration des PC du département sur Debian est telle que les noms des ordinateurs finissent par X. Ainsi, b99 se nomme B99X sous Debian mais ces noms sont équivalents. Par la suite, on gardera les noms "windows" (b99) mais dans les exemples pourront apparaître les noms "Linux" (B99X). Si titi sur b100 veut accéder au display de toto sur b99, il lui suffit d ajouter l un de ces secrets dans sa propre liste (contenue aussi dans son fichier ~/.Xauthority) en précisant qu il est dédié au display 0 de b99 en exécutant la commande suivante (sur une seule ligne) : titi@b100$ xauth add b99.iut.univ-aix.fr:0 MIT-MAGIC-COOKIE-1 2be3d8d46e74438e518d267de4b289a8 puis de créer la variable d environnement DISPLAY appropriée : titi@b100$ export DISPLAY=b99.iut.univ-aix.fr:0.0 S il exécute un client X, celui-ci contactera le serveur X de b99 sur le port 6000 (il s agit du display 0) et lui communiquera le magic-cookie. Ce faisant, le serveur autorisera la connexion. Cette méthode n est pas recommandée car elle pose aussi des problèmes de sécurité. En effet, la connexion X entre b99 et b100 n est pas chiffrée : tout ce qui passe par cette connexion peut être écouté par une tierce personne. En particulier, le magic-cookie circule en clair sur cette connexion. INFO - IUT Aix-en-Provence C. Pain-Barre,

52 Enoncé du TP 7 Réseaux Version du 23/4/ /66 i Ainsi qu il est dit précédemment, cette méthode nécessite que le serveur X soit en écoute par TCP. Or, sur les Debian des PC (et de façon générale), cette écoute est désactivée. Ainsi, il n est pas possible pour titi d afficher sur b99 des fenêtres provenant de b100. Mais il peut afficher des fenêtres sur le display de toto s il est logé lui aussi sur b99. Dans ce cas, le magic-cookie à utiliser et la variable DISPLAY sont légèrement différents que ceux indiqués précédemment : titi@b99$ xauth add B99X/unix:0 MIT-MAGIC-COOKIE-1 2be3d8d46e74438e518d267de4b289a8 titi@b99$ export DISPLAY=:0.0 Cependant, actuellement les Debian des PC sont configurées pour interdire à un utilisateur d ouvrir un shell à distance... i Lorsqu un utilisateur bidule exécute Xming pour se connecter à allegro, le serveur X sur Windows est en écoute TCP et le magic-cookie est automatiquement placé dans le fichier ~/.Xauthority de bidule sur allegro. On peut le voir en exécutant xauth list sur allegro. Par exemple, si Xming a été lancé depuis la machine b98, alors on obtient : bidule@allegro$ xauth list b98.iut.univ-aix.fr:0 MIT-MAGIC-COOKIE-1 97ff01f512b1a1bcce95fed7f2cbff5f Il suffit à un autre utilisateur d ajouter ce magic-cookie dans sa liste pour accéder au display de bidule sur b98, puisque Xming accepte les connexions TCP III.D Méthode par redirection X11 de ssh i C est "la" méthode à utiliser. ssh a été pensé pour permettre à un utilisateur de se connecter à un ordinateur distant et d exécuter des clients X qui sont affichés sur l ordinateur local (sur lequel doit tourner un serveur X). Pour cela, ssh exploite sa capacité de tunneling et se charge de faire passer les communications entre le client X et le serveur X à travers un tunnel. Cette méthode a plusieurs avantages : les échanges entre le client et le serveur X sont cryptés et ne peuvent être écoutés car ils passent par la connexion SSH aucune connexion TCP distante, à part la connexion SSH, n est requise. Ainsi, pour les configurations actuelles qui interdisent l écoute par TCP des serveurs X, cette méthode rend possible la communication entre les clients et les serveurs distants l authentification du client X auprès du serveur X repose sur la transmission du magic-cookie par l intermédiaire d un magic-cookie secondaire aucune manipulation particulière de l utilisateur n est requise à part passer la bonne option à ssh. En particulier, ssh se charge d ajouter le magic-cookie (secondaire) sur la session de l utilisateur sur le serveur SSH. L option ssh qui demande une redirection X11 (X11 forwarding) est l option 3 -X. On empêche cette redirec- 3. Il existe aussi l option -Y qui sécurise encore plus la méthode mais c est un peu trop compliqué à expliquer pour le moment, 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 et notamment la démo flash C. Pain-Barre, INFO - IUT Aix-en-Provence

53 53/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux tion (si elle est activée par défaut dans un fichier de configuration) par l option -x. Ainsi, si toto sur b99 a l identité (ou le mot de passe de) titi sur allegro et exécute : toto@b99$ ssh -X titi@allegro alors : ssh transmet au serveur SSH un (pseudo) magic-cookie généré pour l occasion qu il associe au magiccookie du display utilisé par toto (sur b99), et le serveur place ce (pseudo) magic-cookie dans le fichier.xauthority de titi sur allegro Le serveur SSH (ici, sur allegro) : crée un pseudo-serveur X contactable uniquement localement (par localhost ou ) et en attente sur le premier port TCP disponible à partir de 6010 (prenons 6010). En réalité, c est le serveur SSH qui est en écoute sur ce port crée la variable DISPLAY valant localhost:10.0 pour la session de titi. Si le port pris par le serveur avait été 6011, alors la variable vaudrait localhost:11.0 fait passer par la connexion SSH ce que les clients X se connectant à son serveur transmettent et, inversement, ce qui provient de la connexion SSH en direction d un client X Le client ssh fait lui aussi passer ces communications au serveur X par l intermédiaire de la socket unix de ce dernier mais remplace le (pseudo) magic-cookie par le vrai magic-cookie C est un peu complexe mais parfaitement transparent pour l utilisateur. D ailleurs nous avons déjà eu l occasion d utiliser cette possibilité lors d un TP de système et vous n y avez vu que du feu (non?). Sur allegro, on peut voir la configuration X de titi en exécutant les commandes : titi@allegro$ echo $DISPLAY localhost:10.0 titi@allegro$ xauth list allegro/unix:10 MIT-MAGIC-COOKIE-1 649f421af92486bef73ce9bbe02cafb0 On a une sorte de mélange : la variable DISPLAY dit bien que le serveur est contactable par TCP (à cause de localhost) le (pseudo) magic-cookie dit qu à l autre bout de la connexion, le serveur utilise une socket unix Pour toto sur b99 le magic-cookie est différent : toto@b99$ xauth list B99X/unix:0 MIT-MAGIC-COOKIE-1 2be3d8d46e74438e518d267fe4b289a8 localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 2be3d8d46e74438e518d267fe4b289a8 Maintenant, si un utilisateur bidule sur allegro connaît le (pseudo) magic-cookie de titi, il peut accéder au display de toto sur b99 en exécutant : bidule@allegro$ xauth add allegro/unix:10 MIT-MAGIC-COOKIE-1 649f421af92486bef73ce9bbe02cafb0 bidule@allegro$ export DISPLAY=localhost:10.0 Exercice 24 (X11 forwarding sur allegro) 1. Depuis un terminal du PC, se connecter par ssh sur allegro sans demander la redirection X11 2. Sur allegro, essayer d exécuter : aterm& Après un petit moment, on obtient un message d erreur informant de l impossibilité de la chose INFO - IUT Aix-en-Provence C. Pain-Barre,

54 Enoncé du TP 7 Réseaux Version du 23/4/ /66 3. Quitter la connexion SSH 4. Faire afficher la liste des magic-cookies sur la Debian 5. Se connecter par ssh sur allegro en demandant la redirection X11 6. Sur allegro : (a) faire afficher le contenu de la variable DISPLAY (b) faire afficher la liste des magic-cookies : au moins 1 devrait correspondre à la variable précédente. Le comparer avec celui du PC, il devrait être différent (c) exécuter : aterm >& /dev/null& cette fois, il s affiche sur le PC i À ce stade, vous pouvez si vous le souhaitez vous mettre en relation avec un autre étudiant et faire ce qu il faut pour qu il affiche une fenêtre (par exemple eog ~cpb/public/firefox_wallpaper.png) sur votre PC et vous une autre (eog ~cpb/public/firefox_ie.jpg) sur le sien. 7. Quitter la connexion SSH. [Corrigé] 11 Xnest : un serveur X qui est aussi un client X L exécution d un serveur X sur un Unix est réservée à root. Or, il arrive qu on veuille disposer d un second serveur X pour y faire afficher par exemple le bureau d une autre machine, comme si l on se trouvait physiquement devant le moniteur de cette machine. Une solution est d utiliser la commande Xnest. Elle crée un serveur X qui est affiché par le serveur X gérant le display : c est donc aussi un client X. En paramètre de Xnest il faut lui indiquer le numéro de display qu il va gérer (ainsi qu une option pour gérer correctement le clavier). Par exemple, soit l utilisateur cpb en session graphique sur b99 qui utilise le display 0. En exécutant : cpb@b99$ Xnest -kb -nolisten tcp :1& alors, cpb lance un serveur X gérant le display 1 et s affichant dans le display 0 comme le montre la figure 3. Comme on le voit, le contenu de la fenêtre Xnest est vide. Celui-ci attend de recevoir des demandes de clients X. En effet, bien que client pour le display 0, Xnest est un serveur gérant ici le display 1 et a ouvert une socket unix pour être contactable par les clients locaux (nous avons précisé l option -nolisten tcp pour désactiver l écoute via TCP comme pour les autres serveurs X lancés avec la commande X) : $ ls -l /tmp/.x11-unix/ total 0 srwxrwxrwx 1 root root :43 X0 srwxrwxrwx 1 cpb utilisa. du domaine :35 X1 i On remarque que Xnest étant un processus lancé par cpb, la socket correspondante appartient aussi à cpb, qui a un contrôle total sur ce serveur. C. Pain-Barre, INFO - IUT Aix-en-Provence

55 55/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux FIGURE 3 Fenêtre Xnest (display 1) affichée par le serveur X (display 0). 11.I Affichage de fenêtres locales et distantes dans Xnest Si cpb veut afficher une fenêtre par exemple un gnome-terminal dans la fenêtre Xnest, il doit préciser que le display à utiliser n est pas 0 mais 1. gnome-terminal ne reconnaissant pas l option -display, on utilise la variable DISPLAY et on exécute : cpb@b99$ export DISPLAY=:1.0 cpb@b99$ gnome-terminal& [2] mais on obtient les messages d erreurs suivants : AUDIT: Sun Apr 20 19:36: : Xnest: client 1 rejected from local host (uid 13 Xlib: connection to ":1.0" refused by server Xlib: No protocol specified (gnome-terminal:28931): Gtk-WARNING **: cannot open display: :1.0 [2]+ Exit 1 gnome-terminal Le problème est que les clients exécutés par cpb pour le display 1 n ont pas l autorisation d affichage! En effet, l exécution de la commande Xnest n a pas ajouté d entrée concernant le display 1 dans ~/.Xauthority comme on le voit ci-dessous : INFO - IUT Aix-en-Provence C. Pain-Barre,

56 Enoncé du TP 7 Réseaux Version du 23/4/ /66 cpb@b99$ xauth list B99X/unix:0 MIT-MAGIC-COOKIE-1 2be3d8d46e74438e518d267fe4b289a8 localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 2be3d8d46e74438e518d267fe4b289a8 Ainsi, sans magic-cookie pour le display 1, impossible de communiquer avec le serveur Xnest! Même la méthode xauth nécessite une communication avec le serveur et donc un magic-cookie! Qu à cela ne tienne, il suffit d ajouter manuellement un magic-cookie pour ce display en utilisant xauth et le générateur de magic-cookie mcookie (ou finalement tout autre programme qui nous fournirait 32 digits hexadécimaux, on peut même les choisir nous mêmes...) en exécutant : cpb@b99$ mcookie 9f8dc34b4e5ea9f19f771eccfd21ca01 cpb@b99$ xauth add B99X/unix:1 MIT-MAGIC-COOKIE-1 9f8dc34b4e5ea9f19f771eccfd21ca01 ce qui peut se réduire à la seule commande : cpb@b99$ xauth add B99X/unix:1 MIT-MAGIC-COOKIE-1 $(mcookie) puis, en exécutant à nouveau gnome-terminal : cpb@b99$ gnome-terminal& [2] on obtient une fenêtre gnome-terminal opérationnelle dans notre Xnest : et là on se rend compte que notre fenêtre manque cruellement de décoration et il n est pas possible de la déplacer. Ceci par ce que dans le système X-Window, le serveur X ne sert qu à l affichage et ne s occupe pas de la décoration. Pour avoir un habillage (l ascenceur et le cadre autour de la fenêtre, permettant de la déplacer, l iconifier ou la redimensionner), il faut utiliser un gestionnaire de fenêtres. Sous gnome, le décorateur de fenêtre s appelle metacity. On peut alors décorer notre fenêtre ainsi que toutes celles qu on lancera dans Xnest en exécutant, à la suite des commandes précédentes, la commande : cpb@b99$ metacity& [3] C. Pain-Barre, INFO - IUT Aix-en-Provence

57 57/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux et l on obtient une décoration autour de la fenêtre gnome-terminal : Notre Xnest est maintenant prêt à recevoir tout type de fenêtres, y compris celles provenant d une machine distante. Par exemple, on peut exécuter une fenêtre venant d allegro en utilisant la redirection X11 en exécutant, à la suite des commandes précédentes, les commandes : cpb@b99$ ssh -X cpb@allegro Last login: Sun Apr 20 19:05: from portcpb.iut.univ-aix.fr cpb@allegro$ aterm >& /dev/null& [1] 1339 et l on obtient un aterm tournant sur allegro et décoré par metacity dans notre Xnest : INFO - IUT Aix-en-Provence C. Pain-Barre,

58 Enoncé du TP 7 Réseaux Version du 23/4/ /66 11.II Affichage du bureau gnome dans Xnest On peut aller plus loin et afficher un bureau dans Xnest. Le bureau sous gnome est produit par la commande gnome-session. Cependant cette commande utilise la variable d environnement SESSION_MANAGER pour savoir si un bureau est déjà actif. Pour afficher un bureau gnome dans Xnest, on ferme d abord les fenêtre gnometerminal et aterm puis on exécute, à la suite des commandes précédentes : cpb@allegro$ exit pour quitter la connexion SSH vers allegro cpb@b99$ kill pour arrêter metacity (dont le numéro de processus est ici qu on a pu noter quand on a exécuté metacity&) car gnome-session va elle-même en exécuter un cpb@b99$ echo $SESSION_MANAGER local/b99x:/tmp/.ice-unix/2261 cpb@b99$ unset SESSION_MANAGER cpb@b99$ gnome-session& SESSION_MANAGER=local/B99X:/tmp/.ICE-unix/30693 et l on obtient la fenêtre Xnest suivante : 11.III Affichage du bureau GNUStep de allegro dans Xnest Étape ultime de notre démonstration : l affichage du bureau GNUStep d allegro dans Xnest. Il n y a rien de plus simple car tout est déjà prêt. Il faut juste quitter proprement la session du bureau gnome de Xnest (par le menu Bureau Clore la session), puis exécuter à la suite des commandes précédentes : cpb@b99$ ssh -X cpb@allegro wmaker& où wmaker est à la fois le bureau GNUStep et le window manager de cet environnement. On obtient alors un fenêtre Xnest qui ressemble à : C. Pain-Barre, INFO - IUT Aix-en-Provence

59 59/66 Version du 23/4/2012 Enoncé du TP 7 Réseaux i La commande précédente ne rend pas la main car ssh attend la fin de wmaker. i Toutes ces opérations ont été réalisées sur les PC de l IUT mais peuvent l être depuis chez vous comme il est expliqué sur la page travail_distant. Exercice 25 (Travail avec Xnest) 1. Exécuter Xnest 2. Faire afficher dans la fenêtre Xnest un gnome-terminal et une fenêtre aterm provenant d allegro décorés par metacity 3. Fermer ces fenêtres et tuer metacity 4. Faire afficher le bureau GNUStep d allegro dans Xnest 5. Depuis un autre terminal, faire afficher dans la fenêtre Xnest un gnome-terminal décoré par wmaker 6. Quitter Xnest [Corrigé] i Il est aussi tout à fait possible d exécuter directement gnome-session sur allegro et d afficher le tout (le bureau) dans la fenêtre Xnest. La différence avec l exercice précédent est que le décorateur de fenêtres tourne sur allegro et non sur le PC, mais s affiche aussi sur le PC... INFO - IUT Aix-en-Provence C. Pain-Barre,