Making Life with Git Easier

Avoid repeating your password

Normally, you have to enter your username and password every time you interact with the server. This can be very tedious, particularly when working with many repositories. Git offers credential management to make this more comfortable. Here, we will present a simple setup that avoids entering your password over and over again. If you are interested to learn more details, you can read further at https://git-scm.com/docs/gitcredentials.

The downside to the particularly simple setup we present here, is that the credentials are stored in clear text in your home directory. If your permission setup is less than strict, this increases the risk of a security exposure. To mitigate this, we will not be using your normal password, but a so-called Personal Access Token.

Warning

You may be tempted to try and use ssh together with ssh keys, however, this is not supported at the moment. Due to the way the platform is set up, you must use https. Generally, this offers a good level of security and avoids a few common pitfalls associated with the use of ssh, such as hampered access due to firewall rules and proxies, or the reuse of keys on different machines.

Personal Access Tokens

A Personal Access Token (PAT) works like an alternative password, that is, whenever you are asked for the password to your server account, you can provide the PAT instead. This mitigates the risk of a security exposure with two features. First, while you have only one password, you can create as many PATs as you want and you should use this to avoid re-use. This way, it is painless to deactivate and replace a PAT should it ever become compromised. Second, while your password enables you to use all the features of the server, you can limit what any individual PAT permits. This way, you can have a PAT that only allows you to read repositories, for example to deploy the code to a low security HPC that is not used for development, but not to change your profile details on the server.

Creating a PAT

To maximize security, and because you are expected to use one PAT only for one use-case, you can read the PAT only during the process of creation. Once the web page is closed, you can not get the same PAT again from the server. Of course, you can always create a new one, so it is not a huge problem, but keep this in mind as we reach the end of this section.

To create a PAT, log in to the server at https://git.smhi.se, then click on your profile menu (the small icon in the top-right corner), and then click on Edit profile as shown in Fig. 8

Edit profile

Fig. 8 The profile menu allows you to access all user settings which also permits you to creating PATs.

This brings you to the User Settings page shown in Fig. 9.

User settings

Fig. 9 The user settings page gives you access to a lot of functionality of the Gitlab platform related to your account. Here, we focus on the creation of PATs, highlighted in red. Feel free to explore the other settings in your profile.

Clicking on Access Tokens in the column on the left as highlighted in Fig. 9 takes you to the Personal Access Tokens page. Here you can create a new token by giving it a name and choosing an expiration date as well as the required permissions.

Giving an expiration date is another layer of security: Breaking a password or, equivalently, a PAT takes computational effort and time. By using a time limit, we can make it very difficult to achieve this while the access is still valid. It also means that a compromised method of access will cease to function even if undetected. Hence, limiting the time of validity is considered best practice in security circles. However, this has to be balanced with the inconvenience of recreating tokens every now and then. At the moment, we don’t have an official policy on expiration dates.

Likewise, selecting the minimum set of permissions necessary protects unauthorized access to other functionality. Unless you know for certain otherwise, there is no need to activate api, read_user, or read_api scopes. If you need only read access for this token, for example if it is designated for a HPC platform that will not be used for development, read_repository is the appropriate scope. If you want to use this token to participate in the development of EC-Earth, please use write_repository (which automatically includes reading rights) instead. This recommended configuration is shown in Fig. 10.

PAT creation

Fig. 10 Via User Settings, you can create as many PATs as you like. Choose an arbitrary name that will help you identify the purpose of this token and select the minimum permissions needed for the purpose at hand.

Once you are happy with name, expiration date, and scope, click on Create personal access token (highlighted in Fig. 10). This will give you your new PAT near the top of the page

Showing of new PAT

Fig. 11 The only time you can access a PAT in the web interface is at the time of creation. It is shown to you in the highlighted text box from where you can copy it. You can either select and copy it like any other text, or you can use the little clipboard icon on the right side of that text box, which will automatically copy the token for you.

That concludes the creation of the PAT.

Revoking a PAT

If you don’t need a PAT anymore, you can revoke it, effectively removing it from the server, rendering it unusable. To do that, navigate again to the Personal Access Tokens page shown in Fig. 10. Then scroll down until you find the list of existing PATs. There, you have a red Revoke button for every PAT. Just click on that to revoke the token.

Git credential store

To avoid having to type your password over and over again, you can use the support for credentials built into git.

Note

Using automatic handling of credentials is balancing security with convenience. Git offers three levels. At the most basic, you have to enter your credentials every time you interact with the server in a privileged operation. Slightly more comfortable is caching, in which you have to enter your credentials only once per session, which means that the credentials are never stored to disk by git. At the other end of the spectrum, git stores the credentials permanently for you. This offers the most convenience, but also creates the largest risk to compromise your credentials. In most contexts, all three options are acceptable.

There are many ways to configure credential handling. If you are working with Git on your local computer, you should consider using your local system password wallet or keychain. If you are working on a remote HPC, it is often convenient to use Git’s credential store. For that, execute the following:

git config --global credential.helper store

The next time you need the credentials, you will still be asked for them, but from that moment forward, git will use the stored credentials automatically. This approach is best combined with a Personal Access Token (PAT) as described in Personal Access Tokens.