Identification et clés OpenSSH
Je vais juste essayer de faire le point sur l’identification OpenSSH, et plus particulièrement sur l’utilisation des clés publique/privée.
La suite des utilitaires fournis par OpenSSH se veut d’être LES outils sécurisés de remplacement des programmes historiques de travail à distance que sont telnet, rlogin, rcp, rsh et autre ftp : leur utilisation permet de ne travailler qu’avec des flux de connexion entièrement cryptés, rendant très difficile (du moins dans un temps humainement acceptable) la lecture des paquets transitant sur le réseau entre les machines.
Quoi qu’il en soit, avant que la liaison sécurisée ne s’établisse, OpenSSH procède à un échange des clés secrètes de cryptage symétrique, et doit, pour ce faire, procéder à l’authentification de l’utilisateur initiant la connexion.
Dans le cadre normal des opérations, cette authentification est dévolue – par le daemon opensshd – au sous-système d’identification sous-jacent (par exemple : PAM pour un système GNU/Linux), ce qui nécessite la saisie du mot de passe de l’utilisateur concerné.
Cette phase d’authentification peut être shuntée par la création d’une paire de clés asymétriques : la clé privée restant stockée sur la machine devant initier la connexion, la clé publique étant transmise, sur le serveur distant, à l’utilisateur à connecter.
La commande de génération des clés (dans sa forme la plus simple), est à exécuter sur le système client avec le compte de l’utilisateur qui initiera la connexion vers le système de destination :
utilisateur1:~/$ ssh-keygen -t dsa -b 1024 (puis validez tout … ou pas !)
va générer les deux fichiers (dans le répertoire .ssh/ de l’utilisateur) id_dsa et id_dsa.pub.
Bien entendu, il est possible d’indiquer un nom plus explicite pour ces fichiers durant la procédure de génération.
Une fois les clés générées, il faudra transmettre la clé publique sur la machine cible :
utilisateur1:~/$ ssh-copy-id -i ~/.ssh/id_dsa.pub utilisateur2@machine_a_connecter
Cette commande va ajouter la clé publique qui vient d’être générée au fichier .ssh/authorized_keys de l’utilisateur cible sur la machine à connecter, ce qui permettra à OpenSSH d’identifier la connexion sans interroger le système sous-jacent.
Si vous fournissez ‘Pass Phrase’ lorsque ssh-keygen vous pose la question, la connexion via ssh vous la demandera lors de toute tentative de connexion. Le rôle de cette Pass Phrase et de s’assurer que le possesseur de la clé privée est bien la personne ayant généré la paire de clés, et non pas un simple voleur de clés !
Dès lors, Pour une utilisation interactive, saisir la Pass Phrase permettra de s’affranchir du problème de vol ou compromission de la clé privée, d’autant que l’utilisation de l’agent ssh (commandes ssh-agent et ssh-add) permettront de ne la saisir qu’une fois pour toutes en début de session… Par contre, pour une utilisation automatisée (scripts, cron, etc..) mieux vaut ne pas renseigner la Pass Phrase car, de toutes façons, il faudra la stocker dans un fichier pour pouvoir la fournir le moment venu !
Enfin, concernant le type de clés à générer, la commande spécifiée ci-dessus indique un type DSA (pour Digital Signature Algorithm). Cet algorithme n’est supporté que par la version 2 d’OpenSSH, la version 1 ne permettant d’utiliser, quant à elle, que l’algorithme RSA (pour Rivest Shamir Adleman).
La cryptographie RSA est basée sur la difficulté à factoriser le produit de deux nombres premiers. Ces derniers devant être de taille égale (par exemple de 512 bits pour travailler sur une clé de 1024 bits) et répondre à un certain nombre de critères de robustesse (cf. algorithme de Gordon).
La cryptographie DSA, est dérivée du chiffre El Gamal, reposant sur le problème du logarithme discret pour lesquels les meilleurs algorithmes de résolution connus à ce jour sont de complexité O(racine de n), n étant la taille de l’exposant de la racine primitive choisie.
Mise à jour 2017 :
Avec la version 7 d’OpenSSH (qui a été intégrée à Debian 9 – Stretch), les clés DSA sont marquées « deprecated » et donc désactivées par défaut. A partir de cette version il faut générer des clés RSA de longueur minimale de 2048 bits.
Pour en terminer avec cette courte digression sur openSSH, j’avais également l’habitude d’installer sur les serveurs auxquels j’accède par SSH, un outil tout simplement génial : DenyHost (apt-get install denyhost sous debian 7), outil qui a malheureusement disparu avec Debian Jessie, au profit de fail2ban.
Il s’agit d’un daemon écrit en python qui scrute les logs à la recherche de tentatives de connexions ssh, et qui au terme d’un certain nombre de tentatives échouées (configurable, mais typiquement de 3) ajoute l’adresse I.P. de l’attaquant dans le fichier /etc/hosts.deny, empêchant ainsi la multiplication des attaques par dictionnaires …
DenyHost peut également être configuré pour envoyer un message électronique pour chaque détection de tentative d’intrusion, et vous seriez étonné du nombre de mails de la sorte reçus tous les jours, y compris sur une ligne ADSL ne disposant pas d’une adresse I.P. Fixe !
Références :
- OpenSSL : La librairie des fonctions cryptographiques utilisée par le projet OpenSSH.
- Théorie des Codes : Livre de Jean-Guillaume Dumas, Jean-Louis Roch, Eric Tannier, Sébastien Varrette paru aux Editions Dunod (coll. Sciences Sup).
Catégories : Administration système · Mots-clés: Administration système, cryptographie, sécurité
