|
From: Florent R. <f.r...@fr...> - 2018-09-26 11:14:54
|
Based on all the positive feedback, I've pushed an improved version of these changes to 'next', plus a few more (addressing previous requests seen here: FGData is now fetched before FlightGear and the latter built with -DFG_DATA_DIR=..., missing dependencies added...). For details on the main change, see: https://sourceforge.net/p/flightgear/fgmeta/ci/8a7fd33b2b4bf48f267c260bccf8ea638b2b8961/ Basically, download_and_compile.sh offers two new options, --git-clone-default-proto and --git-clone-site-params, to let you choose how to clone Git repositories. --git-clone-default-proto is for changing the default protocol (which is still https) whereas --git-clone-site-params is more specific, in that it allows one to give a specific protocol, and optionally username, for all repositories located at a given hosting site (currently, we only have GitHub and SourceForge among the hosting sites used by download_and_compile.sh with 'git clone'). Of course, --git-clone-site-params overrides --git-clone-default-proto for hosting sites that match, and both override the default 'https' protocol. Example: assuming people only have problems downloading FGData with https, they can do, in a brand new empty directory: # Secure, but you need to have created a 'johndoe' account at # SourceForge before (see below for details) download_and_compile.sh --git-clone-site-params=SourceForge=ssh:johndoe DATA or # Unencrypted, unauthenticated, therefore insecure unless you check # the obtained last-commit id (even then, as cryptographic knowledge # evolves, I wouldn't guarantee anything about that for years to # come). download_and_compile.sh --git-clone-default-proto=git DATA # This would also do the same, since DATA (FGData) is obtained from # SourceForge: download_and_compile.sh --git-clone-site-params=SourceForge=git DATA Then, you can clone the rest using the default https protocol, or specify it explicitly: download_and_compile.sh --git-clone-default-proto=https These options only affect the 'git clone' operation. That is why the last command here won't change the protocol used when updating your FGData clone, that was specified above when it was cloned. This means you don't have to reclone your repositories from scratch to change the protocol they use: just edit .git/config under the repository root and change stuff like: [remote "origin"] # Or url = https://git.code.sf.net/p/flightgear/fgdata url = ssh://johndoe@git.code.sf.net/p/flightgear/fgdata Subsequent operations such as 'git pull', 'git fetch', etc., will use the new protocol. In order to use SSH, you need an account at the hosting site. But at least for SourceForge (not sure about GitHub), you don't need write permissions in order to just pull from the repositories. Therefore, this does solve, in my experience, the problem several people have had to clone FGData in a secure way. Creating an account at SourceForge is free. That said, for each SSH-using repository, you'll be asked for the password, unless you use ssh-agent or an equivalent. Setting up ssh-agent is not difficult. You first need to create a keypair as explained at: https://wiki.debian.org/SSH#Using_shared_keys (and probably many, many other sites). Basically, just type: ssh-keygen under your normal user account and answer the questions. You'll obtain a (public + private) key pair: ~/.ssh/id_rsa.pub (public part of the key) ~/.ssh/id_rsa (private part of the key) (there may be something else than 'rsa' depending on the default for ssh-keygen's -t option, which you can use to force the key type, as in 'ssh-keygen -t rsa'. This is the main cryptographic algorithm used by the key pair). The private key is normally protected by a passphrase (password), so that people getting access to your files without your consent (robbers, attackers, etc.) can't use it to connect to various sites for which you declared “this is my key and it can be used authentication”. That said, never upload the private key to SourceForge, etc. This must stay on *your* computer. Using the dedicated user account interfaces at SourceForge (also GitHub and others), you can upload your *public* key. For SourceForge, see “SSH Key Posting” at: https://sourceforge.net/p/forge/documentation/SSH%20Keys/ (you may want to read the rest for background info) Once this is done, you can connect to SourceForge with SSH in order to clone, push or pull from/to a repo, using your key pair instead of your SourceForge-user password. The key pair normally takes precedence, therefore if you've correctly uploaded your public key, you should get a prompt *for the key passphrase* (as opposed to your SourceForge account password) when an SSH operation with SourceForge requires you to prove that you are indeed the owner of the private key corresponding to the pulic key you uploaded using their dedicated interface. Now, typing the key passphrase every time it is needed may be annoying, depending on the workflow. That is where ssh-agent comes into play. If you simply start a process supervised by the agent, as in: ssh-agent bash or ssh-agent zsh then for the whole duration of the supervised process, your passphrase will only have to be entered once for each key (yes, one may have several SSH keys), unless expiration measures decide otherwise. This is one of the manual ways to start the agent, but people often get it to start automatically when they log in on their system. In my case, I've done it long ago, that's maybe the uncommented line: use-ssh-agent in /etc/X11/Xsession.options that does the job. Otherwise, I see there is a checkbox reading “SSH Key Agent (GNOME Keyring: SSH Agent)” in XFCE's Session and Startup -> Application Autostart tab. It's unchecked for me, so clearly not required. And from the name, I can't tell whether it is GNOME-specific or not. I suppose the job is done for me by the aforementioned 'use-ssh-agent' line in /etc/X11/Xsession.options. With this[1], you don't have to start ssh-agent manually, and automatically get prompted when connecting to a site where one of your SSH keys could be used for authentication. Moreover, the agent remembers the key passphrase(s) as long as it is alive—or earlier if it is configured to do expiration[2]—that's his job. For completeness, GnuPG also has an agent that can theoretically act as the SSH agent (never tried it this way, though). See also the Debian wiki about ssh-add and ssh-agent: https://wiki.debian.org/SSH#ssh-agent_and_ssh-add Regards [1] Maybe you'll want to install ssh-askpass too or similar, for a nicer user experience. [2] gpg-agent can do expiration, and also ssh-add which can be used inside a process supervised by ssh-agent to enter the passphrase for a key in advance, in order to avoid a future prompt for this key. See [3] for the -t (timeout) option of ssh-add. [3] https://unix.stackexchange.com/a/122656 -- Florent |