User:Rominet: Difference between revisions

Jump to navigation Jump to search

User:Rominet (view source)

Revision as of 19:07, 6 March 2019

39,808 bytes added ,  6 March 2019
French: tutorial on public key authentication with SSH, tailored for users of Git and download_and_compile.sh
(Start user page)
 
(French: tutorial on public key authentication with SSH, tailored for users of Git and download_and_compile.sh)
Line 1: Line 1:
This space is intentionally left blank. :-)
== Vocabulaire technique français/anglais ==
 
;authentification (authentication)
: Action consistant à s'assurer que la personne/le serveur/etc. « en face » (de manière figurée) est bien celle/celui à qui l'on croit avoir affaire.
 
;chiffrement (encryption)
: Transformation réversible de données, de sorte qu'un tiers n'ayant pas la clé de déchiffrement ne puisse extraire aucune information utile à partir du contenu chiffré. La ''cryptographie symétrique'' utilise la même clé pour chiffrer et déchiffrer. À l'inverse, en ''cryptographique asymétrique,'' on travaille avec une paire de clés : une clé privée et une clé publique, les deux étant associées. Pour chiffrer un message, on utilise la clé publique du destinataire. Pour le déchiffrer, celui-ci utilise sa clé privée. On peut réaliser une ''signature numérique'' en utilisant la clé privée puis la clé publique (ceci est une description simplifiée de ce que font les logiciels tels que [https://www.gnupg.org/ GnuPG] lorsqu'ils produisent une signature numérique ; en effet, il est de bon ton d'ajouter quelques métadonnées au message pour garantir son intégrité).
 
;empreinte numérique (hash, fingerprint)
: Les identifiants de commits Git sont des empreintes numériques obtenues à partir du contenu du commit (y compris ses métadonnées, dont font partie les identifiants des commits parents). Exemple d'identifiant de commit Git : 44b411964109e6d0224577147c6e92d240c7a6cc.
 
;dépôt (repository) [Git, Subversion, etc.]
: Ensemble de fichiers et répertoires avec des métadonnées permettant de reconstituer toutes les versions antérieures « enregistrées » de chacun des fichiers. On peut obtenir une copie locale d'un dépôt existant en faisant <code>git clone ''adresse_du_dépôt_source''</code>. L'opération de clonage est donc ''la première'' qui amène un dépôt donné sur votre système (disque dur, etc.). Une fois un dépôt cloné, on peut le mettre à jour avec des commandes telles que <code>git pull --rebase</code>. Si vous utilisez <tt>download_and_compile.sh</tt>, c'est lui qui se charge d'appeler Git avec les commandes adéquates pour cloner et mettre à jour. Il ne vous reste qu'à choisir le protocole à utiliser ; ce qui suit devrait vous aider dans ce choix.
 
== Motivation ==
 
Git peut utiliser divers protocoles pour communiquer avec le serveur : le vieux protocole <tt>git</tt>, le protocole <tt>https</tt> ainsi que <tt>ssh</tt>. Quand on fait quelque chose comme
<pre>git clone ssh://...</pre> ou
<pre>git clone https://...</pre>
le mot précédant <tt>://</tt> indique quel protocole Git doit utiliser.
 
Avantages et inconvénients des trois protocoles :
* Avec le vieux protocole <tt>git</tt>, les données transférées ne sont pas chiffrées et le serveur n'est pas authentifié. Cela signifie que quelqu'un qui est « bien situé » sur le réseau peut non seulement voir ce que vous téléchargez, mais aussi qu'il peut se faire passer pour le site depuis lequel vous croyez télécharger. Le deuxième point est assez embêtant, car il signifie qu'on peut vous refiler un dépôt contenant un malware (virus, cheval de Troie, etc.). Ce risque est potentiellement limité dans le cas particulier d'un dépôt Git, à condition de vérifier le hash du dernier commit après chaque mise à jour de chaque dépôt et de le comparer à une source sûre (qui fait cela ?). Et encore, l'algorithme utilisé pour les hash des commits Git, SHA-1, a déjà été beaucoup étudié<ref name="Google-work-on-SHA-1">Voir par exemple ces [https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html travaux de Google].</ref> ; il n'est pas exclu qu'un de ces jours, on puisse fabriquer un commit foireux qui a le « bon hash », c'est-à-dire celui du dernier commit dans le dépôt officiel. Pour cette raison, il vaut mieux éviter ce protocole.
* Avec le protocole <tt>https</tt>, les données transférées sont chiffrées et le serveur est authentifié. Le principal problème est que ce protocole n'a pas l'air parfaitement implémenté chez [https://sourceforge.net/ SourceForge] : il est souvent impossible de cloner un dépôt très volumineux comme [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData]. Pas de problème avec les dépôts de taille plus modeste à ma connaissance. Pas de problème non plus, en général, pour mettre à jour un dépôt volumineux déjà cloné (il est possible de cloner avec un protocole et mettre à jour avec un autre : il suffit de modifier le fichier <tt>.git/config</tt> à l'intérieur d'un dépôt pour changer le protocole utilisé lors des mises à jour).
* Avec le protocole <tt>ssh</tt>, les données transférées sont chiffrées et le serveur est authentifié. Le principal problème est que pour utiliser ce protocole, il faut soi-même s'authentifier auprès du serveur (alors que l'on peut lire « anonymement » avec <tt>https</tt>), ce qui nécessite soit d'entrer un mot de passe, soit d'utiliser une paire de clés privée/publique. C'est en revanche un avantage pour le développement, car l'authentification permet d'exécuter des commandes <code>git push</code> si le serveur est configuré pour vous autoriser à le faire.
 
Quand <tt>download_and_compile.sh</tt> clone un nouveau dépôt, il utilise par défaut le protocole <tt>https</tt>. Ceci fonctionne bien sauf pour [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData], à cause de ce qui vient d'être dit (dépôt très volumineux, problème probable chez SourceForge). Comme le protocole <tt>git</tt> n'est pas satisfaisant non plus, je propose de cloner les dépôts hébergés chez SourceForge avec le protocole <tt>ssh</tt>. En appelant <tt>download_and_compile.sh</tt> de la manière suivante :
download_and_compile.sh --git-clone-site-params=SourceForge=ssh:''username'' DATA
on dit à <tt>download_and_compile.sh</tt> de cloner ou mettre à jour FGData. Si ce dépôt existe déjà à l'endroit attendu par <tt>download_and_compile.sh</tt>, il sera mis à jour en utilisant le protocole indiqué dans le fichier <tt>.git/config</tt> à l'intérieur du dépôt (qui, sauf si vous l'avez modifié, est celui utilisé lorsque le dépôt a été cloné). Sinon, il sera cloné et comme on a passé l'option <code>--git-clone-site-params=SourceForge=ssh:''username''</code> et que FGData est situé chez SourceForge, <tt>download_and_compile.sh</tt> utilisera pour cette opération de clonage le protocole <tt>ssh</tt> ; il dira au serveur chez SourceForge que vous êtes l'utilisateur ''username'', et il faudra donc prouver à SourceForge que c'est bien le cas (il faut bien sûr remplacer ''username'' par votre nom d'utilisateur chez SourceForge).
 
La manière la plus simple d'apporter une telle preuve consiste à entrer votre mot de passe SourceForge, mais il faudra alors le faire pour chaque opération de clonage ou de mise à jour du dépôt via <tt>ssh</tt>. Si vous travaillez avec plusieurs dépôts, par exemple si vous faites :
download_and_compile.sh --git-clone-site-params=SourceForge=ssh:''username''
(commande qui clone ou met à jour, puis compile [https://sourceforge.net/p/flightgear/simgear/ci/next/tree/ SimGear] et [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/ FlightGear], et clone ou met à jour [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData]), il faudra entrer le mot de passe pour chaque dépôt. Vous devinez que cela devient vite pénible. Heureusement, il y a une autre manière de prouver à SourceForge que vous êtes bien l'utilisateur ''username'' : elle utilise la cryptographie asymétrique, autrement dit une paire de clés (privée, publique) au lieu d'un mot de passe. Cette méthode est sûre et permet de n'entrer le mot de passe de votre clé privée<ref name="ne-pas-confondre-mdp-clé-privée-et-mdp-compte-SourceForge">À ne pas confondre avec le mot de passe de votre compte chez SourceForge !</ref> qu'une fois pour tous les dépôts, jusqu'à ce que vous éteigniez votre ordinateur<ref name="condition-de-cession-des-clés-par-l'agent-SSH">Pour simplifier : nous donnerons des conditions plus précises ci-dessous.</ref>, ou jusqu'à épuisement d'un certain temps, ou encore jusqu'à ce que vous décidiez de mettre fin à la « mémorisation » de votre clé par l'agent SSH (notion qui sera présentée plus loin). Le but de la section suivante est de vous apprendre à mettre en place cette méthode d'authentification sûre et pratique, qui est valable dans le cadre général de l'utilisation de SSH.
 
== Authentification SSH par paire de clés privée/publique ==
 
À l'exception des manipulations effectuées sur les pages web de [https://sourceforge.net/ SourceForge], ce qui suit est valable pour toute connexion entre un client et un serveur SSH. Si l'accent est mis sur [https://sourceforge.net/ SourceForge] dans ce document, c'est pour pouvoir donner des exemples concrets et parce qu'il s'adresse en priorité aux personnes souhaitant compiler FlightGear ; or les dépôts concernés, essentiellement [https://sourceforge.net/p/flightgear/simgear/ci/next/tree/ SimGear], [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/ FlightGear] et [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData], sont tous situés chez SourceForge.
 
<ol type="a">
  <li>Créez un compte sur SourceForge [https://sourceforge.net/user/registration ici] si vous n'en avez pas déjà un. Pour la suite, nous supposerons que le nom d'utilisateur associé à ce compte (le ''login'') est ''username''.
  </li>
  <li>Générez une paire de clés ssh.
 
Sur votre Linux en utilisateur normal (on va dire que votre nom d'utilisateur est <tt>toto</tt>), lancez le programme <tt>ssh-keygen</tt> du package openssh-client :
 
<pre>$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/toto/.ssh/id_rsa):
Created directory '/home/toto/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/toto/.ssh/id_rsa.
Your public key has been saved in /home/toto/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:p7fJx8tKBv1G92BOGxaE4sCbOd6Pu2UoydyPz5DG7wc toto@machine
The key's randomart image is:
+---[RSA 4096]----+
|      .    ..  |
|        o . ..  |
|        * .  .  |
|        =..    . |
|      .Soo . B  |
|      o.B.=E* = |
|        * @+=.o .|
|        B.&+ .  |
|          OBOo  |
+----[SHA256]-----+
$
</pre>
 
(Le choix des options <code>-t rsa</code> et <code>-b 4096</code> passées à <tt>ssh-keygen</tt> dépend des connaissances publiques actuelles en cryptanalyse... Il faudra sans doute supprimer ces options ou les adapter dans quelques années, si/quand les clés RSA longues de 4096 bits seront considérées comme non sûres.)
 
Vous disposez désormais d'une paire de clés associées situées dans le répertoire <tt>/home/toto/.ssh</tt>, utilisables avec la suite de logiciels OpenSSH (notamment avec <tt>ssh</tt>, <tt>ssh-add</tt> et <tt>ssh-agent</tt>). L'une est appelée publique, l'autre privée, et elles sont associées : ce qui est chiffré par l'une ne peut être déchiffré que par l'autre, dans l'état actuel des connaissances. C'est ce que l'on appelle la [https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique cryptographie asymétrique], par opposition à la [https://fr.wikipedia.org/wiki/Cryptographie_sym%C3%A9trique cryptographie symétrique], où la même clé est utilisée pour chiffrer et pour déchiffrer un message.
 
Il ne faut jamais envoyer la clé privée sur Internet : dans le cas qui nous concerne (authentification avec <tt>ssh</tt>), elle joue le rôle d'un mot de passe particulièrement costaud. Par sécurité au cas où quelqu'un vous volerait votre ordinateur ou s'introduirait dedans à distance, la clé privée est elle-même protégée par un mot de passe : celui que vous a demandé <tt>ssh-keygen</tt> ci-dessus (<tt>ssh</tt> l'appelle “passphrase”, autrement dit « phrase de passe », et vous suggère ce faisant de choisir quelque chose d'assez long). La clé publique, en revanche, peut être divulguée à un tiers sans que cela présente de risque, sauf bien sûr bug majeur dans <tt>ssh</tt> ou si l'on découvrait une manière de « casser » les algorithmes cryptographiques utilisés. Nous allons d'ailleurs communiquer notre clé publique au site SourceForge, ce qui nous permettra de nous authentifier grâce à la clé privée associée ''sans la communiquer à quiconque'', simplement grâce à un calcul faisant intervenir la clé privée (pas de panique, <tt>ssh</tt> s'occupe de tout !).
 
Si vous avez utilisé la commande <tt>ssh-keygen</tt> ci-dessus, votre clé privée fraîchement générée se trouve a priori dans le fichier <tt>/home/toto/.ssh/id_rsa</tt>, et la clé publique associée dans le fichier <tt>/home/toto/.ssh/id_rsa.pub</tt>. Cette dernière ressemble à ceci :
  <pre>ssh-rsa AAAAB3Nza...neeEw== toto@machine</pre>
Le <tt>toto@machine</tt> est un commentaire ajouté automatiquement ; il peut aider à s'y retrouver quand on a plein de clés publiques, mais je vous conseille de ne pas l'inclure si vous communiquez votre clé publique à quelqu'un, par exemple à SourceForge, puisqu'il révèle votre nom d'utilisateur local ainsi que celui de votre ordinateur. Si, en revanche, vous copiez la clé publique sur une machine de votre réseau local à la maison, laisser le commentaire en place est nettement moins problématique (les seules personnes pouvant exploiter les renseignements présents dans le commentaire auraient nécessairement déjà un accès à une de vos machines).
  </li>
  <li>Copiez votre clé SSH publique sur SourceForge comme suit.
<ul>
<li>Allez dans votre espace personnel sur [https://sourceforge.net/ SourceForge].</li>
<li>Cliquez sur ''Account Settings'' dans la liste déroulante ''Me'' (ou ''Moi'') en haut à droite.</li>
<li>Cliquez sur ''SSH Settings''.</li>
<li>Dans la zone de texte en face de ''SSH Public Keys'', faites un copier/coller de votre clé publique (c'est-à-dire du contenu de <tt>/home/toto/.ssh/id_rsa.pub</tt> à l'exception du commentaire final du type <tt>toto@machine</tt>). Autrement dit, dans mon exemple ci-dessus, il s'agit de coller une seule longue ligne de la forme <pre>ssh-rsa AAAAB3Nza...neeEw==</pre>
</li>
<li>Il est possible d'uploader plusieurs clés publiques de cette façon en en mettant une par ligne.</li>
<li>Cliquez sur ''Save''.</li>
</ul>
  </li>
  <li>Vous pouvez désormais vous authentifier auprès de SourceForge avec le nom ''username'' de votre compte SourceForge, grâce à la clé privée contenue dans <tt>/home/toto/.ssh/id_rsa</tt>. Ceci fonctionne car SourceForge dispose maintenant de la partie publique de cette paire de clés et sait que cette clé appartient à ''username''.
 
{{Note|Il n'est pas nécessaire de préciser quelle clé on utilise avec cette méthode. Quand le client SSH tente d'établir une connexion avec un ordinateur qui fait tourner le serveur SSH, il envoie au serveur la liste des clés publiques à sa disposition — sauf si votre configuration SSH l'interdit. Si le serveur reconnaît une des clés autorisées par une procédure telle que ce que nous avons fait au point c), il répond au client : « OK, cette clé publique, je la connais ; prouve-moi que tu as la clé privée associée » (cela s'appelle un “challenge”). Il s'agit pour le client de chiffrer un certain paquet d'octets choisi par le serveur, avec la fameuse clé privée. Le client s'exécute, envoie le paquet sous forme chiffrée, le serveur le déchiffre (il le peut car il a la clé publique) et compare le résultat à ce qu'il avait demandé. Simple comme bonjour, n'est-ce pas ? :-)
 
Si vous avez bien suivi, n'importe qui disposant de la clé publique pouvait déchiffrer le paquet envoyé par le client, mais seul quelqu'un possédant la clé privée pouvait préparer le paquet sous cette forme — dans l'état actuel des connaissances publiques. En fait, ce qu'a fait le client ici, c'est ce qu'on appelle une ''signature numérique'' du paquet d'octets choisi par le serveur. Si l'on avait chiffré avec la clé publique, seule la clé privée permettrait de déchiffrer le message : dans ce cas, ce serait un véritable chiffrement et non une signature. Mais les opérations mathématiques sont ''a priori'' les mêmes ; on choisit simplement la clé utilisée en premier — publique ou privée — en fonction de l'usage souhaité.}}
 
{{Note|Si vous souhaitez utiliser cette méthode, appelée ''public key authentication,'' pour vous connecter par SSH à un serveur quelconque sur lequel vous avez un compte, vous pouvez ajouter votre clé publique au fichier <tt>~/.ssh/authorized_keys</tt> dans votre compte sur le serveur, avec des permissions du genre -rw------- (mettre une clé par ligne). Le programme <tt>ssh-copy-id</tt> peut être utilisé pour automatiser ce genre d'opération. L'étape c) ci-dessus revient à faire cela pour votre compte chez SourceForge.}}
 
Lorsqu'un client SSH utilise ainsi une paire de clés (publique, privée) pour s'authentifier auprès d'un serveur SSH, on voit en principe une invitation à entrer la “passphrase” que vous avez donnée ci-dessus à <tt>ssh-keygen</tt> et qui protège votre clé privée. Cette demande peut apparaître dans le terminal depuis lequel le client SSH a été appelé (par exemple avec une commande telle que <code>git clone ssh://...</code>) ou bien dans une fenêtre graphique qui apparaît au moment opportun (voir ci-dessous). En tout état de cause, cette demande de mot de passe, ou “passphrase”, doit provenir de '''votre''' ordinateur, et la “passphrase” '''ne sort pas''' de votre ordinateur ; elle sert juste à ce que <tt>ssh</tt> puisse déverrouiller votre clé privée et s'en servir, sans la transmettre, pour prouver au serveur SSH (situé chez SourceForge en ce qui nous concerne ici) que vous êtes bien en possession de la clé privée correspondant à la clé publique uploadée à l'étape c).
  </li>
  <li>Il est temps de faire les premiers tests. Par exemple :</p>
 
cd /tmp
git clone ssh://''username''@git.code.sf.net/p/flightgear/fgmeta
 
(j'ai choisi [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ fgmeta] parce que c'est assez petit)
 
Vous devriez voir un message de ce genre :
 
  <pre>The authenticity of host 'git.code.sf.net (216.105.38.16)' can't be established.
ECDSA key fingerprint is SHA256:FeVkoYYBjuQzb5QVAgm3BkmeN5TTgL2qfmqz9tCPRL4.
Are you sure you want to continue connecting (yes/no)?</pre>
 
Votre client SSH vous prévient qu'il ne peut pas garantir que le serveur en face (ici, se présentant comme git.code.sf.net) est bien celui que vous voulez. Il se pourrait qu'un attaquant bien placé ait répondu à sa place et se fasse passer pour le « vrai » git.code.sf.net. Bon. Heureusement, on peut s'en sortir sans passer par la prière. Ouvrez dans votre navigateur préféré la [https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/#fingerprint-listing page chez SourceForge qui donne les empreintes numériques des machines accessibles au public], vérifiez que le cadenas indique bien une connexion sécurisée et que l'empreinte ''(fingerprint)'' de la clé mentionnée dans le message ci-dessus est bien celle d'un serveur de SourceForge ayant un nom DNS suivant le motif <tt>*.code.sf.net</tt>. En clair, avec le message ci-dessus, il faut vérifier que la page indiquée liste bien un hash de type SHA-256 égal à <tt>FeVkoYYBjuQzb5QVAgm3BkmeN5TTgL2qfmqz9tCPRL4</tt> pour <tt>*.code.sf.net</tt>. Si c'est le cas, tout va bien, répondez <tt>yes</tt>. Sinon, répondez <tt>no</tt> et lisez le paragraphe [https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/#ssh-host-key-verification ''SSH Host Key Verification''] de la même page.
 
Dans la suite, nous supposerons qu'il n'y a pas eu de problème et que vous avez donc répondu <tt>yes</tt>. Ceci implique que SSH va mémoriser l'empreinte du serveur dans le fichier <tt>~/.ssh/known_hosts</tt>. La question précedente ne vous sera donc plus posée tant que le même serveur renverra la même clé pour se présenter. Mais si un jour vous vous reconnectez au même serveur SSH et que celui-ci s'annonce avec une empreinte différente, SSH va vous prévenir qu'il y a danger à poursuivre la connexion. En effet, un tel évènement pourrait signifier que quelqu'un essaie de se faire passer pour le serveur auquel vous souhaitez vous connecter, mais n'en possède pas la clé privée. SSH et la cryptographie asymétrique fournissent donc une protection efficace contre ce type d'attaque. En pareil cas, on peut se reporter à la [https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/#fingerprint-listing page déjà mentionnée]... en espérant qu'elle n'a pas été piratée. Bref, la situation, si elle se produit, doit appeler à une grande vigilance.
  </li>
  <li>Si vous avez été rapide à valider l'empreinte du serveur à l'étape e), vous devez avoir un clone de [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ fgmeta] tout neuf dans <tt>/tmp</tt>. Sinon, il suffit de relancer la commande</p>
 
git clone ssh://''username''@git.code.sf.net/p/flightgear/fgmeta
 
<p>Comme l'empreinte du serveur est désormais connue de votre client SSH, cela devrait passer comme une lettre à la poste. SSH va juste vous demander la “passphrase” pour déverrouiller votre clé privée, comme je l'ai expliqué au point d). C'est celle que vous avez donnée à <tt>ssh-keygen</tt> lorsque vous avez généré votre paire de clés.</p>
  </li>
  <li>Reprenons : vous pouvez cloner un dépôt Git depuis SourceForge avec le protocole SSH. On aurait sans doute pu faire cela sans la paire de clés, avec un « simple » mot de passe, mais il y a trois avantages à utiliser l'authentification par clé publique comme nous venons de faire :
 
<ul>
<li>Votre clé privée est équivalente à un très gros mot de passe, que vous seriez sans doute incapable de mémoriser.</li>
 
<li>Vous ne la transmettez jamais à SourceForge ni aucun tiers. Le système ''challenge-response'' permet de prouver que vous avez la clé sans la transmettre. Il est toujours préférable, lorsque c'est possible, de ne pas donner de mot de passe à des tiers (de toute façon, vous n'utilisez pas le même mot de passe pour des sites différents, n'est-ce pas ?).</li>
 
<li>Lorsqu'on s'authentifie par mot de passe, chaque commande qui contacte le serveur, telle que <code>git clone</code>, <code>git pull</code> ou <code>git fetch</code>, nécessite d'entrer le mot de passe. Vu le nombre de dépôts qu'il faut mettre à jour avec FlightGear ([https://sourceforge.net/p/flightgear/simgear/ci/next/tree/ SimGear], [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/ FlightGear], [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData] et éventuellement [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/ FGAddon]), ce n'est pas pratique du tout. Mais nous allons voir qu'avec l'authentification par clé publique, l'agent SSH permet de n'entrer qu'un mot de passe, une fois pour toutes, jusqu'à ce que vous le terminiez (par exemple, par fermeture de la session) ou jusqu'à expiration d'un “timeout”, si vous utilisez <tt>ssh-agent</tt> et avez choisi l'option correspondante.</li>
</ul>
  </li>
  <li>'''Introduction à l'agent SSH'''
 
    <p>L'agent SSH est un programme dont le rôle est de garder en mémoire les clés que vous lui confiez et de les passer à <tt>ssh</tt> à chaque fois que nécessaire. Le projet [https://www.openssh.com/ OpenSSH] comporte un agent appelé <tt>ssh-agent</tt> ; il est sans doute déjà installé sur votre ordinateur si vous avez <tt>ssh</tt>.</p>
 
    <p>Lorsqu'une clé (privée) est confiée à l'agent, on vous demande la “passphrase” nécessaire pour la déverrouiller, de la même façon qu'au point d) ci-dessus. La clé privée déverrouillée est alors gardée en mémoire par l'agent. Tant que l'agent SSH fonctionne et a votre clé privée, il est possible de se connecter à un serveur SSH (par exemple avec une commande du type <code>git clone ssh://...</code>) au moyen de cette clé sans avoir à entrer la “passphrase” qui la protège.</p>
 
    <p>Le fait que la clé privée soit stockée sous forme déverrouillée en mémoire RAM n'est pas vraiment un problème, car pour qu'un individu malveillant puisse la lire dans l'espace mémoire du processus correspondant à l'agent SSH, il faudrait qu'il soit déjà installé dans votre compte, auquel cas c'est GAME OVER. Reste le fait que la mémoire vive peut être copiée vers la zone de swap en principe, et donc sur un disque dur. Mais ce problème ne se pose pas ''a priori'' pour <tt>ssh-agent</tt>, car il prend des mesures spécifiques pour que la clé ne se retrouve pas en zone de swap. J'espère que les autres agents SSH font de même.</p>
 
<p>Pour qu'un processus puisse bénéficier de l'agent SSH, il faut qu'il voie dans son environnement une variable lui permettant de communiquer avec l'agent ; il s'agit de la variable <tt>SSH_AUTH_SOCK</tt>. Pour la mettre en place, il y a plusieurs manières de procéder. Comme l'agent SSH est souvent lancé d'office au début de la session graphique X11 afin que tous les programmes de la session graphique puissent en bénéficier<ref name="remarque-agent-ssh-lancé-en-début-de-session-graphique">Ceci car les variables d'environnement d'un processus sont, sauf indication contraire, transmises à ses processus fils.</ref>, on peut commencer par regarder s'il n'est pas déjà lancé chez vous. Je vous propose de lancer la commande suivante afin d'examiner le contenu de la variable d'environnement <tt>SSH_AUTH_SOCK</tt> :</p>
 
<pre>$ env | grep SSH_AUTH_SOCK
SSH_AUTH_SOCK=/home/toto/.cache/keyring-TRIOXN/ssh
$
</pre>
 
<ul>
  <li>Si vous obtenez une ligne de ce genre, vous avez a priori déjà un agent SSH disponible pour toto.
  </li>
  <li>Si cette commande ne renvoie rien, vous n'avez aucun agent SSH disponible pour toto. Nous allons voir dans un instant comment en activer un : allez directement au point (i) dans ce cas.
  </li>
</ul>
 
À partir d'ici, nous nous plaçons dans l'hypothèse où la variable d'environnement <tt>SSH_AUTH_SOCK</tt> est positionnée et non vide, c'est-à-dire dans le premier cas ci-dessus. Cette variable indique à tout processus comment contacter l'agent SSH, qu'il s'agisse du programme <tt>ssh-agent</tt> de la suite OpenSSH ou d'un logiciel compatible tel que le composant <tt>ssh</tt> de <tt>gnome-keyring-daemon</tt>. Nous allons justement essayer de savoir quel est le programme qui joue ce rôle sur votre système. Pour cela, assurons-nous déjà qu'il est activé, en lançant par exemple :
 
<ul>
  <li>En tant que toto (votre compte utilisateur normal) :
    <pre>$ echo "$SSH_AUTH_SOCK"
/home/toto/.cache/keyring-TRIOXN/ssh
$</pre>
  </li>
  <li>En tant que super utilisateur (root) :
  <pre># fuser /home/toto/.cache/keyring-TRIOXN/ssh
/home/toto/.cache/keyring-TRIOXN/ssh:  8825
#</pre>
  </li>
</ul>
 
La socket <tt>/home/toto/.cache/keyring-TRIOXN/ssh</tt> (valeur de <tt>SSH_AUTH_SOCK</tt>) a donc été ouverte par le processus dont l'identifiant (PID) est 8825. Cherchons maintenant qui est ce processus :
 
En tant que toto :
<pre>$ ps -eo pid,cmd | grep -Ee '^ *8825 +'
8825 /usr/bin/gnome-keyring-daemon --daemonize --login
$</pre>
 
Ici, le processus de PID 8825 qui a ouvert la socket dont le nom est contenu dans la variable d'environnement <tt>SSH_AUTH_SOCK</tt> est donc <tt>gnome-keyring-daemon</tt>. C'est lui qui, sur le système utilisé pour cet exemple, joue le rôle de l'agent SSH. Si le programme jouant le rôle d'agent SSH avait été <tt>ssh-agent</tt>, on aurait trouvé <tt>ssh-agent</tt> dans la sortie de la commande <code>ps -eo pid,cmd | grep -Ee '^ *8825 +'</code> ci-dessus. On obtient notamment quelque chose comme ceci lorsque <tt>ssh-agent</tt> est lancé par <tt>/etc/X11/Xsession.d/90x11-common_ssh-agent</tt> grâce à l'option <code>use-ssh-agent</code> du fichier <tt>/etc/X11/Xsession.d/Xsession.options</tt> :
 
<pre>$ ps -eo pid,cmd | grep -Ee '^ *8825 +'
8825 /usr/bin/ssh-agent /usr/bin/im-launch x-session-manager
$</pre>
 
Avec ce qui précède, vous devez être en mesure de déterminer si vous disposez sur votre compte d'un agent SSH (programme offrant un service compatible avec <tt>ssh-agent</tt> sur la socket indiquée par <tt>SSH_AUTH_SOCK</tt>) et, le cas échéant, si ce service est fourni par le programme <tt>ssh-agent</tt> qui vient avec [https://www.openssh.com/ OpenSSH] ou par <tt>gnome-keyring-daemon</tt>. Notez qu'il existe d'autres programmes fournissant un tel service, par exemple GnuPG Agent si l'on active l'option correspondante ; on en trouvera quelques-uns sur le [https://wiki.archlinux.org/index.php/SSH_keys#SSH_agents wiki d'Arch Linux].
  </li>
  <li>'''Comment lancer un agent SSH ?'''
 
    <p>Cette étape présente plusieurs façons de lancer un agent SSH tel que le programme <tt>ssh-agent</tt> ou celui fourni par <tt>gnome-keyring-daemon</tt>. Si l'étape précédente vous a permis d'établir qu'il y en a déjà un pour votre compte utilisateur normal, vous pouvez passer à l'étape suivante.</p>
 
    <p>Sous Debian, le programme <tt>ssh-agent</tt> est automatiquement lancé au démarrage d'une session graphique X11 si le paquet <tt>openssh-client</tt> est installé et l'option <code>use-ssh-agent</code> n'est pas commentée dans <tt>/etc/X11/Xsession.d/Xsession.options</tt> ; pensez à relancer la session graphique si vous venez juste d'activer l'option. Cette manière de procéder s'applique à tous les utilisateurs dès lors qu'ils travaillent dans une session graphique. L'agent SSH lancé de cette manière est le programme <tt>ssh-agent</tt> livré avec OpenSSH.</p>
 
<p>Comme indiqué plus haut, GNOME Keyring fournit aussi un composant qui peut jouer le rôle d'agent SSH. On peut l'activer sous XFCE en allant dans le menu XFCE, puis ''Settings'' → ''Session and startup,'' onglet ''Advanced,'' et enfin cocher ''Launch GNOME services on startup.'' Il semble que cette méthode ait priorité sur la précédente lorsque les deux sont simultanément actives, peut-être car dans ce cas, c'est <tt>gnome-keyring-daemon</tt> qui est lancé en dernier et impose donc la valeur finale de <tt>SSH_AUTH_SOCK</tt>, qui permet de le contacter. Il y a certainement des méthodes similaires pour les environnements de bureau autres que XFCE.</p>
 
{{Note|Certaines personnes [https://askubuntu.com/questions/412793/xubuntu-stop-gnome-keyring-daemon-from-impersonating-ssh-agent bricolent] pour lancer <tt>gnome-keyring-daemon</tt> sans le composant qui offre le service d'agent SSH, car ils souhaitent vraiment utiliser le programme <tt>ssh-agent</tt> d'OpenSSH. L'intention me semble tout à fait légitime, mais les bricolages en question n'ont pas l'air très jolis... Il y a une [https://wiki.archlinux.org/index.php/GNOME/Keyring#Disable_keyring_daemon_components autre méthode] donnée sur le wiki d'Arch Linux. Je précise que je n'ai testé aucune de ces méthodes.}}
 
Citons enfin deux autres manières plus artisanales mais tout aussi valables de lancer un agent SSH, en l'occurrence <tt>ssh-agent</tt>. La première consiste à passer une commande en argument à <tt>ssh-agent</tt>. Par exemple, si l'on exécute la commande suivante dans un terminal :
 
Remplacez <tt>bash</tt> par votre shell préféré (a priori, <tt>$SHELL</tt>) :
<pre>$ ssh-agent bash</pre>
 
on obtient un nouveau shell supervisé par <tt>ssh-agent</tt>, dans lequel les variables <tt>SSH_AUTH_SOCK</tt> est positionnée comme il faut pour contacter l'agent (on dispose aussi de <tt>SSH_AGENT_PID</tt> pour trouver son PID). Toute commande lancée depuis ce nouveau shell bénéficie de la présence de l'agent. On peut terminer ce nouveau shell et l'agent avec <code>exit</code> ou en faisant Ctrl-D en début de ligne dans le nouveau shell.
 
La deuxième manière « artisanale » de lancer <tt>ssh-agent</tt> consiste à exécuter l'une des commandes suivantes dans un shell :
 
<pre>eval $(ssh-agent -s)  # pour un shell de type Bourne (Bash, Zsh...)</pre>
ou
<pre>eval $(ssh-agent -c)  # pour un shell dérivé de csh</pre>
 
Contrairement à la méthode précédente, celle-ci ne crée pas de nouveau shell : elle se contente de lancer <tt>ssh-agent</tt> et de positionner les variables d'environnement <tt>SSH_AUTH_SOCK</tt> et <tt>SSH_AGENT_PID</tt> de sorte que tout programme lancé depuis le shell où vous avez exécuté l'une des deux commandes <code>eval</code> ci-dessus soit en mesure de contacter l'agent SSH.
  </li>
  <li>'''Utilisation de <tt>ssh-add</tt> et de l'agent SSH pour se faciliter la vie'''</p>
 
<p>Vous savez maintenant comment lancer un agent SSH. Dans ce qui suit, je suppose qu'il s'agit soit de <tt>ssh-agent</tt>, soit de l'agent SSH fourni par
<tt>gnome-keyring-daemon</tt>. Dans un cas comme dans l'autre, la variable d'environnement <tt>SSH_AUTH_SOCK</tt> doit avoir une valeur non vide (faire
<code>echo $SSH_AUTH_SOCK</code> dans un terminal). Si ce n'est pas le cas, retournez à l'étape précédente.</p>
 
<ol type="1">
  <li><p>Premier cas : l'agent SSH est <tt>gnome-keyring-daemon</tt></p>
 
    <p>Le fonctionnement est assez simple : si vous lancez une commande faisant appel à un client SSH et si l'authentification peut se faire avec une clé privée que <tt>gnome-keyring-daemon</tt> « voit » (fichiers <tt>id_</tt>''algo'' et <tt>id_</tt>''algo''<tt>.pub</tt> présents dans <tt>~/.ssh/</tt>, je suppose), alors l'agent SSH procédera automatiquement à l'authentification grâce à cette clé, en vous demandant la “passphrase” nécessaire pour déverrouiller la clé, si cela n'a pas déjà été fait. Tant que <tt>gnome-keyring-daemon</tt> n'est pas arrêté, d'autres connexions peuvent être établies avec des serveurs SSH sans qu'aucune “passphrase” ne soit pas demandée, à condition que l'authentification auprès de ces serveurs puisse se faire avec une clé déjà déverrouillée. Lorsqu'une “passphrase” est demandée, cela se passe dans une fenêtre “pop-up” graphique, pas dans un terminal — contrairement à ce qui se passe avec la configuration par défaut de <tt>ssh-agent</tt>.</p>
 
    <p>Vous pouvez tester cela en lançant des commandes telles que</p>
 
git clone ssh://''username''@git.code.sf.net/p/flightgear/fgmeta
 
    <p>et les autres indiquées ci-dessous (pour celle-ci, placez-vous dans un répertoire temporaire car vous allez récupérer un clone de [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ FGMeta] dans le répertoire courant).</p>
    </li>
 
  <li><p>Deuxième cas : l'agent SSH est <tt>ssh-agent</tt></p>
 
<p>Plaçons-nous donc dans un shell sous sa supervision (la commande <code>env | grep SSH_</code> doit montrer que les variables d'environnement <tt>SSH_AUTH_SOCK</tt> et <tt>SSH_AGENT_PID</tt> sont positionnées et non vides). Lancez la commande suivante :</p>
 
<pre>$ ssh-add -l
The agent has no identities.
$</pre>
 
Cela signifie que l'agent SSH est là mais qu'on ne lui a pas encore confié de clé. Transmettons-lui notre clé SSH privée (il faut entrer la “passphrase” pour la déverrouiller), puis relançons <code>ssh-add -l</code> :
 
<pre>$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/toto/.ssh/id_rsa:
Identity added: /home/toto/.ssh/id_rsa (toto@machine)
$ ssh-add -l
4096 SHA256:p7fJx8tKBv1G92BOGxaE4sCbOd6Pu2UoydyPz5DG7wc toto@machine (RSA)
$</pre>
 
Ceci confirme que <tt>ssh-agent</tt> est désormais en possession d'une clé dont <tt>ssh-add</tt> nous précise la taille en nombre de bits, le type et l'empreinte.
 
{{Note|On peut se contenter de lancer <tt>ssh-add</tt> sans argument : il essaie alors d'ajouter les clés éventuellement contenues dans <tt>~/.ssh/id_rsa</tt>, <tt>~/.ssh/id_dsa</tt>, <tt>~/.ssh/id_ecdsa</tt> et <tt>~/.ssh/id_ed255190</tt>.}}
 
{{tip|Une différence notoire avec le cas où l'agent SSH est <tt>gnome-keyring-daemon</tt> est qu'ici, on a dû utiliser <tt>ssh-add</tt> pour confier la clé à l'agent (cela se fait automatiquement lorsque l'agent SSH est <tt>gnome-keyring-daemon</tt>). Avec une ligne telle que <code>AddKeysToAgent yes</code> dans <tt>~/.ssh/config</tt>, il est possible de faire en sorte que <tt>ssh</tt> ajoute automatiquement chaque clé utilisée à <tt>ssh-agent</tt>, comme cela se passe avec <tt>gnome-keyring-daemon</tt>. Il y a également d'autres possibilités de configuration avec ce paramètre, qui peut prendre chacune des valeurs <code>yes</code>, <code>confirm</code>, <code>ask</code> et <code>no</code> (voir la page de manuel <tt>ssh_config(5)</tt>).}}
 
Voilà, c'est terminé. Depuis n'importe quel shell s'exécutant sous la supervision de l'agent SSH, vous pouvez désormais lancer n'importe quelle commande faisant appel à un client SSH : si l'authentification peut se faire avec une clé privée que vous avez confiée à l'agent, la connexion sera établie sans qu'il soit nécessaire d'entrer un quelconque mot de passe. Depuis un tel shell, vous pouvez donc lancer des commandes utilisant l'authentification par SSH, par exemple :
 
Pour télécharger un clone de [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ FGMeta] dans le répertoire courant :</p>
 
git clone ssh://''username''@git.code.sf.net/p/flightgear/fgmeta
 
Pour cloner [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData] avec le protocole SSH, à supposer que <tt>download_and_compile.sh</tt> ne l'ait pas encore cloné ici (sinon, il va simplement mettre à jour FGData en utilisant le protocole indiqué dans <tt>install/flightgear/fgdata/.git/config</tt>, qui n'est pas forcément SSH) :
download_and_compile.sh --git-clone-site-params=SourceForge=ssh:''username'' DATA
 
Même chose pour les trois dépôts [https://sourceforge.net/p/flightgear/simgear/ci/next/tree/ SimGear], [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/ FlightGear] et [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData] correspondant aux arguments optionnels <code>SIMGEAR</code>, <code>FGFS</code> et <code>DATA</code> de <tt>download_and_compile.sh</tt>. Vous pouvez mettre en place un alias ou un mini-script pour ne pas vous embêter à retenir l'option un peu longue.
download_and_compile.sh --git-clone-site-params=SourceForge=ssh:''username''
 
Pour obtenir de l'aide relative à la commande suivante (voir le [https://sourceforge.net/p/forge/documentation/Shell%20Service/ service ''shell'' de SourceForge]) :
ssh ''username''@shell.sourceforge.net
 
Pour démarrer un shell chez SourceForge :
ssh -t ''username''@shell.sourceforge.net create
 
Il est possible de « reprendre » des clés confiées à <tt>ssh-agent</tt> avec les options <code>-d</code> et <code>-D</code> de <tt>ssh-add</tt>. L'option <code>-t</code> de <tt>ssh-agent</tt> permet, quant à elle, de spécifier une durée maximale de rétention des clés par l'agent (un ''timeout,'' d'où le nom de l'option). De toute façon, la rétention des clés sous forme déverrouillée par <tt>ssh-agent</tt> se passe exclusivement en mémoire RAM ; du fait de l'utilisation de <tt>mlock(2)</tt>, la ou les pages mémoire concernées ne peuvent être envoyées dans la zone de swap. Les clés sont retirées à l'agent lorsqu'il est terminé, en particulier lorsque que vous arrêtez ou redémarrez votre ordinateur (où même seulement la session graphique, si c'est elle qui lance l'agent dans votre configuration).
</ol>
  </li>
</ol>
 
== Références ==
<references/>
Rominet
377

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/117529"

Navigation menu