Un <foreignphrase>Shell</foreignphrase> sécurisé

Un <foreignphrase>Shell</foreignphrase> sécurisé Quand Tatu Ylonen à l'origine a écrit ssh, on l'a considéré comme un substitut de telnet et de rsh, qui sont des programmes/protocoles pour se connecter à distance (pour un accès distant à un shell). Cependant, ssh est un protocole réseau, ainsi il peut être utilisé pour créer des communications sécurisées entre des machines. Chaque serveur ssh posséde une clé privée——souvent située dans /etc/ssh/ssh_host_rsa_key. Souvent, il y a une seconde clé privée dans /etc/ssh/ssh_host_dsa_key. Le travail d'un administrateur réseau est de rassembler les clés publiques associées à chacune de ces clés privées (au même endroit, avec une extension .pub) et de les distribuer à toutes les machines du réseau. La manière la plus simple de faire ceci est de se rendre sur chaque ordinateur est de copier ces fichiers dans une clé USB (Universal Serial Bus, Bus série universel) : cp /etc/ssh/ssh_host_rsa_key.pub /media/usb/<ip_addr>.rsa.pub cp /etc/ssh/ssh_host_dsa_key.pub /media/usb/<ip_addr>.dsa.pub L'administrateur crée alors un fichier known hosts : for type in rsa dsa do for i in /media/usb/*.$type.pub do addr=$(basename $i .$type.pub) (echo -n "$addr "; cut -f1-2 -d' '< $i)>> known_hosts done done Ce fichier known_hosts est ensuite copié dans /etc/ssh/ssh_known_hosts pour chaque machine. En conclusion, nous avons définit des paramètres de configuration echo "StrictHostKeyChecking yes" >> /etc/ssh/ssh_config pour chaque machine. (Les utilisateurs de chaque ordinateur peuvent également devoir modifier le fichier de configuration $HOME/.ssh/config s'il existe et supprimer/editer $HOME/.ssh/known_hosts s'il existe). Après cette procédure (évidemment) prolixe (mais pas difficile), Abdul et Chin possédent les clés publiques de chacun. Ainsi, Abdul peut chiffrer des paquets que seul Chin peut lire et Chin peut vérifier des signatures faites par Abdul. (Le véritable protocole ssh est plus complexe et il ne nous concerne pas ici). Ainsi, à présent, à partir d'Abdul on peut se connecter via ssh sur Chin et être sûr que c'est Chin qui répond. Chin demandera cependant le mot de passe à moins que tous les serveurs permettent la directive HostBasedAuthentication dans /etc/ssh/sshd_config. Ce procédé pourrait être risqué pour Chin, à moins que l'utilisateur root sur Abdul soit considéré comme équivalent à l'utilisateur root de Chin. Que penser de types d'échange de données autres (que ssh) ? Heureusement, ceci aussi a été considéré. Si Abdul veut à présent ouvrir le port TCP (Transmission Control Protocol, protocole de contrôle de transmissions) (disons) 80 de Chin, alors Abdul éxecute ssh -q -f -N -L 8080:localhost:80 Chin À présent, se connecter à depuis Abdul donne accès au serveur web de Chin. Que pensez-vous de sécuriser toutes les données échangées ? Ceci a aussi été pris en compte. En fait, sous ssh il existe au moins deux manières : Les applications qui sont capables d'employer le protocole SOCKS (comme Mozilla et Thunderbird) peuvent utiliser un tunnel crée par cette commande : ssh -q -f -N -D 1080 Chin Il y a également des bibliothèques de wrapper comme tsocks qui peut apprendre à n'importe quelle application TCP comment utiliser SOCKS On peut également créer un tunnel TCP entre deux hôtes : ssh -q -f -N -w 0:any Chin En dépit de ses efforts, SSH ne convient pas toujours au problème que nous nous proposons de résoudre pour les raisons suivantes : Le mécanisme de distribution des clés est complexe. Ce n'est pas une bonne idée de percer un tunnel TCP au-dessus de TCP ainsi que l'explique Olaf Titz dans un article. Nous devons installer des tunnels entre chaque paire d'hôtes dans le réseau ; et c'est fastidieux.