Organizing Git Access per Customer with 1Password SSH Agent

As consultants, we must juggle multiple credentials, including those from Xebia. But we are also onboarded at the customers where we are hired for our assignments. I already blogged on how I separate my browser sessions for different clients. This gives me the ability to have relevant bookmarks for my assignment. This blog will continue to explain how I organize my git access and separate them per customer.

Password management

Since I work with various customers, I store all my credentials in a password manager. I am using 1Password, and 1Password has an awesome feature called SSH Agent. With this functionality, you can store your private SSH keys in 1Password and use them when you pull or push code to a remote repository over SSH.

I create an SSH key per customer in my 1Password vault. Once created, I configure the public key in the customer's repository system. (example: GitHub/GitLab/BitBucket) I set both an authentication and a signing key, so I upload the same key twice.

I also create a file ~/.ssh/my-customer.pub that contains the public key; this file instructs SSH on which identity to use. Since we also uploaded a signing key, I will add the public key to the ~/.git/allowed_signers file.

joris.conijn@my-customer.com ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The only downside here is that the key must be stored in your main vault. I always create customer-specific vaults, and the 1Password agent can only use the main vault.

More information on 1Password Agents and how to configure them with GitHub.

Git Configuration

Next is the git configuration. This section has three parts. The first two parts are something that you need to set up per customer. The other part is something you need to set up just once.

First, we will create the git configuration that will be used for this customer. I create a file per customer in the following location: ~/.git/gitconfig-my-customer. This file has the following content:

[user]
    name = Joris Conijn
    email = joris.conijn@my-customer.com
    signingkey = ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[gpg]
  format = ssh
[gpg "ssh"]
  program = "/Applications/1Password.app/Contents/MacOS/op-ssh-sign"
[commit]
  gpgsign = true

The user definition in this file will be used to commit the code. In this example, the user is Joris Conijn, and the email address is joris.conijn@my-company.com. This ensures that you commit your code with the entity known in the customer's environment.

Use your own public key as the signing key and make sure that the 1Password path also matches your system. Next, for each customer, you will need to set the following in the ~/.gitconfig file:

[includeIf "gitdir:~/workspace/my-customer/"]
    path = ~/.git/gitconfig-my-customer
[url "git@my-customer:my-org/“]
        insteadOf = "git@github.com:my-org/"

I need to explain a few things here. The first part ensures that any Git repository in the ~/workspace/my-customer/ path uses the configuration defined in ~/.git/gitconfig-my-customer.

The second part will transform the git@github.com:my-org/my-repo.git to git@my-customer:my-org/my-repo.git. Now this is actually the secret sauce; the domain used is not a valid domain. It is just the name of the customer, and it will not resolve to the github.com servers just yet.

The one-time setup required is to configure the ~/.git/allowed_signers file for use. You can do this by adding the following snippet to the ~/.gitconfig file:

[gpg "ssh"]
    allowedSignersFile = ~/.git/allowed_signers

This will configure the list of allowed_signers in git so that the git cli tooling shows valid signatures.

SSH Configuration

We are almost done; next up is the SSH configuration itself. We now need to update the ~/.ssh/config file:

Host my-customer
    HostName github.com
    User git
    IdentityFile ~/.ssh/my-customer.pub
    IdentitiesOnly yes

What we are doing here is the following. We define a host called my-customer and overwrite the hostname with github.com. This ensures that GitHub servers are used again, and we point to our customer-specific configuration. The primary reason for this virtual hostname is that you can only define SSH configurations on hostnames, not URI paths.

Conclusion

Managing multiple customer environments as a consultant can easily become messy if credentials and Git configurations overlap. By leveraging 1Password’s SSH Agent and a structured Git and SSH setup, you can keep your projects securely isolated while maintaining a smooth developer experience. This approach ensures professional separation, clear commit histories, and effortless switching between customer contexts.

Photo by Myburgh Roux