From 231decab205486637274cb11ca8fc83873ac6ee0 Mon Sep 17 00:00:00 2001 From: Erik Fasterius Date: Fri, 3 Nov 2023 17:38:10 +0100 Subject: [PATCH] Move Git SSH setup to pre-course-setup --- pages/course-information/pre-course-setup.md | 61 ++++++++++++++++++-- pages/git/git-7-working-remotely.md | 46 +-------------- 2 files changed, 56 insertions(+), 51 deletions(-) diff --git a/pages/course-information/pre-course-setup.md b/pages/course-information/pre-course-setup.md index 13b117c9..3e66586c 100644 --- a/pages/course-information/pre-course-setup.md +++ b/pages/course-information/pre-course-setup.md @@ -61,7 +61,7 @@ resources: > then add `nameserver 8.8.8.8` to the bottom of the file and save it. > **Important!**
-> Whenever a setup instruction specifies Mac or Linux (*i.e.* only those two, with no alternative for Windows), +> Whenever a setup instruction specifies Mac or Linux (*i.e.* only those two, with no alternative for Windows), > **please follow the Linux instructions.** Open a bash shell Linux terminal and clone the GitHub repository containing all @@ -147,6 +147,55 @@ below for more information. > Locate the version box in the bottom right corner of the website and > select the corresponding version. +### GitHub setup + +[GitHub](https://github.com) is one of several online hosting platforms for Git +repositories. We'll go through the details regarding how Git and GitHub are +connected in the course itself, so for now we'll stick to setting up your +account and credentials. + +If you have not done so already, go to [github.com](https://github.com/join) and +create an account. You can also create an account on another online hosting +service for version control, *e.g.* [Bitbucket](https://bitbucket.org) or +[GitLab](https://about.gitlab.com/). The exercises in this course are written +with examples from GitHub (as that is the most popular platform with the most +extensive features), but the same thing can be done on alternative services, +although the exact menu structure and link placements differ. + +Any upload to and from GitHub requires you to authenticate yourself. GitHub +used to allow authentication with your account and password, but this is no +longer the case - using SSH keys is required instead. Knowing exactly what these +are is not necessary to get them working, but we encourage you to read the box +below to learn more about them! GitHub has excellent, platform-specific +instructions both on how to [generate](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) +and [add](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) +SSH keys to your account, so please follow those instructions. + +> **SSH keys and authentication**
+> Using SSH (Secure Shell) for authentication basically entails setting up a +> pair of keys: one private and one public. You keep the private key on your +> local computer and give the public key to anywhere you want to be able to +> connect to, *e.g.* GitHub. The public key can be used to encrypt messages that +> *only* the corresponding private key can decrypt. A simplified description of +> how SSH authentication works goes like this: +> +> 1. The client (*i.e.* the local computer) sends the ID of the SSH key pair it +> would like to use for authentication to the server (*e.g.* GitHub) +> 2. If that ID is found, the server generates a random number and encrypts this +> with the public key and sends it back to the client +> 3. The client decrypts the random number with the private key and sends it +> back to the server +> +> Notice that the private key always remains on the client's side and is never +> transferred over the connection; the ability to decrypt messages encrypted +> with the public key is enough to ascertain the client's authenticity. This is +> in contrast with using passwords, which are themselves sent across a +> connection (albeit encrypted). It is also important to note that even though +> the keys come in pairs it is impossible to derive the private key from the +> public key. If you want to read more details about how SSH authentication work +> you can check out [this website](https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process), +> which has more in-depth information than we provide here. + ## Installing Mamba ### Mamba or Conda? @@ -171,8 +220,8 @@ this is not too confusing. ### If you already have Mamba installed -If you already have installed Mamba you can make sure you're using the latest -version by running `mamba update -n base mamba` and skip the installation +If you already have installed Mamba you can make sure you're using the latest +version by running `mamba update -n base mamba` and skip the installation instructions below. ### If you have Conda installed @@ -210,7 +259,7 @@ rm Mambaforge-MacOSX-arm64.sh ```bash # Install Mambaforge3 for 64-bit Linux -curl -L https://github.com/conda-forge/miniforge/releases/latest/download/Mambaforge-Linux-x86_64.sh -O +curl -L https://github.com/conda-forge/miniforge/releases/latest/download/Mambaforge-Linux-x86_64.sh -O bash Mambaforge-Linux-x86_64.sh rm Mambaforge-Linux-x86_64.sh ``` @@ -233,7 +282,7 @@ mamba --version > The Mamba docs specify a couple of things to keep in mind when using Mamba. > First of all, `mamba` should be installed in the `base` environment and no > other packages should be installed into `base`. Furthermore, mixing of the -> `conda-forge` and `defaults` channels should be avoided as the default +> `conda-forge` and `defaults` channels should be avoided as the default > Anaconda channels are incompatible with `conda-forge`. > **Different Mambas/Condas**
@@ -446,7 +495,7 @@ the Docker icon in the menu bar in the upper right part of the screen. ### Linux -Go to the [linux-install](https://docs.docker.com/desktop/install/linux-install/) +Go to the [linux-install](https://docs.docker.com/desktop/install/linux-install/) section of the Docker documentation and make sure that your computer meets the system requirements. There you can also find instructions for different Linux distributions in the left sidebar under *Installation per Linux distro*. diff --git a/pages/git/git-7-working-remotely.md b/pages/git/git-7-working-remotely.md index a1d36f09..70cf3815 100644 --- a/pages/git/git-7-working-remotely.md +++ b/pages/git/git-7-working-remotely.md @@ -12,50 +12,6 @@ version control system) and online hosting of *Git repositories* (such as GitHub): the former is the core of keeping track of your code's history, while the latter is how to store and share that history with others. -## GitHub setup - -If you have not done so already, go to [github.com](https://github.com/join) -and create an account. You can also create an account on another online hosting -service for version control, *e.g.* [Bitbucket](https://bitbucket.org) or -[GitLab](https://about.gitlab.com/). The exercises below are written with -examples from GitHub (as that is the most popular platform with the most -extensive features), but the same thing can be done on alternative services, -although the exact menu structure and link placements differ a bit. - -Any upload to and from GitHub requires you to authenticate yourself. GitHub -used to allow authentication with your account and password, but this is no -longer the case - using SSH keys is favoured instead. Knowing exactly what these -are is not necessary to get them working, but we encourage you to read the box -below to learn more about them! GitHub has excellent, platform-specific -instructions both on how to [generate](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) -and [add](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) -SSH keys to your account, so please use them before moving on! - -> **SSH keys and authentication**
-> Using SSH (Secure Shell) for authentication basically entails setting up a -> pair of keys: one private and one public. You keep the private key on your -> local computer and give the public key to anywhere you want to be able to -> connect to, *e.g.* GitHub. The public key can be used to encrypt messages that -> *only* the corresponding private key can decrypt. A simplified description of -> how SSH authentication works goes like this: -> -> 1. The client (*i.e.* the local computer) sends the ID of the SSH key pair it -> would like to use for authentication to the server (*e.g.* GitHub) -> 2. If that ID is found, the server generates a random number and encrypts this -> with the public key and sends it back to the client -> 3. The client decrypts the random number with the private key and sends it -> back to the server -> -> Notice that the private key always remains on the client's side and is never -> transferred over the connection; the ability to decrypt messages encrypted -> with the public key is enough to ascertain the client's authenticity. This is -> in contrast with using passwords, which are themselves sent across a -> connection (albeit encrypted). It is also important to note that even though -> the keys come in pairs it is impossible to derive the private key from the -> public key. If you want to read more details about how SSH authentication work -> you can check out [this website](https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process), -> which has more in-depth information than we provide here. - ## Create a remote repository Log in to your GitHub account and press the *New* button: @@ -104,7 +60,7 @@ On branch main nothing to commit, working tree clean ``` -You always need to specify `git push origin main` by default, but you can +You always need to specify `git push origin main` by default, but you can circumvent this by telling Git that you always want to push to `origin/main` when you're on your local `main` branch. To do this, use the command `git branch --set-upstream-to origin/main`. **Try it out now**.