377
edits
User:Rominet: Difference between revisions
Jump to navigation
Jump to search
Use templates or wiki-links when referencing repositories of the FG project
(Use the FGMeta page and restore nobreak spaces (copy/paste from the edit form in FireFox replaces them by normal spaces!!)) |
(Use templates or wiki-links when referencing repositories of the FG project) |
||
| Line 1: | Line 1: | ||
Most end-users will probably be interested in the procedure described below, that can be used to clone a Git repository such as [ | Most end-users will probably be interested in the procedure described below, that can be used to clone a Git repository such as [[FGData]] using the SSH protocol and modify a single file so that future updates of the repository are done with the HTTPS protocol. To this date, this is the easiest way, as far as I know, to retrieve FGData in a secure and reliable way (probably because of (1) its sheer size as compared to the other repositories of the FlightGear project, and (2) some technical problems in the SourceForge Git infrastructure; other repositories can be cloned with HTTPS without any problem). This procedure is explained [[#using-download-and-compile-sh-to-build-flightgear|in full detail in English]] and [[#alternate-method-clone-with-ssh-and-update-with-https|more summarily in French]]. | ||
Users who are willing to take the time to read moderately technical explanations may be interested in the [[#tutorial-on-ssh-public-key-authentication-and-ssh-agent|tutorial on creating a pair of SSH keys, setting up an SSH agent and using it to do all Git transfers with the SSH protocol]] (in French). This is an alternate method, is quite secure and convenient when set up, but requires users to understand a few technical points regarding SSH public key authentication. They are all explained below, though, for those who are prepared to read carefully. | Users who are willing to take the time to read moderately technical explanations may be interested in the [[#tutorial-on-ssh-public-key-authentication-and-ssh-agent|tutorial on creating a pair of SSH keys, setting up an SSH agent and using it to do all Git transfers with the SSH protocol]] (in French). This is an alternate method, is quite secure and convenient when set up, but requires users to understand a few technical points regarding SSH public key authentication. They are all explained below, though, for those who are prepared to read carefully. | ||
| Line 15: | Line 15: | ||
Pros and cons of each of these protocols: | Pros and cons of each of these protocols: | ||
* With the old <tt>git</tt> protocol, data is '''not encrypted''' and there is '''no authentication''' to guarantee that the remote computer is really the one you intended to contact. This implies in particular that malicious actors who can intercept and inject packets between your computer and the legitimate server can make you download what ''they'' want, instead of what the legitimate server would normally have sent (this is called a ''man-in-the-middle attack).'' This risk is partially mitigated in the particular case of Git, at the condition that after every update performed using the unsafe <tt>git</tt> protocol, you double-check from a known-good source that the last commit identifier you got for each branch of the downloaded repository is the same as on the legitimate server. Needless to say, nobody does that. Besides, the SHA-1 algorithm that Git uses to compute commit identifiers has been somewhat weakened during the last years<ref name="Google-work-on-SHA-1">See for instance this [https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html Google report].</ref>; therefore, even if it's not the case at the time of this writing, one can't dismiss the possibility that at some point in the future, “bad guys” might be able to prepare malicious commits having the same identifier as one of the commits of the legitimate repository. For these reasons (especially the possibility of a man-in-the-middle attack), it is a good idea to avoid using the obsolete <tt>git</tt> protocol. In other words, don't use <tt>git://</tt> when you clone a Git repository. | * With the old <tt>git</tt> protocol, data is '''not encrypted''' and there is '''no authentication''' to guarantee that the remote computer is really the one you intended to contact. This implies in particular that malicious actors who can intercept and inject packets between your computer and the legitimate server can make you download what ''they'' want, instead of what the legitimate server would normally have sent (this is called a ''man-in-the-middle attack).'' This risk is partially mitigated in the particular case of Git, at the condition that after every update performed using the unsafe <tt>git</tt> protocol, you double-check from a known-good source that the last commit identifier you got for each branch of the downloaded repository is the same as on the legitimate server. Needless to say, nobody does that. Besides, the SHA-1 algorithm that Git uses to compute commit identifiers has been somewhat weakened during the last years<ref name="Google-work-on-SHA-1">See for instance this [https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html Google report].</ref>; therefore, even if it's not the case at the time of this writing, one can't dismiss the possibility that at some point in the future, “bad guys” might be able to prepare malicious commits having the same identifier as one of the commits of the legitimate repository. For these reasons (especially the possibility of a man-in-the-middle attack), it is a good idea to avoid using the obsolete <tt>git</tt> protocol. In other words, don't use <tt>git://</tt> when you clone a Git repository. | ||
* With the <tt>https</tt> protocol, all transferred data is '''encrypted''' and, more importantly here, the server you connect to is '''authenticated.''' The main problem here is that this protocol is not well implemented at [https://sourceforge.net/ SourceForge]: cloning a large repository such as [ | * With the <tt>https</tt> protocol, all transferred data is '''encrypted''' and, more importantly here, the server you connect to is '''authenticated.''' The main problem here is that this protocol is not well implemented at [https://sourceforge.net/ SourceForge]: cloning a large repository such as [[FGData]] using <tt>https</tt> (almost?) always fails. As far as I know, this problem doesn't happen with smaller repositories, nor does it happen when simply updating a large one that has already been cloned (it is indeed possible to clone a repository with a given protocol and later update it using another protocol; all one has to do for that is to modify the <tt>.git/config</tt> file inside the repository—this is precisely the method we are going to describe next, step by step). | ||
* With the <tt>ssh</tt> protocol, all transferred data is '''encrypted''' and the server you connect to is '''authenticated''' (this is done differently, but offers similar guarantees as the <tt>https</tt> protocol). The main problem in this case, which is generally a minor one, is that in order to download via the <tt>ssh</tt> protocol, you have to authenticate ''yourself'' to the server (in contrast with <tt>https</tt>, which allows anonymous downloads). This requires you to either enter a password or to use a (public, private) pair of SSH keys—the latter method being called ''public key authentication.'' On the other hand, getting yourself authenticated to the server is an advantage for development, because this allows server administrators to possibly grant you write access to the repository, should you be able and willing to contribute to the project (i.e., administrators could then allow you to run commands such as <code>git push</code> that update the remote repository). | * With the <tt>ssh</tt> protocol, all transferred data is '''encrypted''' and the server you connect to is '''authenticated''' (this is done differently, but offers similar guarantees as the <tt>https</tt> protocol). The main problem in this case, which is generally a minor one, is that in order to download via the <tt>ssh</tt> protocol, you have to authenticate ''yourself'' to the server (in contrast with <tt>https</tt>, which allows anonymous downloads). This requires you to either enter a password or to use a (public, private) pair of SSH keys—the latter method being called ''public key authentication.'' On the other hand, getting yourself authenticated to the server is an advantage for development, because this allows server administrators to possibly grant you write access to the repository, should you be able and willing to contribute to the project (i.e., administrators could then allow you to run commands such as <code>git push</code> that update the remote repository). | ||
When <tt>download_and_compile.sh</tt> clones a new repository, it uses by default the <tt>https</tt> protocol. This works fine except for [ | When <tt>download_and_compile.sh</tt> clones a new repository, it uses by default the <tt>https</tt> protocol. This works fine except for [[FGData]], for the reasons we have just explained (very large repository, transfer problems with SourceForge). Since using the <tt>git</tt> protocol is not an acceptable solution either, I recommend to clone the FGData repository using the <tt>ssh</tt> protocol. FGData can then be updated using <tt>https</tt>, and other repositories can be cloned as well as updated using <tt>https</tt>. The next section will explain step by step how to do that. | ||
Another option is to use the <tt>ssh</tt> protocol in all cases. If you use an SSH agent in conjunction with public key authentication, this is quite a fine solution. But in case you don't, this method would require you to enter your SourceForge password every time a Git command needs to contact the remote server—assuming all repositories you work with are hosted there, which is the case for the FlightGear core repositories. Needless to say, this would be quite cumbersome unless you rarely interact with the remote server. Since setting up public key authentication requires more learning and work for users who are not already familiar with it, we are going to present the easier method here: using the <tt>ssh</tt> protocol for cloning [ | Another option is to use the <tt>ssh</tt> protocol in all cases. If you use an SSH agent in conjunction with public key authentication, this is quite a fine solution. But in case you don't, this method would require you to enter your SourceForge password every time a Git command needs to contact the remote server—assuming all repositories you work with are hosted there, which is the case for the FlightGear core repositories. Needless to say, this would be quite cumbersome unless you rarely interact with the remote server. Since setting up public key authentication requires more learning and work for users who are not already familiar with it, we are going to present the easier method here: using the <tt>ssh</tt> protocol for cloning [[FGData]] (i.e., ''only for the initial download)'' and <tt>https</tt> for all other communications initiated by the Git client on your computer. For those interested, the method based on public key authentication is explained in detail in French [[#tutorial-on-ssh-public-key-authentication-and-ssh-agent|on this very page]]. | ||
=== <span id="getting-started-with-download-and-compile-sh"></span> Getting started with <tt>download_and_compile.sh</tt> === | === <span id="getting-started-with-download-and-compile-sh"></span> Getting started with <tt>download_and_compile.sh</tt> === | ||
| Line 258: | Line 258: | ||
or | or | ||
$ download_and_compile.sh -j$(nproc) | $ download_and_compile.sh -j$(nproc) | ||
(<code>-j$(nproc)</code> is “only” useful to save time—see the tip below). If you don't pass any non-option argument to <tt>download_and_compile.sh</tt> as done here, it will take care of the three base components needed to run FlightGear: <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> (these are the component names used by <tt>download_and_compile.sh</tt>, i.e., the final arguments one can optionally give in a <tt>download_and_compile.sh</tt> command; in normal speech, they correspond to the | (<code>-j$(nproc)</code> is “only” useful to save time—see the tip below). If you don't pass any non-option argument to <tt>download_and_compile.sh</tt> as done here, it will take care of the three base components needed to run FlightGear: <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> (these are the component names used by <tt>download_and_compile.sh</tt>, i.e., the final arguments one can optionally give in a <tt>download_and_compile.sh</tt> command; in normal speech, they correspond to the {{simgear source | ||
| text = SimGear | |||
}}, {{flightgear source | |||
| text = FlightGear | |||
}} and {{fgdata source | |||
| text = FGData | |||
}} repositories). Therefore, the above command is presently exactly equivalent to: | |||
$ download_and_compile.sh SIMGEAR FGFS DATA | $ download_and_compile.sh SIMGEAR FGFS DATA | ||
| Line 274: | Line 280: | ||
==== <span id="using-download-and-compile-sh-to-update-flightgear"></span> Using <tt>download_and_compile.sh</tt> to update FlightGear ==== | ==== <span id="using-download-and-compile-sh-to-update-flightgear"></span> Using <tt>download_and_compile.sh</tt> to update FlightGear ==== | ||
Just go to the directory from which you you previously ran <tt>download_and_compile.sh</tt>. This is the folder we called ''$dir'' in the previous section which, if you did a complete run of <tt>download_and_compile.sh</tt>, contains the <tt>run_fgfs.sh</tt> executable and a log file of what <tt>download_and_compile.sh</tt> did in its last run, named <tt>compilation_log.txt</tt>. If you wish to update, say, | Just go to the directory from which you you previously ran <tt>download_and_compile.sh</tt>. This is the folder we called ''$dir'' in the previous section which, if you did a complete run of <tt>download_and_compile.sh</tt>, contains the <tt>run_fgfs.sh</tt> executable and a log file of what <tt>download_and_compile.sh</tt> did in its last run, named <tt>compilation_log.txt</tt>. If you wish to update, say, {{simgear source | ||
| text = SimGear | |||
}}, {{flightgear source | |||
| text = FlightGear | |||
}} and {{fgdata source | |||
| text = FGData | |||
}}, simply execute this: | |||
$ download_and_compile.sh -pn SIMGEAR FGFS DATA | $ download_and_compile.sh -pn SIMGEAR FGFS DATA | ||
We'll explain the <code>-pn</code> in a minute. <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> are called ''components'' in <tt>download_and_compile.sh</tt> terminology. A component generally corresponds to a software repository, or something close. In fact, since <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> are often precisely the components people wish to update, they form the default components set, so that the previous command is equivalent to: | We'll explain the <code>-pn</code> in a minute. <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> are called ''components'' in <tt>download_and_compile.sh</tt> terminology. A component generally corresponds to a software repository, or something close. In fact, since <tt>SIMGEAR</tt>, <tt>FGFS</tt> and <tt>DATA</tt> are often precisely the components people wish to update, they form the default components set, so that the previous command is equivalent to: | ||
| Line 320: | Line 332: | ||
Avantages et inconvénients des trois protocoles : | 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="fr-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 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="fr-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 [ | * 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 [[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. | * 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 [ | 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 [[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 | $ 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). | 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). | ||
| Line 329: | Line 341: | ||
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 : | 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'' | $ 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 [ | (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 [[FGData]]), il faudra entrer le mot de passe pour chaque dépôt. Vous devinez que cela devient vite pénible. '''Il est cependant possible de seulement cloner avec SSH, puis changer le protocole pour chaque dépôt cloné grâce au <tt>.git/config</tt> à l'intérieur du dépôt et ainsi faire en sorte que les mises à jour des dépôts utilisent le protocole <tt>https</tt>, qui ne nécessite ni de créer vous-même une paire de clés, ni d'entrer un mot de passe.''' Si vous êtes pressé, c'est la méthode que je conseillerais. Voir [[#alternate-method-clone-with-ssh-and-update-with-https|ci-dessous]] pour plus de détails sur cette méthode. | ||
Plutôt que d'envoyer son mot de passe SourceForge au serveur par SSH, 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. | Plutôt que d'envoyer son mot de passe SourceForge au serveur par SSH, 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. | ||
| Line 335: | Line 347: | ||
===<span id="tutorial-on-ssh-public-key-authentication-and-ssh-agent"></span> Authentification SSH par paire de clés privée/publique === | ===<span id="tutorial-on-ssh-public-key-authentication-and-ssh-agent"></span> 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 | À 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 {{simgear source | ||
| text = SimGear | |||
}}, {{flightgear source | |||
| text = FlightGear | |||
}} et {{fgdata source | |||
| text = FGData | |||
}}, sont tous situés chez SourceForge. | |||
<ol type="a"> | <ol type="a"> | ||
| Line 429: | Line 447: | ||
<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>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 ( | <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 ({{simgear source | ||
| text = SimGear | |||
}}, {{flightgear source | |||
| text = FlightGear | |||
}}, {{fgdata source | |||
| text = FGData | |||
}} et éventuellement {{fgaddon source | |||
| text = 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> | </ul> | ||
</li> | </li> | ||
| Line 558: | Line 584: | ||
$ git clone ssh://''username''@git.code.sf.net/p/flightgear/fgmeta | $ git clone ssh://''username''@git.code.sf.net/p/flightgear/fgmeta | ||
Pour cloner [ | Pour cloner [[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 | $ download_and_compile.sh --git-clone-site-params SourceForge=ssh:''username'' DATA | ||
Même chose pour les trois dépôts | Même chose pour les trois dépôts {{simgear source | ||
| text = SimGear | |||
}}, {{flightgear source | |||
| text = FlightGear | |||
}} et {{fgdata source | |||
| text = 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'' | $ download_and_compile.sh --git-clone-site-params SourceForge=ssh:''username'' | ||