Skip to content

Commit

Permalink
Move Git SSH setup to pre-course-setup
Browse files Browse the repository at this point in the history
  • Loading branch information
fasterius committed Nov 3, 2023
1 parent e476812 commit 231deca
Show file tree
Hide file tree
Showing 2 changed files with 56 additions and 51 deletions.
61 changes: 55 additions & 6 deletions pages/course-information/pre-course-setup.md
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@ resources:
> then add `nameserver 8.8.8.8` to the bottom of the file and save it.
> **Important!** <br>
> 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
Expand Down Expand Up @@ -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** <br>
> 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?
Expand All @@ -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
Expand Down Expand Up @@ -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
```
Expand All @@ -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** <br>
Expand Down Expand Up @@ -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*.
Expand Down
46 changes: 1 addition & 45 deletions pages/git/git-7-working-remotely.md
Original file line number Diff line number Diff line change
Expand Up @@ -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** <br>
> 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:
Expand Down Expand Up @@ -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**.
Expand Down

0 comments on commit 231deca

Please sign in to comment.