How to Configure Git for Multiple SSH Keys and Signing Commits With GPG in 2026?

Working across multiple Git accounts—personal projects on GitHub, client repositories on GitLab, and enterprise code on internal servers—quickly becomes a configuration nightmare. You commit with the wrong email address, push with the wrong SSH key, or forget to sign commits with the correct GPG key. Then you spend hours fixing your commit history. I’ve been there, and I wrote this guide so you do not have to struggle through the same mistakes. In this tutorial, I will show you exactly how to configure Git for multiple SSH keys and signing commits with GPG, step by step, with real commands you can copy and paste.

Commit signing proves you actually wrote the code. When someone sees a “Verified” badge next to your commit on GitHub or GitLab, they know the commit came from you and was not spoofed by someone who got access to your repository. Organizations increasingly require signed commits for security compliance, and open-source maintainers often prefer them for contribution verification. Setting up Git to automatically select the right SSH key and signing key based on repository location saves you from constantly remembering to run git config user.email or manually specifying keys.

Prerequisites: What You Need Before You Start

Before diving into configuration, verify your Git version supports the features I will use. You need Git 2.10 or later for conditional includes (includeIf), and Git 2.34 or later if you want to use SSH keys for commit signing instead of GPG. Check your version with:

git --version

You should see output like git version 2.43.0. If you are on an older version, upgrade Git before continuing. Most modern package managers (Homebrew on macOS, apt on Ubuntu, Chocolatey on Windows) provide recent Git versions.

You also need a basic understanding of terminal commands. I will provide exact commands, but you should know how to open a terminal, navigate directories, and edit configuration files. For editing, you can use nano, vim, or your preferred text editor. The commands I show work on macOS and Linux. Windows users should use Git Bash or WSL for the best experience.

How to Configure Git for Multiple SSH Keys and Signing Commits With GPG?

Here is the complete workflow you will follow. First, you generate separate SSH keys for each account (personal, work, client). Then, you configure SSH to automatically select the correct key based on the host you are connecting to. Next, you create GPG keys for commit signing and associate each key with the appropriate account. Finally, you set up Git’s conditional configuration system to automatically apply the correct identity, SSH key, and signing key based on repository directory location.

The result: when you clone a repository into your ~/work directory, Git automatically uses your work email, work SSH key, and work GPG key. When you clone into ~/personal, Git switches to your personal identity. No manual configuration required after the initial setup.

Generating Multiple SSH Keys for Different Accounts

Start by creating separate SSH keys for each Git account. I recommend using Ed25519 keys—they are faster, more secure, and produce shorter keys than RSA. Ed25519 has been supported since OpenSSH 6.5 (released in 2026), so every modern system handles it without issues.

Generate a key for your personal account:

ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_personal

Generate a key for your work account:

ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_work

The -C flag adds a comment to help you identify the key later. The -f flag specifies the output file. Using descriptive filenames like id_ed25519_personal and id_ed25519_work prevents confusion when you have multiple keys.

When prompted, enter a strong passphrase. A passphrase adds security if someone gains access to your private key file. You can use an SSH agent to cache the passphrase so you do not have to type it repeatedly.

After generating keys, add them to your SSH agent:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_personal
ssh-add ~/.ssh/id_ed25519_work

List your loaded keys to verify:

ssh-add -l

You should see both Ed25519 keys listed with their fingerprints.

Configuring SSH Config for Multiple Hosts

The SSH config file controls which key SSH uses for each connection. By defining separate Host blocks, you can use different keys for github.com personal repositories versus github.com work repositories through URL rewriting.

Create or edit the SSH config file:

nano ~/.ssh/config

Add Host blocks for each account. The trick is using different host aliases that map to the same server but specify different identity files:

# Personal GitHub account
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes

# Work GitHub account (via alias)
Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

With this configuration, git clone [email protected]:personal/project.git uses your personal key. For work repositories, you use the alias: git clone git@github-work:company/repo.git. Both connect to GitHub, but SSH selects different keys based on the host you specify.

The IdentitiesOnly yes line ensures SSH only tries the specified identity file. Without it, SSH might try other keys from your agent or default files, which can cause authentication failures or use the wrong key.

For GitLab, add another block:

Host gitlab.com
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes

Test your configuration by connecting:

ssh -T [email protected]
ssh -T git@github-work

GitHub responds with a message like “Hi username! You’ve successfully authenticated.” If you see a different username for each connection, your SSH config works correctly.

Setting Up GPG Keys for Commit Signing

GPG keys sign commits to prove authorship. Unlike SSH keys used for authentication, GPG keys create cryptographic signatures attached to each commit. GitHub, GitLab, and other platforms verify these signatures and display “Verified” badges on signed commits.

Install GPG if you do not have it. On macOS, use Homebrew:

brew install gnupg

On Ubuntu or Debian:

sudo apt install gnupg

Generate a GPG key for commit signing. Use RSA 4096 or Ed25519:

gpg --full-generate-key

Select option 4 (RSA and RSA) and enter 4096 for key size. Alternatively, select option 9 (ECC and ECC) and choose Ed25519 for modern keys. Set expiration as appropriate—1 to 2 years is common. Enter your real name and the email address matching your Git configuration (the email you use on GitHub).

After generation, list your secret keys:

gpg --list-secret-keys --keyid-format LONG

Output looks like:

sec   rsa4096/ABC123DEF456GHI789 2024-01-15 [SC] [expires: 2026-01-15]
      DEF456GHI789JKL012MNO345PQR678STU901VWX
uid   [ultimate] Your Name <[email protected]>
ssb   rsa4096/345PQR678STU901VWX 2024-01-15 [E]

The string after sec and the slash (ABC123DEF456GHI789 in this example) is your key ID. Copy this for Git configuration.

Export your public key to add it to GitHub:

gpg --armor --export ABC123DEF456GHI789 | pbcopy

On Linux, pipe to xclip -selection clipboard instead of pbcopy. Go to GitHub Settings > SSH and GPG keys > New GPG key, paste, and save.

Repeat this process for each account (personal, work). Use different email addresses for each key to match your Git identities.

Git Configuration With Conditional Includes

Git’s conditional include system loads different configuration files based on repository location. This is the key to automatic profile switching. You create a main ~/.gitconfig with default settings, then separate files for personal and work identities that Git loads conditionally.

Edit your main Git configuration:

nano ~/.gitconfig

Add conditional includes at the end:

# Default configuration (optional)
[user]
    name = Your Name
    email = [email protected]
    signingkey = ABC123DEF456GHI789
[commit]
    gpgsign = true
[gpg]
    program = gpg

# Conditional includes for different directories
[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

[includeIf "gitdir:~/personal/"]
    path = ~/.gitconfig-personal

Now create the work configuration file:

nano ~/.gitconfig-work

Add:

[user]
    name = Your Name
    email = [email protected]
    signingkey = WORK_KEY_ID_HERE
[commit]
    gpgsign = true

Create the personal configuration file:

nano ~/.gitconfig-personal

Add:

[user]
    name = Your Name
    email = [email protected]
    signingkey = PERSONAL_KEY_ID_HERE
[commit]
    gpgsign = true

The includeIf gitdir: directive tells Git: “If the current repository is inside this directory, load this configuration file.” Settings in the included file override earlier settings, giving you automatic profile switching based on where you work.

Set your GPG key IDs in each file. Replace WORK_KEY_ID_HERE and PERSONAL_KEY_ID_HERE with the actual key IDs you retrieved earlier using gpg --list-secret-keys.

Create the directories if they do not exist:

mkdir -p ~/work ~/personal

Now when you clone or create repositories inside ~/work/, Git uses your work identity. Repositories in ~/personal/ use your personal identity.

SSH Signing as an Alternative to GPG

Git 2.34 introduced native support for signing commits with SSH keys. This simplifies setup—you reuse your existing SSH keys instead of managing separate GPG keys. SSH signing works well if you already have Ed25519 SSH keys and prefer one key type for both authentication and signing.

To use SSH signing, configure Git globally or per-directory:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519_personal.pub
git config --global commit.gpgsign true

The key difference: you specify the public key file (.pub) for SSH signing, not the private key. Git signs commits using your SSH agent, which holds the private key.

Add your SSH public key to GitHub as a signing key. Go to Settings > SSH and GPG keys > New SSH key, select “Signing Key” as the type, and paste your public key.

For conditional setups, add to your ~/.gitconfig-personal:

[gpg]
    format = ssh
[user]
    signingkey = ~/.ssh/id_ed25519_personal.pub

And to ~/.gitconfig-work:

[gpg]
    format = ssh
[user]
    signingkey = ~/.ssh/id_ed25519_work.pub

SSH signing has tradeoffs. It requires Git 2.34+ and GitHub/GitLab support (fully supported since 2026). GPG signing works on older Git versions and with any platform that supports GPG. Choose SSH signing for simplicity if you control your environment. Use GPG for broader compatibility and enterprise requirements.

Testing and Verifying Your Setup

After configuration, verify everything works before relying on it for real commits. Start by checking which configuration Git applies to each directory.

For your personal directory:

cd ~/personal
git config --show-origin --get user.email
git config --show-origin --get user.signingkey

Output should show your personal email and signing key, with the configuration file path (~/.gitconfig-personal) as the source.

For your work directory:

cd ~/work
git config --show-origin --get user.email
git config --show-origin --get user.signingkey

Output should show your work email and signing key, sourced from ~/.gitconfig-work.

Create a test commit to verify signing works. In a test repository:

cd ~/personal
mkdir test-repo && cd test-repo
git init
echo "# Test" > README.md
git add README.md
git commit -m "Test signed commit"

Git prompts for your GPG passphrase (unless cached). After committing, check the signature:

git log --show-signature -1

Output should include “Good signature from Your Name <[email protected]>”. If you see “Can’t check signature: No public key”, export your public key and verify it matches what you uploaded to GitHub.

Push to GitHub and check that the commit shows “Verified”. If it shows “Unverified”, your GPG key might not match your Git email exactly, or you might not have uploaded the correct public key to GitHub.

Troubleshooting Common SSH and GPG Errors

Even with careful setup, you might encounter errors. Here are solutions to the most common problems I have seen.

Error: gpg: signing failed: Inappropriate ioctl for device

This error occurs when GPG cannot communicate with the passphrase entry program (pinentry). It is common on macOS and Linux systems after GPG upgrades.

Fix by setting the GPG TTY environment variable. Add to your shell configuration (~/.zshrc, ~/.bashrc, or ~/.bash_profile):

export GPG_TTY=$(tty)

Reload your shell:

source ~/.zshrc  # or ~/.bashrc

If that does not work, configure pinentry explicitly. Create or edit ~/.gnupg/gpg-agent.conf:

pinentry-program /usr/local/bin/pinentry-mac

On Linux, use /usr/bin/pinentry-tty or /usr/bin/pinentry-gnome depending on your environment. Restart the GPG agent:

gpgconf --kill gpg-agent

Error: Git uses the wrong SSH key or identity

If Git authenticates with the wrong key, check your SSH config. Ensure IdentitiesOnly yes is set in each Host block. Without it, SSH might offer multiple keys from your agent, and the server could accept a different one than you intended.

Debug SSH connections with verbose output:

ssh -vT [email protected]

Look for lines like “Offering public key: /Users/you/.ssh/id_ed25519_personal”. This shows which key SSH offers first.

Error: includeIf not working or not loading configuration

Conditional includes require the repository to match the gitdir: pattern exactly. Check that your repository path matches the pattern. The pattern gitdir:~/work/ matches repositories inside ~/work/ but not in ~/workspace/.

Verify Git expands the path correctly:

cd ~/work/some-repo
git config --show-origin --get user.email

If you see ~/.gitconfig instead of ~/.gitconfig-work, the pattern is not matching. Try absolute paths:

[includeIf "gitdir:/home/yourname/work/"]
    path = ~/.gitconfig-work

Error: Commit shows unverified on GitHub

GitHub shows “Unverified” when the GPG key does not match the email in your Git configuration, or when you have not uploaded the public key. Verify:

1. Your Git user.email matches the email on your GPG key (exact match, case-sensitive).

2. You uploaded the correct public key to GitHub (Settings > SSH and GPG keys).

3. Your GPG key is not expired or revoked.

Check key details:

gpg --list-secret-keys --keyid-format LONG

Compare the email in the uid line with your Git configuration:

git config user.email

Frequently Asked Questions

Conclusion

Configuring Git for multiple SSH keys and signing commits with GPG takes initial effort but saves hours of manual configuration mistakes. You now have a complete setup: multiple SSH keys selected automatically by host, GPG keys for commit signing, and Git conditional includes that switch identities based on repository location. Your commits will show verified signatures, and you will never accidentally push with your personal email to a work repository again.

The key components are the SSH config file for key selection, GPG keys for signing, and Git’s includeIf directive for automatic profile switching. Test your setup with the verification commands I provided, and refer to the troubleshooting section when you encounter common errors. Once configured, everything works automatically—you focus on coding, not configuration.