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.
Lorsqu’on crée une paire de clés, on crée en fait deux fichiers liés par les règles suivantes :
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.
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).
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.
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.
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.
Voir en ligne : SSH : secure shell De l’utilisateur à l’administrateur, Frédéric Bongat
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.
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
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…