Managing Multiple GitHub Accounts with SSH Configuration

Sep 7, 2025
Categories: Optimizations Tutorials
Tags: dev workflow github ssh workflow

Working with multiple GitHub accounts presents a common challenge for developers who maintain both personal and professional repositories. The typical scenario involves a developer who contributes to their company's private repositories during work hours and maintains personal projects on their own GitHub account. This setup requires careful configuration to prevent authentication conflicts and ensure commits appear under the correct identity.

This guide demonstrates how to configure multiple GitHub accounts using separate Git configuration files and SSH keys. The approach maintains clean separation between different contexts while allowing seamless switching between accounts.

Prerequisites

Before starting, ensure you have Git installed on your system and basic familiarity with command line operations. You will also need access to both GitHub accounts you plan to configure.

Understanding the Configuration Structure

The solution involves three main components:

  • A master .gitconfig file that routes to specific configurations
  • Separate configuration files for each account (.gitconfig-work and .gitconfig-personal)
  • Individual SSH keys and host configurations for each GitHub account

This structure allows Git to automatically select the appropriate configuration based on the repository location on your filesystem.

Step 1: Generate SSH Keys for Each Account

Start by creating separate SSH keys for each GitHub account. Navigate to your SSH directory:

cd ~/.ssh

Generate an SSH key for your personal account:

ssh-keygen -t ed25519 -C "your-personal-email@example.com" -f ~/.ssh/id_ed25519_personal

Generate an SSH key for your work account:

ssh-keygen -t ed25519 -C "your-work-email@company.com" -f ~/.ssh/id_ed25519_work

When prompted for a passphrase, you can either enter one for additional security or press Enter to skip. The -f flag specifies the filename to avoid overwriting any existing keys.

After generation, you should have four new files in your ~/.ssh directory:

  • id_ed25519_personal (private key)
  • id_ed25519_personal.pub (public key)
  • id_ed25519_work (private key)
  • id_ed25519_work.pub (public key)

Step 2: Add SSH Keys to GitHub Accounts

Copy the public key for your personal account:

cat ~/.ssh/id_ed25519_personal.pub

Log into your personal GitHub account, navigate to Settings > SSH and GPG keys, click "New SSH key," and paste the key content. Give it a descriptive title like "Personal Laptop."

Repeat this process for your work account using the work public key:

cat ~/.ssh/id_ed25519_work.pub

Step 3: Configure SSH Hosts

Create or edit the SSH config file to define different hosts for each GitHub account:

touch ~/.ssh/config
chmod 600 ~/.ssh/config

Add the following configuration to ~/.ssh/config:

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

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

If your work uses GitHub Enterprise with a different domain, modify the work configuration accordingly:

# Work GitHub Enterprise account
Host github-work
    HostName github.yourcompany.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

The IdentitiesOnly yes directive prevents SSH from trying other keys if the specified key fails.

Step 4: Test SSH Connections

Verify that both SSH configurations work correctly:

ssh -T git@github.com

You should see a message like: "Hi username! You've successfully authenticated, but GitHub does not provide shell access."

Test the work connection:

ssh -T git@github-work

This should authenticate with your work account.

Step 5: Create Git Configuration Files

Create separate Git configuration files for each account. Start with the personal configuration:

touch ~/.gitconfig-personal

Add the following content to ~/.gitconfig-personal:

[user]
    name = Your Personal Name
    email = your-personal-email@example.com
[url "git@github-personal:yourusername]
    insteadOf = git@github.com:yourusername

Create the work configuration:

touch ~/.gitconfig-work

Add the following content to ~/.gitconfig-work:

[user]
    name = Your Work Name
    email = your-work-email@company.com
[url "git@github-work:your-company]
    insteadOf = git@github.com:your-company

Step 6: Configure the Master Git Configuration

Create or edit your main Git configuration file to route to the appropriate profile based on directory:

touch ~/.gitconfig

Add the following content to ~/.gitconfig:

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

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

# Default configuration (optional)
[user]
    name = Your Default Name
    email = your-default-email@example.com

This configuration tells Git to use the work profile for any repository within the ~/work/ directory and the personal profile for repositories within the ~/personal/ directory.

Step 7: Organize Your Projects

Create the directory structure that matches your Git configuration:

mkdir -p ~/work
mkdir -p ~/personal

Move or clone your repositories into the appropriate directories. For example:

# Clone a work repository
cd ~/work
git clone git@github.com:company/project.git

# Clone a personal repository
cd ~/personal
git clone git@github.com:yourusername/project.git

Behind the scenes work repositories use git@github-work while personal repositories use git@github-personal.

However, when you clone a repository you do not need to specify this. It is all handled automatically based on the gitconfig.

Step 8: Verify the Configuration

Test that Git uses the correct configuration for each context. Navigate to a work repository:

cd ~/work/some-project
git config user.email

This should display your work email address. Similarly, check a personal repository:

cd ~/personal/some-project
git config user.email

This should display your personal email address.

Working with Existing Repositories

If you have existing repositories that need to use the new SSH configuration, update their remote URLs. For work repositories, change the remote URL to use the work SSH host:

cd ~/work/existing-project
git remote set-url origin git@github.com:company/existing-project.git

For personal repositories, ensure they use the standard GitHub host:

cd ~/personal/existing-project
git remote set-url origin git@github.com:yourusername/existing-project.git

Advanced Configuration Options

You can extend this setup with additional configurations. For example, to use different signing keys for each account, add the following to the respective configuration files:

[user]
    signingkey = YOUR_GPG_KEY_ID

[commit]
    gpgsign = true

You can also configure different merge and rebase strategies, aliases, or any other Git settings specific to each context.

Troubleshooting Common Issues

If you encounter authentication failures, verify that your SSH agent is running and has loaded the correct keys:

ssh-add -l

If your keys are not listed, add them manually:

ssh-add ~/.ssh/id_ed25519_personal
ssh-add ~/.ssh/id_ed25519_work

For permission errors, ensure your SSH files have the correct permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/id_ed25519_*

If commits still appear under the wrong identity, verify that you are working within the correct directory structure and that your .gitconfig includes the proper includeIf directives.

Conclusion

This configuration provides a robust foundation for managing multiple GitHub accounts while maintaining clear separation between different contexts. The directory-based approach ensures that Git automatically selects the appropriate identity and SSH key based on where you are working, reducing the chance of accidentally committing with the wrong account.

The modular structure also makes it easy to add additional accounts or modify existing configurations without affecting other setups. Whether you work with multiple organizations or simply want to keep personal and professional development separate, this approach provides the flexibility and reliability needed for modern development workflows.

📝 Back to All Posts