Le site des administrateurs systèmes sous Mac OS X
  Un grand pouvoir implique de grandes responsabilités.



Accueil du site > Dossiers > SSH et les paires de clés
SSH et les paires de clés


Clés publiques, clés privées et SSH mardi 9 octobre 2007, par Jayce Piel

Il est fortement recommandé d’utiliser SSH avec son mode de clé publique/privée. Cela permet soit plus de sécurité, soit plus de souplesse dans les scripts. Cet article vous expliquera le principe des doubles clés et leur utilisation.


Clé publique, clé privée

Lorsqu’on crée une paire de clés, on crée en fait deux fichiers liés par les règles suivantes :

  • tout ce qui est chiffré avec une des deux clés ne peut être déchiffré qu’avec l’autre.
  • tout ce qui est signé par la clé privée peut être vérifié avec la clé publique.

Il faut donc que la clé privée reste en la possession exclusive d’un utilisateur, alors que la clé publique peut(doit) être distribuée. Ainsi, si je vous donne ma clé publique, vous pourrez déchiffrer les documents que je vous envoie en étant sûrs que c’est moi qui les ait chiffrés. Inversement, vous pourrez chiffrer un document avec ma clé publique pour être sûrs que moi seul pourrait le lire.

Pour « garantir » [1] la confidentialité et la sécurité d’un échange entre les utilisateurs A et B, il faut que chacun ait sa propre paire de clés. A chiffrera le document avec sa clé privée, puis avec la clé publique de B. Seul B pourra déchiffrer le document reçu avec sa clé privée, et il sera sûr que le document a bien été envoyé par A puisqu’il devra ensuite déchiffrer le document avec la clé publique de A.

Générer la paire de clés

Ouvrez le Terminal et tapez la commande :

ssh-keygen -t rsa

La commande vous propose de créer un fichier id_rsa (la clé privée) dans un répertoire .ssh situé à la racine de votre compte utilisateur. Si ce répertoire n’existe pas, il sera créé avec les bons droits (700 pour que seul l’utilisateur puisse y accéder) par la commande. Au même endroit, il créera un autre fichier du même nom mais avec l’extention .pub (id_rsa.pub) correspondant à la clé publique.

Vous pouvez donner une passphrase (une passphrase, c’est un mot de passe, mais au lieu d’un mot, vous pouvez utilisez une phrase) afin de mieux sécuriser votre clé, mais ce n’est pas obligatoire (voir plus bas).

Envoyer la clé publique

Tapez les commandes suivantes :

ssh lecompte@leserveur mkdir -p ~/.ssh
scp id_rsa.pub lecompte@leserveur:./myrsa.pub
ssh lecompte@leserveur cat ~/myrsa.pub >>~/.ssh/authorized_keys

Désormais, la commande ssh <serveur> ne vous demandera plus que la passphrase, si vous en avez donné une (au lieu du mot de passe). J’en conviens : pas beaucoup de changement en apparence, sauf que la passphrase n’est pas envoyée sur le réseau, mais est utilisée localement pour authoriser l’utilisation de la clé.

Si vous n’avez pas mis de passphrase, la connexion est directe, un peu comme (pour ceux qui connaissent), le bon vieux rlogin (la connexion reste quand même cryptée bien sûr). Ce dernier mode est très utile pour les scripts.

Déploiement des clés publiques

Si vous avez des scripts qui doivent se connecter à de nombreuses machines pour lancer une ou plusieurs commandes, vous apprécirez le script ci-joint.

Zip - 739 octets
Script de déploiement des clés publiques

Le script déploie la clé publique du compte courant définie dans le fichier ~/.ssh/id_rsa.pub (ainsi que les éventuelles autres clés publiques définies dans les fichiers ~/.ssh/id_rsa.pub.*) sur le compte ladmin des machines définies dans le fichier liste_machine qui se situe dans le même répertoire que le script. Dans ce script je considère que les machines sont sur le réseau local et que je peux les contacter en Bonjour, je rajoute donc .local à chaque nom de machine. Ce script ne peut pas être lancé automatiquement, car il va demander le mot de passe du compte admin pour toutes les machines sur lesquelles la clé publique n’a pas été envoyée.

Je vous laisse étudier le script et l’adapter à vos besoins.


[1] La « garantie » n‘est valable que si on est réellement sûr de la sécurité lors de l‘échange de clés.


[ Haut ] Enregistrer au format PDF

Creative Commons License

Cette création est mise à disposition sous un contrat Creative Commons.




Recommandez ce site à un ami :

Votre Prénom : E-mail de votre ami :

Valid XHTML 1.0 Transitional

FORUM DE L'ARTICLE :



4 Messages de forum
SSH et les paires de clés

18 octobre 2007 00:18, par jbordier
Votre article est intéressant mais incomplet et je recommande la lecture du document cité en reference (authentification par paire de clés à partir de la page 76). Quelques remarques La phrase d’authentification (passphrase) ne circule pas sur le réseau. Elle sert localement à activer la clé privée. C’est la principale différence avec le mot de passe classique. Le choix de cette phrase a cependant son importance, il faut ne pas la laisser vide et , par précaution, elle doit comporter au moins 14 caractères. Un autre point à prendre en considération est la configuration de ssh côté serveur. Il faut désactiver la connexion avec le compte root et la connexion par mot de passe classique en changeant les valeurs par défaut des parametres correspondant (PermitRootLogin no et PasswordAuthentication no) dans le fichier /etc/sshd_config. Pour que la connexion avec mot de passe soit effectivement désactivée il faut de plus changer la valeur du parametre UsePAM à no.

Voir en ligne : SSH : secure shell De l’utilisateur à l’administrateur, Frédéric Bongat


SSH et les paires de clés

18 octobre 2007 22:50, par Jayce Piel

Merci pour les commentaires et le lien. J’ai corrigé l’article sur l’utilisation de la passphrase.

Pour le fait que l’article soit incomplet, par contre, je ne suis pas d’accord. Les recommandations sur la passphrase et sur la configuration de ssh sont intéressantes et vrai, mais ne rentrent pas dans le cadre de cet article. Cet article est vraiment ciblé sur l’utilisation des paires de clés avec SSH , ce qui, si on ne met pas de passphrase, permet de faire du « rlogin sécurisé »…

Je ne serai pas contre, bien sûr, si l’auteur du document cité est d’accord, pour qu’on (toi ou un autre) reprenne sur mosx.org l’intégralité de son article qui est très intéressant, mais dont le format n’est pas très pratique à lire.


SSH et les paires de clés

19 octobre 2007 11:27, par jbordier

Je reconnais que le mot « incomplet » était un peu fort et que la question de la securisation d’une machine acceptant les connexions ssh n’était pas le sujet de votre article qui se place dans l’optique d’un administrateur système maitrisant ses actions.

Le probleme n’est pas le même pour le simple utilisateur pour lequel il est fortement déconseillé d’avoir une clé privée sans passphrase.

Le document de F.Bongat qui est sous forme de diapos est difficilement consultable sur un site web. Je vais lui demander s’il possède une version editable.

Jerome Bordier


SSH et les paires de clés

19 octobre 2007 11:41, par Jayce Piel

Là on est d’accord. :-) Et j’espère F.Bongat aura son dicument sous une autre forme ou sera d’accord pour qu’il soit repris sur notre site.

Bon, cet échange de messages long m’a par contre fait voir que la présentation des messages telle qu’elle est aujourd’hui n’est pas géniale et qu’il faut vraiment que je modifie le squelette du site pour ça…