Le matériel nécessaire à la réalisation de ce travail est disponible à l’url suivante : http://infoweb-ens/~hernandez-n. Ce TD est inspiré d'un TD proposé par Keryel, Leroy et Ménard, 2003
L'objectif de ce travail est apprendre à se connecter sur un système distant à l'aide de la commande ssh.
Dans le cadre de ce TP on
utilisera OpenSSH. La version 2 du protocole ssh est la plus récente.
La commande ssh permet de se connecter à distance ou de lancer des
commandes à distance. La commande scp permet de copier des fichiers
à distance. La commande sftp fournit une interface FTP pour les
nostalgiques.
Il existe plusieurs protocoles Internet permettant
de se connecter à un ordinateur distant : telnet, les
r-commandes (rlogin, rsh ou encore rcp), ssh (Secure
Shell). Alors que telnet et les r-commandes font circuler les
informations en clair sur le réseau, ssh est beaucoup plus sûr :
le client et le serveur s'authentifient mutuellement, ce qui évite que des pirates se fassent passer pour l'un ou pour l'autre
les données échangées sur le réseau par le biais de ssh sont chiffrées, ce qui garantit leur confidentialité
À partir d’ici oublier que telnet, rlogin ou ftp aient pu exister , et ne les utilisez plus que sous la menace.
Il vous est demandé de rédiger un rapport succin correspondant à vos réponses aux questions. Relevez et expliquez les manipulations que vous réalisez si besoin est.
Pour réaliser ce travail, les réponses sont à chercher dans le support de cours, les man(uels) des commandes utilisées et éventuellement sur l'Internet (en priorité les sites de la section bibliographie ci-dessous). N'hésitez pas à utilisez les commandes que vous connaissez déjà pour auditer le bon fonctionnement des outils que vous utilisez (netstat pour les ports locaux ouvert en lecture, nmap les ports distants ouverts, wireshark pour voir qui communique et le contenu ce qui est communiqué ...).
Pour ce travail, vous utiliserez le réseau accessible via votre interface eth1. Configurez cette interface. Chaque machine reçoit une adresse IP privée de classe C de type : 192.168.0.<votreIdentifiantSurLaPriseAuDosDeVotreMachine>. Fermer eth2 pour contrôler votre réseau (ifconfig eth2 down).
Tout le monde est tenu de changer le mot de passe de son compte root et de créer (adduser) un compte avec comme nom de login et mot de passe : distant/distant.
Premiers tests
Personnellement je tourne avec la version SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3.. Et vous ? Tapez ssh -v
Apprenez
à détourner les commandes que vous utilisez pour certains usages
vers d'autres usages. Sachant que le service ssh tourne sur le port
22, interrogez le avec :
nc localhost 22
Tourne t il ?
Lancement
du serveur ssh et format de demande de connexion
Tentez de vous connecter
sur une machine voisinessh
compte-distant
@machine-distante
Si cela
ne marche pas, cela signifie que vos acolytes ne font pas tourner de
démon sshd sur leur machine ou que leur compte test n'est pas
encore actif.
Afin que chacun puisse se connecter par ssh sur
votre machine lancer, en tant que root, le démon sshd (ou ssh selon
les versions)
/etc/init.d/sshd
start
Se
connecter via ssh sur une machine distante d’un collègue.
Remarquez qu’à la
première utilisation votre client ssh dit qu’il ne connaît pas la
clé publique du sshd de la machine distante et l’affiche. C’est
typiquement le problème de l’authentification par mécanisme
public et l’oeuf ou la poule : comment être sûr que le sshd qu’on
veut atteindre est bien celui auquel on pense et qu’on n’est pas
redirigé par un moyen quelconque vers un sshd pirate qui espionnera
tout ce que vous faites ?
C’est justement cette clé privée
distante qui permet de vérifier ça. Si vous vous êtes déjà
connecté sur votre machine via ssh, ~/.ssh/known_hosts
contient déjà cette clé et ssh reconnaissant une machine amie ne
vous posera pas la question précédente. Si votre connexion est
détournée, ssh refusera la connexion car la clé renvoyée par le
sshd distant ne sera probablement pas celle de ~/.ssh/known_hosts.
Continuez la connexion et authentifiez vous. Puis déconnectez vous (CTRL + D) et reconnectez vous. L'affichage est il le même ?
Supprimez le fichier et tentez de vous connecter.
Mais revenons au problème
de la question initiale de "la première fois" : comment
être sûr que c’est la bonne clé qui est envoyée et donc que
c’est bien la même machine ? Plusieurs solutions :
– vous
connaissez la clé par coeur et vous voyez bien que c’est la même
,;
– vous l’avez sur une disquette, un CDROM, une carte ou un
ruban perforée ;
– vous avez coupé en 3 votre clé : un bout
est gravé sur votre chaussure gauche, un autre est brodé
à
l’intérieur de votre slip et enfin le dernier morceau est tatoué
en haut de votre nuque ;
– vous interprétez la signature de la
clé en binaire et faites le piercing correspondant (entre 0 et
128
trous) ;
– vous n’avez pas de solution et vous acceptez de
vous connecter après avoir fait une prière.
Auditer
votre connexion
Testez les commandes last, netstat, nmap, who, ifconfig (avec les options qui vont bien) sur le poste distant après connexion. A quoi servent ces commandes ? Identifiez vous d'autres personnes connectées ? De même chacun sur son poste local peut utiliser les mêmes commandes. Identifiez vous qui est actuellement connecté chez vous ?
Essayer de sniffer le contenu d'une connexion ssh avec wireshark (pas nécessairement une connexion entrante ou sortante). Identifiez vous qui est connecté sur qui ? Arrivez vous à lire le contenu ?
Après avoir supprimé ~/.ssh/known_hosts, lancez une connexion en mode verbeux (voir le man) et analyser la procédure.