Secure Shell : OpenSSH

Les accès réseau sécurisés.

Pour ouvrir une session sur un ordinateur distant sur un réseau TCP/IP, que ce soit en LAN ou en WAN, on utilise fréquemment des outils comme telnet, rlogin ou ftp. Mais on sait maintenant que des outils existent sur n'importe quel site Internet, qui permettent, même avec un OS aussi simple que Windows 9x, de visualiser et décoder les paquets TCP/IP et éventuellement de lire en clair tout le traffic du réseau. Dans ces conditions, un mot de passe, même crypté, est une faille de sécurité potentielle. Plusieurs solutions existent pour pallier à ce problème de sécurité. On peut par exemple mentionner SRP, décrit sur http://www.ifrance.fr/cmic/netsec/srp.html

Avec l'utilisation de SSH, la totalité de la session de travail sur le réseau est cryptée. SSH permet donc d'utiliser de façon sécurisée un réseau non-sécurisé. Nous allons examiner le procédé employé, l'installer sur une plateforme d'essai, puis l'utiliser.

Fonctionnement de SSH.

Pour la version 1.5 du protocole, le draft de T. Ylonen , qui date de 1995, donne toutes explication nécessaires. A partir de la version 2, qui est la plus utilisée aujourd'hui, des modifications importantes ont été réalisées sur le protocole. Le fonctionnement est le suivant.

SSH comporte 3 composants principaux :

• La couche de transport qui fournit l'authentification du serveur, la confidentialité et l'intégrité des données
• Le protocole d'authentification qui permet de certifier l'identité de l'utilisateur du client auprès du serveur,
• Le protocole de connexion qui est chargé du cryptage proprement dit. Ce protocole s'appuie sur le protocole d'authentification.

L'ensemble fonctionne sur un modèle client serveur. Dans le cas d'utilisation du protocole TCP/IP sur le réseau, la procédure suivante se déroule entre la machine cliente et la machine serveur :

• Dès que la connexion est établie (protocole TCP sur un port dédié du serveur), le client et le serveur échangent en clair leurs numéros de version du protocole SSH. On ne peut d'ailleurs pas éviter cet échange en clair.
• Sitôt effectué ce premier échange, le client et le serveur utilisent un protocole binaire par paquet.
• Le serveur commence par envoyer au client sa clef d'hôte, sa clef de serveur, la liste des méthodes de cryptage supportées, la liste des méthodes d'athentification supportées, des indicateurs d'extensions de protocole, et un cookie que le client devra renvoyer.
• Le client et le serveur calculent séparément un identifiant de session.
• Le client génère alors une clef de session de 256 bits, la crypte en utilisant les 2 clefs RSA du serveur (clef d'hôte et clef de serveur), puis envoie au serveur la clef de session cryptée, le type de cryptage utilisé, et une copie du cookie du serveur. L'ensemble de ce message est envoyé en clair. Le client passe ensuite en mode crypté.
• Le serveur répond au client par un message de confirmation crypté.
• Les deux parties, le client et le serveur, sont maintenant en mode crypté avec l'utilisation de l'algorithme et la clef sélectionnés.
• C'est alors que le client va demander une authentification de l'utilisateur en envoyant le nom de l'utilisateur et la clef publique de l'hôte client sur le serveur. avec une des méthode suivantes :
  • ~/.rhosts ou /etc/hosts.equiv (par défaut, cette méthode est désactivée),
  • ~/.rhosts ou /etc/hosts.equiv avec la méthode d'authentification de l'höte RSA,
  • authentification RSA,
  • authentification par mot de passe.
  • authentification RSA (client -> serveur et serveur ->client) avant d'aceppter le .rhosts et/ou /etc/hosts.equiv.

     

    Le protocle de transport détaillé est décrit dabns le document draft-ietf-secsh-transport-07.txt

    Cryptage par clef publique et clef privée.

     

    Les différentes implémentations de SSH.

    SSH1, la première version de SSH (protocole V1.2 et V1.5) a été écrite en 1995 par T. Ylonen, un professeur Finlandais. Cette première version était gratuite. La licence devint plus restrictive à partir de la version 1.2.12, en 1997. A cette date, le développement et la commercialisation de SSH2 fut confiée à Data Fellows puis à SSH Communications : on pouvait alors utiliser gratuitement SSH, mais seulement dans un but non commercial.

    OSSH, une version libre de SSH, a été écrite par B.Gronvall. C'est en fait une version sans bogues de SSH V.1.2.12

    L'équipe de OpenBSD, qui a tourjours mis l'accent sur la sécurité sur cet OS libre, a repris OSSH, y a inclus les patches correctifs de la version 1.2.12 à la version 1.2.27, a enlevé les algorithmes IDEA/RC4, le mode "non-crypté", en en a tiré OpenSSH. C'est la seule version vraiment intéressante à ce jour, car:

    • c'est un produit qui est maintenu par une équipe,
    • elle contient la possibilité d'authentification par Kerberos 4 et SKEY,
    • les sources sont gratuites et libres de droits,
    • les protocoles SSH 1.3, 1.5 et 2.0 sont supportés (compatibilité avec toute implémentation SSH ou OpenSSH),
    • le protocole IPV6 est supporté,
    • OpenSSH utilise les algorithmes BlowFish et triple DES pour crypter un session et RAS pour crypter la clef FIXME.
      
      Par contre, quelques inconvénients sont à signaler :
      
    • il est nécessaire d'avoir les bibliothèques ssl (OpenSSL), et zlib pour compiler OpenSSH,
    • si le système d'exploitation hôte n'a pas de device /dev/random, il est nécessaire d'ajouter l'Entropy Generator Device. C'est par exemple le cas pour le système d'exploitation Solaris.
    • l'authentification SecuID n'est pas supportée,
    • des problèmes de sécurité ont été trouvés avec la version 2.1 et antérieures. Ces problèmes ont été éliminés dès la version 2.1.1. Voir à ce sujet le suivi des problèmes de sécurité sur FIXME.

     

---

 ©2000, 2001 cmic. Mise à jour le 12-octobre-2001