Managing Multiple GitHub Accounts on One Machine

My first week at a new job, I pushed a commit to the company's private repo and GitHub showed it under my personal avatar with my personal email.

Not a security issue technically, but my manager pinged me about it within an hour.

The fix took five minutes once I understood what was actually going on — but it took me longer than that to realize the problem was two completely separate systems that I'd been treating as one.

Two systems, not one

"I'm logged into GitHub" feels like a single thing. It's actually two independent mechanisms that know nothing about each other.

SSH authentication — which GitHub account is allowed to push to a repository. Determined entirely by which SSH key your machine presents when connecting to github.com. One key tied to your personal account means every git push authenticates as that account, regardless of what repository you're pushing to.

Git commit identity — the name and email baked into each commit's metadata. Set by git config user.email. GitHub reads the email from the commit and links it to whichever profile has that email registered. Zero connection to SSH authentication — you could authenticate as Account A via SSH but commit under Account B's email, and Git wouldn't stop you.

The "wrong profile" problem happens when either one (or both) points at the wrong account. You have to fix them separately.

Step 1 — Generate separate SSH keys

One key per account. If you use the same key for both, GitHub can't distinguish which account you intend to authenticate as (a key can only be added to one GitHub account at a time anyway).

# Work account
ssh-keygen -t ed25519 -C "work-email@company.com"
# When prompted for filename, save as: ~/.ssh/id_work

# Personal account
ssh-keygen -t ed25519 -C "personal@gmail.com"
# When prompted for filename, save as: ~/.ssh/id_personal

Add each public key to its respective GitHub account:

GitHub → Settings → SSH and GPG Keys → New SSH Key

Paste the output of:

cat ~/.ssh/id_work.pub        # for the work account
cat ~/.ssh/id_personal.pub    # for the personal account

Step 2 — Configure SSH host aliases

This is the core of the whole setup. Since both accounts connect to github.com, SSH needs a way to know which key to use for which repositories.

The trick: define aliases in ~/.ssh/config that both resolve to github.com but use different identity files.

Host work-github
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_work
    AddKeysToAgent yes
    IdentitiesOnly yes

Host personal-github
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_personal
    AddKeysToAgent yes
    IdentitiesOnly yes

IdentitiesOnly yes is the critical line — it prevents SSH from trying every key in your agent and accidentally authenticating with the wrong one.

Test both aliases:

ssh -T git@work-github
# Expected: Hi work-username! You've successfully authenticated...

ssh -T git@personal-github
# Expected: Hi personal-username! You've successfully authenticated...

If either fails: the key isn't added to the correct GitHub account, or the file path in IdentityFile has a typo.

Step 3 — Use aliases in remote URLs

From now on, clone URLs use the alias instead of plain github.com:

# Work repositories
git clone git@work-github:organization/project.git

# Personal repositories
git clone git@personal-github:username/side-project.git

For repositories you already cloned with the default URL:

git remote set-url origin git@work-github:organization/project.git

Verify with git remote -v — the host portion should show your alias, not github.com directly.

origin  git@work-github:organization/project.git (fetch)
origin  git@work-github:organization/project.git (push)

Step 4 — Set the right commit identity

SSH handles authentication. Now handle the name and email that appear on your commits.

Set your most-used identity as the global default:

git config --global user.name "Your Name"
git config --global user.email "work-email@company.com"

Override per-repository for projects that need a different identity:

cd ~/projects/personal-blog
git config user.name "Your Name"
git config user.email "personal@gmail.com"

This writes to that repository's .git/config and overrides the global for anything committed inside that directory.

• Before your first commit in any new repo, run: git config user.email — verify the output is what you want. Changing it after the commit is pushed means rewriting history, which you probably don't want to deal with.

When things break

"The organization has enabled or enforced SAML SSO"

Your SSH key is registered on GitHub but hasn't been authorized for the specific org that requires SSO.

Fix: GitHub → Settings → SSH Keys → find the key → "Configure SSO" → "Authorize" next to the org name.

One-time step per key per org. Nothing in Git or SSH tells you this is the issue — the error message from GitHub is the only clue.

"ERROR: Repository not found"

Almost never means the repo doesn't exist. It means the SSH key you authenticated with doesn't have access to it.

Fix:

git remote -v              # check which alias is in the URL
ssh -T git@<that-alias>    # confirm which account that alias authenticates as

If the alias authenticates as the wrong account, update the remote URL to use the correct alias.

Commits showing under the wrong profile

GitHub matched the email in the commit metadata to a different account.

Fix:

git log --format='%ae' -1   # check the email on your last commit

If it's wrong, fix going forward:

git config user.email "correct@email.com"

For the already-pushed commit on a shared branch: accept it (rewriting history over a cosmetic email issue isn't worth the disruption to teammates). For a recent unpushed commit, amend it:

git commit --amend --no-edit

Quick reference

SSH authentication and Git commit identity are completely independent — fixing one doesn't fix the other. The one-time SSH config setup with host aliases is the permanent solution. Once it's in place, you never have to think about which account you're using again — the alias in the remote URL does all the routing automatically.