Gitlab in S[UW][12] labs

User guide

Step 1 - SSH Key Preparation

Run the PuTTYgen application from the Windows start menu. Generate a key (the default RSA 2048-bit mode shall be sufficient).

Export the generated private key in the OpenSSH format (Conversions -> Export OpenSSH key) into Y:\keys\id_rsa.

Copy the public key from the PuTTygen window and register it in the web interface of gitlab.mff.cuni.cz (User Settings / SSH Keys).

Step 2 - Batch File Preparation

For each repository you want to work with, prepare a Windows batch file stored at Y:, e.g. clone_repo.cmd, with the following contents:

git -c core.sshCommand="ssh -i y:/keys/id_rsa" clone <repository-ssh-url> c:\Users\student\source\repos\<local-repository-name>
c:
cd c:\Users\student\source\repos\<local-repository-name>
git config core.sshCommand "ssh -i y:/keys/id_rsa"
git config user.name "<your-name>"
git config user.email "<your-email>"

Example:

git -c core.sshCommand="ssh -i y:/keys/id_rsa" clone git@gitlab.mff.cuni.cz:teaching/nprg041/bednarek/cv.git c:\Users\student\source\repos\bednarek-cv
c:
cd c:\Users\student\source\repos\bednarek-cv
git config core.sshCommand "ssh -i y:/keys/id_rsa"
git config user.name "David Bednarek"
git config user.email "david.bednarek@matfyz.cuni.cz"

Step 3 - Cloning the repository

Clone the repository by invoking Y:\clone_repo.cmd.

After cloning, open the folder c:\Users\student\source\repos\<local-repository-name> with Visual Studio.

Further repository operations like pull, commit, push etc. may be performed by the git functions of Visual Studio.

Don't forget to commit and push the local repository back to gitlab before leaving. You may also want to erase the local repository if you want to hide your work from other users.

If you (or anybody else) did not erase the local repository, you may continue work with the local repository on your next logon. You may want to verify (by checking git status) whether your local repo was not accidentaly or intentionally altered. If you find alterations, rollback the changes and return to the last commit pushed to gitlab.

Motivation

Although the Windows computers in labs authenticate users by their SIS credentials, all such authenticated users share the same Windows account student. Consequently, all students share the same settings and local files, located in c:\Users\student.

Therefore, it is completely unsafe to store any passwords or keys in the default locations defined by Windows.

In order to partially mitigate this non-safety, a part of user settings is automatically cleared upon each logon. The use of this part of settings for sensitive information is moderately safe; however, it implies reentering of this information after every logon. Consequently, it is unusable for non-human-readable information like ssh keys.

The only storage locations that are safe and persistent are the two personal folders mapped at Y: and Z:

However, a local repository can not be stored on Y: or Z: because the underlying unix/windows conversion hides the .git folders required by the git functionality in Visual Studio (although command-line git works). In addition, the network drives are too slow for storing the temporary files needed by Visual Studio.

Gitlab use

Accessing gitlab via HTTP works with usernames and passwords. Windows git clients tend to store the usernames and passwords at least temporarily, which is unsafe in the shared environment of labs.

Accessing gitlab via SSH requires a SSH key which must be stored in a persistent personal location, i.e. at Y: or Z:. Command-line git clients (including the git support in Visual Studio and Visual Studio Code) use command-line ssh clients which, by default, read the keys from $HOME/.ssh, i.e. c:\Users\student\.ssh. Overriding the key location is possible through the git config; however, the git configuration is stored at these three locations:

• system - unreachable for non-administrators
• global - $HOME/.gitconfig, i.e. c:\Users\student\.gitconfig, effectively shared by all students
• local - inside a local repository, non-existent during clone operations

Principles of the solution

The approach tries to avoid any configuration stored at C:.

The ssh key is stored at Y: (avoiding y:\.ssh because this folder would be invisible in Explorer).

PuTTYgen is used because the command-line ssh-keygen is not in PATH.

The use of y:/keys/id_rsa is enforced by setting the core.sshCommand configuration entry of git.

The batch does the following:

• The repository is cloned with core.sshCommand specified explicitly in the command-line.
• For further operations with the local repository, the same core.sshCommand is stored into the local config of the repository.
• For convenience, the batch also sets the user name and email required by git for commits.

The local repository shall be commited and pushed into gitlab before logging off from the Windows.

The contents of c:\Users\student\source\repos (which is the default folder for Visual Studio projects) is not cleared upon Windows logoff or logon. It is thus likely that the student will find the local repository on their next logon.

Although the local repository may be modified (including commits) by someone else between the logons by the owner, the owner is the only user that can push the commits to gitlab because the corresponding ssh key is located at Y: and thus accessible only to the owner. Therefore, the owner can always detect and rollback any unwanted changes using the gitlab repository.