Stop GitHub From Confusing Your Work and Personal Accounts (macOS SSH Setup)

I once spent the better part of an hour convinced I’d lost push access to my company’s repo, only to realize GitHub was authenticating me as myself instead of as them. No permissions issue, no revoked key — just SSH quietly offering the wrong identity and GitHub politely lying to me about the repo not existing.

If you juggle a personal GitHub account alongside a company account on the same laptop, you’ve probably hit this error:

ERROR: Repository not found
fatal: Could not read from remote repository.

It almost never means what it says. This post walks through a clean, repeatable way to fix it for good using SSH host aliases, so every project on your machine talks to the right account automatically — no more manually swapping keys or second-guessing which identity just got used.

The Root Cause

By default, macOS keeps one SSH keypair (id_rsa or id_ed25519) and uses it for everything. The moment you have more than one GitHub account, that breaks down: SSH’s ssh-agent will happily offer every key it has loaded, one after another, until GitHub accepts one. If your personal key gets offered first and accepted, GitHub authenticates you as your personal account — even when you’re trying to push to a company repo. GitHub doesn’t reject the connection outright; it just tells you the repo “doesn’t exist,” because as far as that identity is concerned, it doesn’t.

The fix is to give each account its own dedicated key and force SSH to use only that key for that account’s repos, via ~/.ssh/config.

Quick Reference

1. Check existing keys: ls -al ~/.ssh
2. Generate a new key: ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/github-companyname
3. Add it to the Keychain: ssh-add --apple-use-keychain ~/.ssh/github-companyname
4. Copy the public key: pbcopy < ~/.ssh/github-companyname.pub
5. Add the public key to GitHub (Settings → SSH and GPG Keys)
6. Add a Host alias for it in ~/.ssh/config, with IdentitiesOnly yes
7. Test it: ssh -T git@github-companyname
8. Point your repo at it: git remote set-url origin git@github-companyname:org/repo.git

Below is the reasoning behind each step, plus the config gotcha that trips most people up.

Step 1: Inventory Your Existing Keys

Before generating anything new, see what’s already in ~/.ssh:

ls -al ~/.ssh

Default key generation uses generic names like id_rsa or id_ed25519. If you don’t check first, it’s easy to overwrite an existing key by accident. Pick a unique, descriptive filename per account instead (e.g., github-personal, github-acme, github-clientco).

Step 2: Generate a Dedicated Key Pair Per Account

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

• -t ed25519 — uses the Ed25519 algorithm, which is faster and considered more secure than the older RSA default.
• -C "email" — a comment embedded in the key, useful for identifying it later in GitHub’s key list.
• -f ~/.ssh/github-companyname — writes the private key to github-companyname and the public key to github-companyname.pub, instead of clobbering the default filename.

Giving every account its own key pair means access is properly isolated — if one key is ever compromised or revoked, it doesn’t touch your other accounts.

Private vs. public key, quickly:

• ~/.ssh/github-companyname is the private key. Never share it, commit it, or upload it anywhere.
• ~/.ssh/github-companyname.pub is the public key. This is the one you paste into GitHub.

Step 3: Load the Key into Keychain

ssh-add --apple-use-keychain ~/.ssh/github-companyname

This loads the private key into ssh-agent for the current session and stores its passphrase in the macOS Keychain, so you’re not retyping it every time you open a new terminal tab.

Step 4: Register the Public Key with GitHub

pbcopy < ~/.ssh/github-companyname.pub

Then, logged into the correct GitHub account in your browser:

1. Go to Settings → SSH and GPG Keys → New SSH key.
2. Give it a descriptive title (e.g., “MacBook Pro — Work”).
3. Paste the key and save.
4. If the repo belongs to an organization with SAML SSO enabled, click Configure SSO next to the new key and authorize it — otherwise GitHub will still reject access even though the key itself is valid.

Step 5: Configure SSH Host Aliases

This is the step that actually makes multi-account SSH work. Open (or create) ~/.ssh/config:

nano ~/.ssh/config

And define one Host block per account:

# Personal
Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/github-personal
    IdentitiesOnly yes
    AddKeysToAgent yes
    UseKeychain yes
# Company A
Host github-company-a
    HostName github.com
    User git
    IdentityFile ~/.ssh/github-company-a
    IdentitiesOnly yes
    AddKeysToAgent yes
    UseKeychain yes
# Company B
Host github-company-b
    HostName github.com
    User git
    IdentityFile ~/.ssh/github-company-b
    IdentitiesOnly yes
    AddKeysToAgent yes
    UseKeychain yes

Watch your Host labels carefully. Each block needs a unique alias — it’s a common copy-paste mistake to duplicate a Host line (e.g., leaving two blocks both named github-company-a) when adding a third account. If that happens, SSH config parsing takes the first matching value for each key and silently ignores the rest, so your second block effectively does nothing and you’ll be debugging a phantom auth failure. Double-check each Host name is distinct before moving on.

Why IdentitiesOnly yes Matters

Without it, SSH offers every key in your agent to the server, in order, until one is accepted — regardless of which Host alias you connected through. That’s exactly the “wrong account authenticated” problem from the intro. Setting IdentitiesOnly yes tells SSH: for this host alias, use only the IdentityFile I specified, full stop. This single line is what actually enables clean multi-account separation.

Step 6: Verify the Connection

ssh -T git@github-company-a

You should see:

Hi <Your-Username>! You've successfully authenticated, but GitHub does not provide shell access.

If the username in that message isn’t the one you expect, something upstream (key order, missing IdentitiesOnly, wrong .pub uploaded) is still misconfigured — fix it here before touching any repos.

Step 7: Point Your Repo at the Right Alias

Inside a project, check and update the remote:

# Check current remote
git remote -v

# Update it to use your SSH host alias
git remote set-url origin git@github-company-a:Org/Repo.git

The difference is subtle but important:

Remote URLBehavior[email protected]:Org/Repo.gitUses SSH’s default identity resolutiongit@github-company-a:Org/Repo.gitUses the Host github-company-a block in ~/.ssh/config

Do this per-repo, once, and every future git pull/push in that folder automatically uses the correct identity — no env vars or manual key-switching required.

Troubleshooting

ERROR: Repository not found / fatal: Could not read from remote repository

• SSO not authorized — go to Settings → SSH Keys → authorize SSO for that key.
• Wrong key being offered — confirm IdentitiesOnly yes is set for that host block.
• Remote URL still points at the wrong alias — check with git remote -v.

Permission denied (publickey)

• The key isn’t loaded in ssh-agent — run ssh-add --apple-use-keychain ~/.ssh/github-companyname again.
• The public key wasn’t copied/pasted correctly into GitHub — re-copy with pbcopy and re-paste.

Takeaway

The whole setup boils down to three ideas: a separate key per identity, a host alias per identity in ~/.ssh/config with IdentitiesOnly yes, and remotes that point at the alias instead of github.com directly. Once it’s wired up, switching between personal and work repos is completely invisible — you cd into a folder and git push just works as the right person.

Use this file here to run the shell script and setup all these automatically, just by following the prompt on the terminal: