It all started when I was juggling two worlds — my work projects on Bitbucket and my personal experiments on GitHub.
My Bitbucket setup was running smoothly. I had my SSH keys configured, commits pushed, pipelines running — life was good.
Then one day, I started a side project on GitHub. I made a few commits, felt proud, and hit:
git push origin mainAnd then — boom 💥 — “Permission denied.”
That’s when I realized my computer was still trying to use my Bitbucket SSH key to talk to GitHub. Time to fix that.
Step 1: Creating a New SSH Key for GitHub
I didn’t want to mess up my existing Bitbucket setup, so I decided to generate a brand-new SSH key just for GitHub.
In the terminal, I ran:
ssh-keygen -t ed25519 -C "personal@gmail.com" -f ~/.ssh/id_ed25519_personalThis created two files:
- id_ed25519_personal → my private key
- id_ed25519_personal.pub → my public key
Then, I copied the content of the public key using:
cat ~/.ssh/id_ed25519_personal.pubI went to GitHub → Settings → SSH and GPG keys → New SSH key, pasted it in, and saved.
At this point, GitHub knew who I was.
But my local machine still didn’t know which key to use when connecting to which service.
Step 2: Teaching My Computer Which Key to Use
Inside my ~/.ssh directory, I had all my SSH keys:
/Users/jiyo/.ssh
├── id_ed25519_work
├── id_ed25519_work.pub
├── id_ed25519_personal
├── id_ed25519_personal.pub
└── configThat config file is the magic piece that tells SSH which key belongs to which host.
I opened it and added the following configuration:
# GitHub account
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_personal
IdentitiesOnly yes
# Bitbucket account
Host bitbucket.org
HostName bitbucket.org
User git
IdentityFile ~/.ssh/id_ed25519_work
IdentitiesOnly yesNow, whenever I connected to GitHub, it used my GitHub key.
And when I connected to Bitbucket, it used my Bitbucket key.
Simple, but powerful.
Step 3: Testing the Setup
Now comes the moment of truth. At this point, you’ll fall into one of two scenarios:
A. You already have a local project that you want to push to a remote repository
First, link your local repository to the remote one so Git knows where to push your changes. If you’re using GitHub, run:
git remote add origin git@github.com:user/repo.gitTo confirm that the remote link was added correctly, use:
git remote -vIf you notice a typo or incorrect URL, simply remove and re-add the remote:
git remote rm origin
git remote add origin git@github.com:user/repo.gitNext, ensure your local branch name matches the remote branch name. For example, if your remote branch is main but your local branch is master, rename it with:
git branch -M mainFinally, push your local project to the remote repository:
git push origin mainB. You already have a remote repository and want to clone it locally
To clone a repository from GitHub, run:
git clone git@github.com:user/repo.gitOr, if you’re cloning from Bitbucket:
git clone git@bitbucket.org:user/repo.gitBoth methods should work perfectly. 🎉
Your machine now knows which SSH key to use for each host.
Step 4: Using Custom Host Aliases
Here’s a neat trick I learned later — you can actually give each host a custom alias.
Host github_personal
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_personal
IdentitiesOnly yesThen, when cloning:
git clone git@github_personal:user/repo.gitThis is super useful when you have multiple GitHub accounts (e.g., work, freelance, personal).
You could have entries like github_work, github_personal, and github_freelance, each tied to its own key.
Common Mistakes
You’ve set up a custom SSH host alias, but forgot to use it in your git clone or git remote add origin command.
For example, using:
git@github.com:user/repo.git instead of the correct alias:
git@github_personal:user/repo.gitStep 5: Don’t Forget
This little line is more important than it looks:
IdentitiesOnly yesIt tells SSH to use only the key you specified — not to randomly try every key it finds.
Without it, you might get errors like:
“Too many authentication failures.”
So yes, make sure this line is there for each host.
Step 6: Check Your Git User Info per Repository
Everything was running perfectly now — but there was one last thing to remember.
Even though my SSH keys were properly separated, Git still needed to know who was making each commit.
In my work repo, I checked the configuration:
git config --local --listIf my personal email appeared there, I fixed it:
git config --local user.name "Your Work Name"
git config --local user.email "your_work_email@company.com"And for my personal repo:
git config --local user.name "Your Personal Name"
git config --local user.email "personal@gmail.com"This ensures I never commit to my company repository using my personal details (been there, done that 😅).
The Final Setup
By the end of it, my .ssh folder looked like this:
/Users/jiyo/.ssh
├── id_ed25519_work
├── id_ed25519_work.pub
├── id_ed25519_personal
├── id_ed25519_personal.pub
└── configMy SSH configuration was clean, my commits were properly tagged, and switching between GitHub and Bitbucket was effortless.
No more “Permission denied.”
No more wrong email in commits.
Just smooth, clean Git operations across all my accounts.
Lesson Learned
If you ever find yourself juggling multiple Git accounts, remember this:
- Give each account its own SSH key.
- Use a .ssh/config file to tell SSH which key belongs to which host.
- Set your Git name and email per repository.
It’s a small setup that saves you from a ton of future headaches.
Now every time I push, it feels like both my work and personal worlds are in perfect sync.
