As developers, we have to maintain multiple credentials to authenticate and sign our code changes before pushing to remote. This is used to be simple: just use the https endpoint offered by the remote git repository provider, authenticate with our email and password and call it a day. However, now a-day, git remote providers are moving to enforcing SSH authentication which provides a host of benefits out of the scope of discussion for this blog. On this one, we are focusing on how can we leverage git conditionals and ssh to manage our credentials.

The Old

Image you have created your public and private key pair and configured the ~/.ssh/config  file to map your private key to the ssh host of your git provider.

Host ssh.gitlab.env-1

  PreferredAuthentications publickey
  IdentityFile ~/.ssh/internal-gitlab
  AddKeysToAgent yes
  UseKeychain yes

We then move to configuring our ~/gitconfig file to tell git to use SSH as the signing key and authentication key for our repo.

[gpg]
  format = ssh
  
[user]

  name = James S. Abreu Mieses
  email = [email protected]
  signingkey = /Users/abreuj/.ssh/internal-gitlab.pub

[core]

  editor = neovim
  excludesfile = /Users/abreuj/.gitignore_global

[commit]

  gpgsign = true
  template = /Users/abreuj/.stCommitMsg

...

It looks great if we are simply pushing to a single repository and nothing else. With this configuration we will be able to both authenticate and sign our commits.

But, what if we have a second repo to push to? Or maybe a third? How would we manage this? We would have to repeat the steps of generating our key pairs and add the private key and ssh domain to the ~/.ssh/config file.

Host ssh.gitlab.env-1

  PreferredAuthentications publickey
  IdentityFile ~/.ssh/internal-gitlab
  AddKeysToAgent yes
  UseKeychain yes



Host ssh.github.com

  PreferredAuthentications publickey
  IdentityFile ~/.ssh/personal-github
  AddKeysToAgent yes
  UseKeychain yes

Easy. Now, You will be able to push to the new repo under the ssh.github.com host. Which is great for authentication. For commit signatures on the other hand, this will not work because we have already configured our git identity to use internal-gitlab.pub for commit signatures. So the commits pushed to the github repo will end up being unverified which means the signature is not trusted.

The initial option here is to again configure the ~/.gitconfig file to use the personal-github.pub private key for signatures. This will work, but when we go back to pushing changes to the gitlab repo, we will go back to having the commit signature not be verified by the provider. So now what?

Use Git Conditional

To solve this issue of having to manually configure our git identity to use the correct public key to sign our commits, we can use git' includeIf to load an identity based on some condition. Here is an example using our initial config:

[gpg]
  format = ssh
  
[user]

  name = James S. Abreu Mieses
  email = [email protected]
  signingkey = /Users/abreuj/.ssh/internal-gitlab.pub

[core]

  editor = neovim
  excludesfile = /Users/abreuj/.gitignore_global

[commit]

  gpgsign = true
  template = /Users/abreuj/.stCommitMsg

[includeIf "hasconfig:remote.*.url:[email protected]:*/**"]
    path=~/path/to/github-iden

On the new config, we are including the git includeIf telling git to load the github-iden config if the repository we are in has a remote url under the ssh.github.com host. If this is not the case, continue using the default identity.

[user]

    name=James S. Abreu Mieses
    email=[email protected]
    signingkey=/Users/abreuj/.ssh/personal-gitlab.pub

For here on, we will be able to authenticate and sign our commits using the correct credentials for the repository we are trying to deploy.

Conclusion

Git conditionals are a game changer when it comes to automating identity selection for a give repository. Hopefully you find this article and git conditions as awesome as I did.