Multiple GitHub accounts on one laptop are normal now: a managed work identity,
a personal account, perhaps an open-source organization account. The failure mode
is still surprising. git fetch says the repository does not exist even though
it absolutely does, because SSH offered a key that authenticated successfully
for the wrong account.
The useful fix is to choose an identity at the repository level. That keeps a work account from accidentally becoming the default for every clone on a machine, and it avoids a maze of hostname aliases when one exceptional repository is all you need to handle.
Confirm that this is an SSH identity problem
First check the remote rather than changing credentials blindly:
git remote -v
git remote get-url origin
This article applies to an SSH URL such as git@github.com:owner/repo.git. An
https:// remote uses a credential helper and personal-access tokens instead;
changing core.sshCommand will not fix it.
For an SSH remote, ask Git to show the SSH negotiation while fetching:
GIT_SSH_COMMAND='ssh -vvv' git fetch origin
Look for the identities SSH offers and the account GitHub accepts. Do not paste that verbose output into a ticket or chat without reviewing it first: it can reveal usernames, hostnames, and local key paths.
Set the key only for this repository
From the repository root, configure the exact key to use:
git config core.sshCommand \
'ssh -i ~/.ssh/id_ed25519-personal-github -o IdentitiesOnly=yes'
Git writes this to .git/config by default. There is deliberately no
--global flag. IdentitiesOnly=yes matters: it tells SSH not to keep trying
keys supplied by an agent after the named key, which is the usual reason a
multi-account setup quietly chooses the wrong identity.
Verify what the repository will use:
git config --show-origin --get core.sshCommand
git ls-remote origin HEAD
git ls-remote is a tidy final check because it authenticates to the configured
remote without changing local branches or the working tree.
A more maintainable option for several repositories
If many repositories use the same identity, put a named host in ~/.ssh/config:
Host github-personal
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519-personal-github
IdentitiesOnly yes
Then point only the relevant remotes at that host:
git remote set-url origin git@github-personal:slaptijack/example.git
This is cleaner for a whole account boundary. The repository-local
core.sshCommand is better when a single clone is exceptional or when a
repository needs a carefully constrained command.
Avoid the tempting shortcuts
Do not rename or overwrite a work key to make a personal clone work. Do not add
IdentitiesOnly globally until you understand every host that depends on your
SSH agent. And do not share one private key between organizational and personal
accounts simply because it is convenient; separate keys make revocation and
audit boundaries much less ambiguous.
When the remote itself has changed—not merely its identity—use the migration workflow in updating a moved Git remote. If the account works but branches look stale, the remote-pruning guide is the next useful check.
The important distinction is simple: Git chooses a remote, SSH chooses an identity, and a repository-local setting can safely override the latter without changing the rest of your machine.
