Git

Git: From SSH to Personal Access Tokens

Michael Mikhailidi

• 2 min read
Git: From SSH to Personal Access Tokens
Photo by Frederik Merten / Unsplash

I used SSH protocol for years to access remote repositories on-premises and remotely. It's a convenient, reliable, and secure way to sync your local and remote repositories. However, architectural changes and security requirements encourage moving from SSH  to HTTPS/TLS protocols, sometimes in a rush way.

For command line riders, it means that  SSH keys are not in use, and you should provide credentials to access the Source Control Management (SCM) system over HTTPS and how you will manage them. SCM vendors unanimously introduced personal access tokens (PAT) as an alternative to your username/password. Switching to PAT gives you plenty of benefits, such as:

  • Reduce the risk of losing your credentials;
  • You can manage your tokens w/o interfere with the regular password management policies;
  • Tokens have expiration dates and could be easily revoked or rotated.
  • Tokens allow fine-grained access control by limiting access to functions and projects.
  • Tokens could be bound to the function/project rather than to users.

After the ode to PATs, let's discuss how it impacts your repository interactions.

The most secure and inconvenient way is not to store any passwords on your system, but you still need to keep them somewhere safe. There are plenty 3rd party solutions, from Windows sticky notes to CyberArk. In practice, every interaction with the remote repository will ask you for credentials.

To soften the annoyance, the Git client offers a cache credential helper. 

$ git config credential.helper 'cache --timeout=600'

The command above configures credential helper and sets the expiration time to ten minutes (600 seconds). The first git command will ask you for your credentials, and all the consequent interactions will use the cached credentials.  

On the plus side, you don't store any credentials with Git but must keep them somewhere else and enter them every time you pull or push the remote system.

For convenience and security, use system credential helpers.   This approach integrates Git with the OS secret management solutions, directly accessing your stored credentials until they expire or get revoked. Along with the OS-bounded solutions, there are third-party security managers, so you can find the one that works best for you. The most common commands are:

# Windows. Git stores in Credentials Manager/Windows Credentials
$ git config --global credential.helper manager

# MacOS. Utlizes MacOS keychain 
$ git config --global credential.helper osxkeychain

# Linux. You may want to find actual location of the library first.
# locate -b git-credential-libsecret
$ git config --global credential.helper \
/usr/lib/git-core/git-credential-libsecret

This is a controversial way to keep your PAT on the system when you need to avoid user intervention or you can't access any other credential managers. Git offers insteadOf clause to override URLs. This trick would help you in situations where The sample construct is:

$ git config --global url."https://my-token:glpat-XXXXXXXXXX@gilab.com/".insteadOf "https://gitlab.com/"

It also helps with the submodules or when you refer to other repositories, such as Ansible roles requirements.yml.