Posted inGit

Managing Multiple GitHub and GitLab Accounts on the Same Machine with SSH Config

Git tutorial - IT technology blog
Git tutorial - IT technology blog

The Struggle of Managing Multiple Repositories Across GitHub and GitLab

Working simultaneously for a company (GitLab) and on personal projects (GitHub) is common. However, if you have to manage two or three different client accounts, you can easily find yourself in a frustrating situation due to permission mix-ups. The most common issue is the 403 Forbidden error when pushing code. Worse yet, you might accidentally commit to a company repository using a personal email, making your Git history look highly unprofessional.

Previously, I used HTTPS to clone repositories. Having to enter a username or Personal Access Token (PAT) every time I pushed was a major hassle. Since switching completely to SSH config, I’ve saved at least 10-15 minutes of frustration every day. The system automatically identifies the account based on the “alias” you define, allowing for a complete separation of work environments.

The Core of the Problem: Why Use SSH Config?

By default, when connecting to GitHub via SSH, your computer looks for the ~/.ssh/id_rsa file for authentication. However, GitHub does not allow the same public key to be used for two different accounts. Even if you create two separate keys, the SSH client isn’t smart enough to choose the right one because both point to the same github.com host.

SSH Config solves this by creating aliases. Instead of using github.com, you use github-personal or github-work. Based on this alias, your computer knows exactly which “key” to present to the server.

Detailed Practical Guide

Step 1: Create Separate SSH Keys

Never use one key for everything. In my experience, each account should have its own key pair. Prioritize the ed25519 algorithm because it’s more secure and lightweight than the old rsa.

# Key for personal account
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_personal

# Key for work account
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_work

Remember to use the -f parameter to give the files different names, avoiding overwriting existing active keys.

Step 2: Add the Public Key to GitHub/GitLab

You need to copy the contents of the .pub file and paste it into the SSH Settings section in your browser. You can use the cat or pbcopy (on macOS) command to quickly get the code:

cat ~/.ssh/id_ed25519_personal.pub
# Copy the entire code and paste it into your personal GitHub settings

Step 3: Configure the SSH Config File

This is the key step. Open (or create) the file at ~/.ssh/config using the command:

nano ~/.ssh/config

Then, fill in the configuration according to the template below:

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

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

# Company GitLab
Host gitlab.com-work
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work

In this configuration: Host is a custom alias you define, HostName is the actual server address, and IdentityFile points directly to the corresponding private key.

Step 4: Practical Cloning and Pushing

The most common mistake happens at this step. You must not copy the SSH link from GitHub exactly; instead, you need to modify the host part to match the name you defined in the config file.

For example, if the original link is: [email protected]:user/repo.git
You would clone using the command:

git clone [email protected]:user/repo.git

If the project is already on your machine, update the remote URL so you don’t have to start over:

git remote set-url origin [email protected]:user/repo.git

Preventing Identity Confusion with Git Config

SSH config helps you bypass access barriers, but it doesn’t automatically fix user.name or user.email. A small oversight could lead to your company’s commit history showing a personal username like “meo-con-9x,” which looks totally out of place.

My advice is to never set your email at the global level (--global). Instead, configure it separately for each project:

git config user.name "Your Name"
git config user.email "[email protected]"

For a more professional setup, you can explore the includeIf feature in the .gitconfig file. It allows for automatic email switching based on the project folder—for instance, using your work email for ~/work/ and your personal email for ~/personal/.

Real-World Experience

I’ve implemented this workflow for my entire development team and found it to be extremely stable. Here are three minor tips to keep you out of trouble:

  • Test the connection: Try the command ssh -T [email protected] before you start. If you see the message “Hi username!”, you’ve succeeded.
  • SSH Agent: Sometimes your computer will “forget” the keys after a restart. Don’t forget to add the key to the agent using the ssh-add command if you encounter authentication errors.
  • Host Naming: Choose short, distinguishable names, but avoid naming them exactly like the real domain to prevent interference when accessing the web.

Setting up SSH config takes only 5 minutes but provides absolute peace of mind. You’ll no longer have to struggle with permission errors or worry about using the wrong account every time you push code.

Are you having any trouble with the configuration? Leave a comment below, and I’ll help you out right away.

Share:
Tags: