377
edits
Rominet
Joined 28 January 2015
→Autre méthode : clonage avec SSH et mises à jour avec HTTPS: Simpler method for changing the protocol or URL of a Git remote
m (Fix anchors so that the parts in English look more natural when moved to an English-only page) |
(→Autre méthode : clonage avec SSH et mises à jour avec HTTPS: Simpler method for changing the protocol or URL of a Git remote) |
||
| (9 intermediate revisions by the same user not shown) | |||
| 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. | ||
== English == | == English == | ||
| 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> === | ||
The text that was temporarily here has been moved to its [[Scripted Compilation on Linux Debian/Ubuntu#getting-started-with-download-and-compile-sh|final location]] in the [[Scripted Compilation on Linux Debian/Ubuntu]] article. | |||
==== <span id="getting-started-with-download-and-compile-sh-notations"></span> Notations ==== | ==== <span id="getting-started-with-download-and-compile-sh-notations"></span> Notations ==== | ||
The text that was temporarily here has been moved to its [[Scripted Compilation on Linux Debian/Ubuntu#getting-started-with-download-and-compile-sh-notations|final location]] in the [[Scripted Compilation on Linux Debian/Ubuntu]] article. | |||
==== <span id="getting-download-and-compile-sh-the-right-way"></span> Getting <tt>download_and_compile.sh</tt> the “right way” ==== | ==== <span id="getting-download-and-compile-sh-the-right-way"></span> Getting <tt>download_and_compile.sh</tt> the “right way” ==== | ||
The text that was temporarily here has been moved to its [[Scripted Compilation on Linux Debian/Ubuntu#getting-download-and-compile-sh-using-an-fgmeta-clone|final location]] in the [[Scripted Compilation on Linux Debian/Ubuntu]] article. | |||
==== <span id="using-download-and-compile-sh-to-build-flightgear"></span> Using <tt>download_and_compile.sh</tt> to build FlightGear ==== | ==== <span id="using-download-and-compile-sh-to-build-flightgear"></span> Using <tt>download_and_compile.sh</tt> to build FlightGear ==== | ||
The text that was temporarily here has been moved to its [[Scripted Compilation on Linux Debian/Ubuntu#using-download-and-compile-sh-to-build-flightgear|final location]] in the [[Scripted Compilation on Linux Debian/Ubuntu]] article. | |||
and | |||
==== <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 ==== | ||
The text that was temporarily here has been moved to its [[Scripted Compilation on Linux Debian/Ubuntu#using-download-and-compile-sh-to-update-flightgear|final location]] in the [[Scripted Compilation on Linux Debian/Ubuntu]] article. | |||
== Français == | == Français == | ||
| Line 296: | Line 47: | ||
;authentification (authentication) | ;authentification (authentication) | ||
: Action consistant à s'assurer que la personne/le serveur/etc. | : 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) | ;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 | : 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) | ;empreinte numérique (hash, fingerprint) | ||
: Donnée numérique (c'est-à-dire qui peut être représentée par un nombre entier) servant à identifier un « objet » (un commit Git, un serveur, une clé numérique...). Il s'agit donc d'une sorte d'empreinte digitale, à ceci près qu'elle est numérique, qu'elle n'est ''a priori'' pas stockée sur les doigts et qu'elle identifie un objet à préciser, lequel n'est pas nécessairement une personne. L'identifiant d'un commit Git est une empreinte numérique obtenue à partir du contenu de ce commit (y compris de ses métadonnées, dont font partie les identifiants des commits parents). Exemple d'identifiant de commit | : Donnée numérique (c'est-à-dire qui peut être représentée par un nombre entier) servant à identifier un « objet » (un commit Git, un serveur, une clé numérique...). Il s'agit donc d'une sorte d'empreinte digitale, à ceci près qu'elle est numérique, qu'elle n'est ''a priori'' pas stockée sur les doigts et qu'elle identifie un objet à préciser, lequel n'est pas nécessairement une personne. L'identifiant d'un commit Git est une empreinte numérique obtenue à partir du contenu de ce commit (y compris de 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.] | ;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 à | : 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 === | === Motivation === | ||
Git peut utiliser divers protocoles pour communiquer avec le | 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 | ||
git clone ssh://... | git clone ssh://... | ||
ou | ou | ||
| Line 315: | Line 66: | ||
le mot précédant <tt>://</tt> indique quel protocole Git doit utiliser. | le mot précédant <tt>://</tt> indique quel protocole Git doit utiliser. | ||
Avantages et inconvénients des trois | 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 | * 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 | * 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). | ||
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 | 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 | 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. | ||
===<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 | À 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 339: | Line 96: | ||
<li>Générez une paire de clés ssh. | <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- | 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 | <pre>$ ssh-keygen -t rsa -b 4096 | ||
| Line 367: | Line 124: | ||
(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.) | (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 | 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 | 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 à | 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> | <pre>ssh-rsa AAAAB3Nza...neeEw== toto@machine</pre> | ||
Le <tt>toto@machine</tt> est un commentaire ajouté | 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> | ||
<li>Copiez votre clé SSH publique sur SourceForge comme suit. | <li>Copiez votre clé SSH publique sur SourceForge comme suit. | ||
| Line 388: | Line 145: | ||
<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''. | <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 | {{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 | 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.}} | {{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 | 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> | ||
<li>Il est temps de faire les premiers tests. Par | <li>Il est temps de faire les premiers tests. Par exemple :</p> | ||
$ cd /tmp | $ cd /tmp | ||
$ git clone ssh://''username''@git.code.sf.net/p/flightgear/fgmeta | $ git clone ssh://''username''@git.code.sf.net/p/flightgear/fgmeta | ||
(j'ai choisi [ | (j'ai choisi [[FGMeta]] parce que c'est assez petit) | ||
<span id="ssh-question-about-unknown-host-key">Vous devriez voir un message de ce | <span id="ssh-question-about-unknown-host-key">Vous devriez voir un message de ce genre :</span> | ||
<pre>The authenticity of host 'git.code.sf.net (216.105.38.16)' can't be established. | <pre>The authenticity of host 'git.code.sf.net (216.105.38.16)' can't be established. | ||
| Line 409: | Line 166: | ||
Are you sure you want to continue connecting (yes/no)?</pre> | 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 | 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 (rassurez-vous, il est quasi impossible de se retrouver dans cette situation et de ne pas s'en rendre compte : le message affiché par <tt>ssh</tt> en pareil cas est très visible et explicite !). | 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 (rassurez-vous, il est quasi impossible de se retrouver dans cette situation et de ne pas s'en rendre compte : le message affiché par <tt>ssh</tt> en pareil cas est très visible et explicite !). | ||
</li> | </li> | ||
<li>Si vous avez été rapide à valider l'empreinte du serveur à l'étape e), vous devez avoir un clone de [ | <li>Si vous avez été rapide à valider l'empreinte du serveur à l'étape e), vous devez avoir un clone de [[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 | $ git clone ssh://''username''@git.code.sf.net/p/flightgear/fgmeta | ||
| Line 419: | Line 176: | ||
<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> | <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> | ||
<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> | <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>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 | <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> | ||
<li>'''Introduction à l'agent SSH''' | <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 c'est 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>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 c'est 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>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> | ||
| Line 437: | Line 202: | ||
<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>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' | <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 | <pre>$ env | grep SSH_AUTH_SOCK | ||
| Line 446: | Line 211: | ||
<li>Si vous obtenez une ligne de ce genre, vous avez a priori déjà un agent SSH disponible pour toto. | <li>Si vous obtenez une ligne de ce genre, vous avez a priori déjà un agent SSH disponible pour toto. | ||
</li> | </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 | <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> | </li> | ||
</ul> | </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 | À 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> | <ul> | ||
<li>En tant que toto (votre compte utilisateur normal) : | <li>En tant que toto (votre compte utilisateur normal) : | ||
<pre>$ echo "$SSH_AUTH_SOCK" | <pre>$ echo "$SSH_AUTH_SOCK" | ||
/home/toto/.cache/keyring-TRIOXN/ssh | /home/toto/.cache/keyring-TRIOXN/ssh | ||
</pre> | </pre> | ||
</li> | </li> | ||
<li>En tant que super utilisateur (root) : | <li>En tant que super utilisateur (root) : | ||
<pre># fuser /home/toto/.cache/keyring-TRIOXN/ssh | <pre># fuser /home/toto/.cache/keyring-TRIOXN/ssh | ||
/home/toto/.cache/keyring-TRIOXN/ssh: 8825 | /home/toto/.cache/keyring-TRIOXN/ssh: 8825 | ||
| Line 465: | Line 230: | ||
</ul> | </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 | 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 | En tant que toto : | ||
<pre>$ ps -eo pid,cmd | grep -Ee '^ *8825 +' | <pre>$ ps -eo pid,cmd | grep -Ee '^ *8825 +' | ||
8825 /usr/bin/gnome-keyring-daemon --daemonize --login | 8825 /usr/bin/gnome-keyring-daemon --daemonize --login | ||
</pre> | </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> (sous Debian) : | 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> (sous Debian) : | ||
<pre>$ ps -eo pid,cmd | grep -Ee '^ *8825 +' | <pre>$ ps -eo pid,cmd | grep -Ee '^ *8825 +' | ||
| Line 478: | Line 243: | ||
</pre> | </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 | 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> | ||
<li>'''Comment lancer un agent | <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>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>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> | <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> | ||
| Line 490: | Line 255: | ||
{{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.}} | {{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 | 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>) : | Remplacez <tt>bash</tt> par votre shell préféré (a priori, <tt>$SHELL</tt>) : | ||
<pre>$ ssh-agent bash</pre> | <pre>$ ssh-agent bash</pre> | ||
on obtient un nouveau shell supervisé par <tt>ssh-agent</tt>, dans lequel la variable <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. | on obtient un nouveau shell supervisé par <tt>ssh-agent</tt>, dans lequel la variable <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 | 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> | <pre>$ eval $(ssh-agent -s) # pour un shell de type Bourne (Bash, Zsh...)</pre> | ||
| Line 503: | Line 268: | ||
<pre>$ eval $(ssh-agent -c) # pour un shell dérivé de csh</pre> | <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 | 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> | ||
<li>'''Utilisation de <tt>ssh-add</tt> et de l'agent SSH pour se faciliter la vie'''</p> | <li>'''Utilisation de <tt>ssh-add</tt> et de l'agent SSH pour se faciliter la vie'''</p> | ||
| Line 520: | Line 285: | ||
$ git clone ssh://''username''@git.code.sf.net/p/flightgear/fgmeta | $ 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 [ | <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 [[FGMeta]] dans le répertoire courant).</p> | ||
</li> | </li> | ||
| Line 546: | Line 311: | ||
{{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>).}} | {{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>).}} | ||
{{Note|Il est possible de | {{Note|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).}} | ||
</li> | </li> | ||
</ol> | </ol> | ||
<li>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 :</p> | <li>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 :</p> | ||
Pour télécharger un clone de [ | Pour télécharger un clone de [[FGMeta]] dans le répertoire courant :</p> | ||
$ 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'' | ||
| Line 569: | Line 340: | ||
</ol> | </ol> | ||
===<span id="alternate-method-clone-with-ssh-and-update-with-https"></span> Autre | ===<span id="alternate-method-clone-with-ssh-and-update-with-https"></span> Autre méthode : clonage avec SSH et mises à jour avec HTTPS === | ||
Voici une autre méthode pour obtenir et mettre à jour de manière sûre les dépôts avec <tt>download_and_compile.sh</tt> : | Voici une autre méthode pour obtenir et mettre à jour de manière sûre les dépôts avec <tt>download_and_compile.sh</tt> : | ||
<ol type="1"> | <ol type="1"> | ||
| Line 603: | Line 374: | ||
url = ssh://''username''@git.code.sf.net/p/flightgear/fgmeta | url = ssh://''username''@git.code.sf.net/p/flightgear/fgmeta | ||
par<br /> | par<br /> | ||
< | url = <nowiki>https://git.code.sf.net/p/flightgear/fgmeta</nowiki> | ||
([[FGMeta|fgmeta]] est pris comme exemple ici, mais vous devez bien sûr laisser le nom du dépôt tel que vous l'avez trouvé). | |||
{{Tip|Plutôt que de modifier manuellement le fichier <tt>.git/config</tt> dans chaque dépôt, on peut aussi utiliser <code>git remote set-url ''remote'' ''url''</code> à l'intérieur de chaque dépôt. Par exemple, pour FGMeta, il suffit d'aller dans le répertoire correspondant et de lancer : | |||
git remote set-url origin <nowiki>https://git.code.sf.net/p/flightgear/fgmeta</nowiki>}} | |||
</li> | </li> | ||
<li>Répétez l'opération précédente pour chaque dépôt. | <li>Répétez l'opération précédente pour chaque dépôt. | ||