jose@cwru.edu
jerome@fenal.org
Copyright © 2001 par Jose Nazario
Je discutais récemment avec un ami à propos de la façon d'utiliser SSH afin d'arriver à une façon sûre de faire de l'authentification sans mot de passe. Il recherchait un moyen d'automatiser des transferts de fichiers et voulait le faire en utilisant un script expect (pour injecter le mot de passe lors de sa demande) afin d'automatiser le processus. Je lui ai suggéré « ssh-agent », mais je ne savais pas comment le faire fonctionner à ce moment-là. Depuis, j'ai appris, et c'est relativement facile.
L'utilisation de l'agent pour l'authentification par clés et une méthode pour faciliter les communications. Vous pouvez utiliser l'authentification sans agent, vous avez juste à déverrouiller la clé à chaque fois que vous voulez l'utiliser. Notez que par défaut, le client SSH essaiera de vous authentifier en utilisant les clés avant le mot de passe. L'agent simplifie largement la gestion de tout ça.
Il existe plusieurs mises en oeuvre du protocole SSH, chacune avec ses particularités d'usage et de comportement. Les deux les plus communes sont celles de openssh.org et de ssh.com. OpenSSH a été écrit pour OpenBSD, et est donc un logiciel libre. Le produit ssh de ssh.com est un produit commercial gratuit pour les systèmes d'exploitation libres (et pour les utilisations non-commerciales, ou à titre d'essai ou d'enseignement sur les autres systèmes d'exploitation). Chacune de ces mises en oeuvre a ses petites particularités de comportement et à l'utilisation.
Comme si de multiples logiciels n'étaient pas suffisants, il existe aussi deux protocoles SSH, SSH1 et SSH2. Cet article se focalisera uniquement sur l'utilisation du protocole SSH1, qui diffère légèrement du protocole SSH2. Plusieurs articles précédemment parus la Linux Gazette ont présenté l'utilisation de ssh-agent pour SSH2 (cf. plus bas). Notez que par défaut, SSH2 utilise des clés DSA, ainsi que des noms de répertoires et de fichiers différents de SSH1, bien qu'une certaine compatibilité puisse être conservée. Comme la plupart des gens utilisent le protocole SSH1 (données issues d'une récente scrutation de l'Internet avec scan-ssh par l'Université de l'Alberta), nous nous concentrerons donc sur cette version. OpenSSH suit, quasiment parfaitement, la syntaxe du programme ssh1 de ssh.com en ce qui concerne la gestion des clés par l'agent. Notez bien que cela diffère de la gestion de SSH2 (non couvert ici).
Les avantages de l'authentfication RSA sont nombreuses, brutes de fonderie :
Dans l'authentification RSA, chaque côté doit vérifier qu'ils sont bien ceux qu'ils disent qu'ils sont. Le client vérifie que le serveur est bien celui qu'il doit être (par rapport à leur clé publique, stockée dans le fichier ~/.ssh/known_hosts), et le serveur vérifie l'authenticité de l'identité du client via une clé RSA. Cela est utilisé pour se protéger d'une attaque du type « homme du milieu », grâce à la véracité des clés des serveurs.
Les clés RSA peuvent être protégées par une phrase de passe, et non un mot de passe, ce qui ouvre un plus grand espace de recherche pour des méthodes d'attaque par la force brute. Ainsi, au lieu de « p@55w0rd », vous pouvez utiliser « Toby Betts est le cothurne de David Monk et drague F0xT4il. » (Vous devriez utiliser quelque chose de plus complexe que l'un ou l'autre de ces deux exemples.)
La force d'une authentification signifie, dans ce cas une paire de clés RSA, est relativement forte. Le chiffrement RSA est connu pour son coût et l'infaisabilité d'une attaque de type force brute. On ne peut pas dire la même chose des mots de passe.
Vous n'aimez pas taper des mots de passe souvent, non ? Moi aussi. Après quelques moments passés à tout mettre en place (ce qui fait à peu près autant de frappe au clavier qu'un mot de passe d'authentification de session), ce qui se fait maintenant sans effort, connectez-vous simplement à l'hôte distant et votre authentification est prise en charge.
Ainsi, je ne vois aucune raison (autre que ne pas savoir comment faire, ce que ce document essaie de vous enseigner) pour ne pas l'utiliser.
| Suivant | ||
| Composants |