How to configure multiple Cloud Repositories account in one machine

How to Manage Multiple Cloud Repositories Accounts on One Machine

NOTE: In this article we will see the steps for GitHub, but for other service providers the steps will be similar.

The cleanest and most reliable way is via SSH keys and per-repo Git config.

Managing multiple GitHub accounts on the same computer or coordinating a team using SSH can be tricky if you have not set up properly. In this guide, we’ll walk you through a clean, scalable approach for handling multiple cloud repositories with SSH.

Complete Guide: Managing Multiple GitHub Accounts on One Computer Using SSH

When you work on multiple projects — perhaps some personal, some for clients, or for different organizations — you often need to push code to multiple GitHub accounts from a single machine. This setup can get tricky when the default GitHub authentication via browser or SSH conflicts between accounts.

In this article, We’ll walk you through a clean, effective way to configure multiple SSH keys on the same machine, assign them to different GitHub accounts, and manage them per project with ease. We’ll also cover common mistakes, how to troubleshoot them, and best practices for configuring emails and usernames.

Must Read: How to configure SSH

Why Not Just Use Browser-Based Authentication?

Using browser-based authentication forces you to use a single GitHub account in your default browser. If you work with multiple accounts, this creates conflicts — either pushing code with the wrong identity or getting permission errors.

SSH keys solve this cleanly and securely.

Why Use SSH for GitHub?

Using SSH for authentication:

Eliminates browser-based logins and token juggling
Avoids conflicts when switching between multiple GitHub accounts
Provides a secure, persistent way to push and pull code
Keeps personal and work repositories cleanly separated

Final Working Solution Overview

We'll:

Create separate SSH keys for each remote repositories account.
Add those keys to the corresponding accounts.
Configure an SSH config file to manage multiple SSH identities.
Set local Git username and email per repository.
Change existing remote URLs from HTTPS to SSH (If you have cloned using HTTPS).
Troubleshoot any permission denied or SSH agent errors.

Complete Step-by-Step Setup

NOTE: Try to run the below commands in the bash for better results.

1. Generate SSH Keys for Each Account

Open your terminal and generate a unique SSH key pair for each remote repositories account:

ssh-keygen -t ed25519 -C "anyuser@gmail.com" -f ~/.ssh/github_anyuser
ssh-keygen -t ed25519 -C "capscode.team@gmail.com" -f ~/.ssh/github_capscode

Key points:

Use different filenames via -f ~/.ssh/your_key_name.
Email IDs used here don't need to match the GitHub account email exactly — it’s just for annotation, but it's cleaner if they do.

It generates a new SSH key pair using the Ed25519 algorithm, adds a comment (email), and saves the key pair for each account in a specific file location.

2. Add SSH Keys to SSH Agent

Start the SSH agent:

eval "$(ssh-agent -s)"

Then add both keys:

ssh-add ~/.ssh/github_anyuser
ssh-add ~/.ssh/github_capscode

Check if they're added:

ssh-add -l

3. Add Public Keys to Respective GitHub Accounts

Copy each public key:

cat ~/.ssh/github_anyuser.pub
cat ~/.ssh/github_capscode.pub

Go to GitHub → Settings → SSH and GPG keys for each account and add the corresponding key.

4. Configure SSH Config File for Multiple Identities

Create (if it doesn't exist) or edit:

nano ~/.ssh/config

Add:

# anyuser GitHub account
Host github-anyuser
  HostName github.com
  User git
  IdentityFile ~/.ssh/github_anyuser
  IdentitiesOnly yes

# capscode GitHub account
Host github-capscode
  HostName github.com
  User git
  IdentityFile ~/.ssh/github_capscode
  IdentitiesOnly yes

Note: Host github-anyuser , here the host name need not needs to be same as the key name. This is crucial. The Host alias (github-anyuser, github-capscode) is what you’ll use in your remote URL instead of github.com. This lets you route SSH connections to the correct key.

To exit: (In Bash)

Press Ctrl + X (to exit)
If it asks Save modified buffer? (Y/N), press: Y to save changes N to discard changes
Then press Enter to confirm the file name (if you chose to save)

(In Vim)

Press Esc
Then type: :wq and hit Enter to save and exit :q! and hit Enter to force quit without saving

5. Test SSH Connections

For each account:

ssh -T git@github-anyuser
ssh -T git@github-capscode

NOTE: Here github-anyuser is a host alias name (and not the keyname) you define in your ~/.ssh/config file. It acts like a nickname for a specific SSH config block — pointing to github.com with a specific identity file. A successful message:

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

6. Set Local Git Identity for Each Project

Git identity (username and email) can be different for each repository. Navigate to each project’s directory and run:

For personal projects:

git config user.name "User Name"
git config user.email "anyuser@gmail.com"

For capscode projects:

git config user.name "capscode"
git config user.email "capscode.team@gmail.com"

Important: This avoids commits showing up under the wrong GitHub user. The user.email here must be a verified email on the GitHub account you're pushing to. The user.name is a local author name for commits — it doesn’t need to match your GitHub profile name, but good practice says it should.

List Config in a Project To check config in a repo:

git config --list --local

7. Switch Remote URL from HTTPS to SSH

If you have cloned the repo using SSH, then no need to follow this step.

Navigate to your local repo, if your project’s remote origin is still HTTPS like:

https://github.com/capscode/capscode-website.git

Change it to the correct SSH alias like:

git remote set-url origin git@github-capscode:capscode/capscode-website.git

A Common SSH Confusion Developers Face When Cloning GitHub Repositories

By default, GitHub repositories are cloned using the SSH URL git@github.com:username/repo.git. This works perfectly when a developer has a single GitHub account and one SSH key configured on their system. In such cases, SSH simply uses the default key and authentication succeeds without any issues.

Problems begin when developers work with multiple GitHub accounts, such as personal and work accounts, each requiring a different SSH key. To handle this, developers often configure SSH host aliases in the ~/.ssh/config file. These aliases allow SSH to decide which key to use for a specific connection.

A common mistake is configuring an SSH alias but continuing to clone repositories using github.com. SSH applies a configuration block only when the hostname in the Git URL exactly matches the Host value in the SSH config. If the alias is not used, SSH ignores it entirely.

For example, if your SSH config contains Host github-work, you must clone the repository using git@github-work:username/repo.git. Cloning the same repository with git@github.com:username/repo.git will bypass the alias and may use the wrong SSH key. This often results in authentication failures or access denied errors.

Using SSH aliases becomes especially helpful when managing multiple GitHub accounts on the same machine, ensuring the correct identity is always used for each repository.

8. Verify Your Remote URL

Check:

git remote -v

It should look like:

origin  git@github-capscode:capscode/capscode-website.git (fetch)
origin  git@github-capscode:capscode-website.git (push)

9. Troubleshooting Common Issues

Permission Denied (publickey) Check which keys are active:

ssh-add -l

If missing, re-add:

ssh-add ~/.ssh/github_capscode

Testing Connection Verbosely

ssh -vT git@github-capscode

ssh -T git@github.com

If SSH Key Shows 'Never Used' in GitHub This typically means it hasn't been used yet — try a git pull or git push after ensuring the remote URL and SSH config are correct.

How to remove an SSH key both locally from your machine and optionally from GitHub too, if needed.

To Remove an SSH Key from Your Local Machine:

Delete the private & public key files

Let’s say your key was:

~/.ssh/github_anyuser
~/.ssh/github_anyuser.pub

Remove them like this:

rm ~/.ssh/github_anyuser
rm ~/.ssh/github_anyuser.pub

Remove the key from the SSH agent (if it was added)

List keys loaded in SSH agent:

ssh-add -l

Remove a specific key:

ssh-add -d ~/.ssh/github_anyuser

Or remove all keys:

ssh-add -D

Update your ~/.ssh/config (if you configured one)

Open your SSH config:

nano ~/.ssh/config

Remove or comment out the section referring to the deleted key:

# Host github-personal
#   HostName github.com
#   User git
#   IdentityFile ~/.ssh/github_anyuser

Verify Removal

Check if the SSH key is still available locally:

ls ~/.ssh/

Check active keys in your SSH agent:

ssh-add -l

And that’s it — clean removal done!

To Remove an SSH Key from GitHub Account

Go to GitHub Settings → SSH and GPG keys
Find the key you want to delete.
Click Delete next to it.

Setting Up SSH for a Team of Developers

When you’re working in a team, each member should:

Generate their own SSH key pair
Add their public SSH key to their personal GitHub account
Clone the shared repository via SSH
Set their per-repo Git config with a verified email in their GitHub account
Each Member Configures SSH (optional if default key is used), If the member generated a custom-named key, like id_ed25519_john, they’ll need to configure their ~/.ssh/config else not

Developer SSH Key Generation:

ssh-keygen -t ed25519 -C "developer@example.com"

Add Public Key to GitHub:

Go to Settings → SSH and GPG keys → New SSH key

Clone the Shared Repo:

git clone git@github.com:organization/repo.git

Manage Permissions via GitHub:

Use GitHub repo settings (or organization/team permissions) to control access.

Bonus: Verify Connection

Each member can verify their SSH setup with:

ssh -T git@github.com

It should respond:

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

NOTE: SSH key management is local to their machine; access control is managed via GitHub

Do the email addresses need to be the same in:

Purpose	Email required	Must match GitHub account?	Why?
1. SSH key generation (`-C` flag)	Recommended	No (but good practice)	This is a label in the SSH key's public file — it’s purely informational and doesn't affect GitHub authentication.
2. Per-repo Git identity (`git config user.email`)	Required	Yes	This email is embedded in each commit’s metadata. GitHub uses this to associate commits with your account. Must be a verified email on that account for verified commits and contribution tracking.
3. GitHub account email	Required	Yes	This is your account email (or additional verified emails on your account) that GitHub uses to link commits and notifications.

NOTE:

Email used in git config must be a verified email in the corresponding GitHub account.
SSH key -C email is optional for functionality, but should match for clarity.
Git username (git config user.name) is for your local commits' author field and doesn't have to match your GitHub profile name — though it’s good practice to keep it consistent.

Let's now see the breakdown of the command used in SSH key generation:

ssh-keygen -t ed25519 -C "anyuser@gmail.com" -f ~/.ssh/github_anyuser

What `ssh-keygen -t ed25519 -C "anyuser@gmail.com" -f ~/.ssh/github_anyuser` command does:

It generates a new SSH key pair using the Ed25519 algorithm, adds a comment (email), and saves the key pair in a specific file location.

Breakdown of Each Flag and Argument:

Part	Meaning
`ssh-keygen`	The command-line tool for generating, managing, and converting SSH key pairs.
`-t ed25519`	`-t` specifies the type of key to create. `ed25519` is a modern, fast, and secure elliptic-curve algorithm recommended over RSA now.
`-C "anyuser625@gmail.com"`	`-C` adds a comment inside the public key file. Typically used to indicate the email or purpose of the key. This makes it easier to identify the key later when viewing public keys on GitHub or in `~/.ssh/authorized_keys`.
`-f ~/.ssh/github_anyuser`	`-f` specifies the filename and location where to save the key pair. It saves the private key at `~/.ssh/github_anyuser` and the public key at `~/.ssh/github_anyuser.pub`. If omitted, it defaults to `~/.ssh/id_ed25519`.

What Files Are Created?

After running this:

~/.ssh/github_anyuser → the private key (keep this secret)
~/.ssh/github_anyuser.pub → the public key (this goes into GitHub)

Why Use Each Option?

-t ed25519: Faster, safer, and smaller than RSA. Supports modern cryptography.
-C: Helps you recognize which key is for what — especially useful when managing multiple keys.
-f: Allows you to name and organize your keys separately per GitHub account or project, instead of overwriting the default id_ed25519 key.

Example Without Flags (What Happens?)

If you just ran:

ssh-keygen

It would default to rsa (on older systems) or ed25519 (on newer).
Ask you interactively where to save the key (default ~/.ssh/id_ed25519)
No comment would be added.

Pro Tip:

Always explicitly define:

the key type -t
the comment -C
the filename -f

when working with multiple keys to avoid confusion later.

How SSH behaves with multiple keys in the agent

When you connect to a host (e.g., github.com), SSH will try all keys loaded in the agent, one by one, until one works or all fail.

This can work fine if the server accepts the key early, but:

It might slow down the connection because SSH tries multiple keys.

Some servers (including GitHub and Bitbucket) have a limit on how many keys they accept in one authentication attempt.

If the wrong key is tried first and rejected, sometimes you get “Permission denied” errors.

Why you still want an SSH config file The config file with IdentityFile and IdentitiesOnly yes tells SSH exactly which key to try for which host.

This prevents SSH from trying every key in the agent blindly.

It speeds up authentication and avoids key conflicts or permission errors.

So, What’s the Use of the `~/.ssh/config` File If We Don’t Mention `IdentitiesOnly yes`?

The ~/.ssh/config file allows you to:

Define custom Host aliases for different SSH destinations
Specify which private key to use for which host
Control other connection options (like port, user, etc.)

Even without IdentitiesOnly yes, the config file will:

Map a host alias (like github-anyuser) to a real hostname (github.com)
Set the corresponding IdentityFile for that host alias

But here’s the subtle catch:

Without IdentitiesOnly yes — SSH will still offer other keys loaded in your SSH agent or found in default locations alongside the IdentityFile you specified in the config.

Which can lead to:

Authentication failures if the wrong key gets offered first and the server rejects it
Or unnecessary key attempts before the correct one is picked

Example — Without `IdentitiesOnly yes`

Config

Host github-anyuser
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_anyuser

What happens when you connect?

SSH will offer the key specified in IdentityFile
But will also try:
- Any keys in your SSH agent (ssh-add -l)
- And any default keys in ~/.ssh/ (like id_ed25519, id_rsa)

This can cause issues if the wrong key gets tried first.

Example — With `IdentitiesOnly yes`

Config

Host github-anyuser
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_anyuser
  IdentitiesOnly yes

What happens now?

SSH will only use the specified key
It will ignore all other keys in your agent and .ssh/ folder for this connection Clean, predictable, and avoids “Permission denied (publickey)” errors

So What’s the Point of `~/.ssh/config` Without It?

Without IdentitiesOnly yes, the config is still useful for:

Defining aliases (Host github-anyuser)
Pointing to preferred keys via IdentityFile
Setting custom usernames, ports, or other connection options

But — to fully control which key gets used exclusively for a given host alias, you need IdentitiesOnly yes.

TL;DR:

Action	Config Only	Config + `IdentitiesOnly yes`
Define Host aliases	YES	YES
Specify which key should be preferred	YES	YES
Restrict SSH to use only that key	NO	YES

Note: IdentitiesOnly yes makes that preference mandatory

Pro Tip:

If you only have one key in your agent and one in your .ssh/ folder — the config without IdentitiesOnly yes works fine. But in multi-key, multi-host setups (like multiple GitHub/Bitbucket/GitLab accounts) — it’s essential.

Final Summary

You don’t need to use the same email ID everywhere — but it's recommended for clarity.
You must configure per-repo Git user.name and user.email.
SSH remote URLs must use the correct SSH alias from your SSH config.
Always test connections with ssh -T before pushing code.
Switch existing HTTPS remotes to SSH with git remote set-url.
Keep SSH keys unique and labeled for each GitHub account.
Use separate SSH keys for each GitHub account
Use per-repo git config for user.email matching a verified email on the corresponding account
git config user.name is for commit authorship display and can differ
Manage SSH identities with an SSH config file
Team members should each use their own SSH key and GitHub account — permissions are handled via GitHub settings, not by sharing keys
No browser-based login needed
No credential conflicts
Clean per-project Git identity

Alternative Approaches

Git Configuration Methods

If you prefer managing identities through Git configuration rather than SSH aliases, check out our companion guide:

Modern way to manage multiple cloud repositories from one machine
Learn about:

Per-project .git/config setup
Directory-based includeIf configuration
Using core.sshCommand for key management

How to configure multiple Cloud Repositories account in one machine

How to Manage Multiple Cloud Repositories Accounts on One Machine

Complete Guide: Managing Multiple GitHub Accounts on One Computer Using SSH

Why Not Just Use Browser-Based Authentication?

Why Use SSH for GitHub?

Final Working Solution Overview

Complete Step-by-Step Setup

1. Generate SSH Keys for Each Account

2. Add SSH Keys to SSH Agent

3. Add Public Keys to Respective GitHub Accounts

4. Configure SSH Config File for Multiple Identities

5. Test SSH Connections

6. Set Local Git Identity for Each Project

7. Switch Remote URL from HTTPS to SSH

A Common SSH Confusion Developers Face When Cloning GitHub Repositories

8. Verify Your Remote URL

9. Troubleshooting Common Issues

How to remove an SSH key both locally from your machine and optionally from GitHub too, if needed.

To Remove an SSH Key from Your Local Machine:

To Remove an SSH Key from GitHub Account

Setting Up SSH for a Team of Developers

Developer SSH Key Generation:

Add Public Key to GitHub:

Clone the Shared Repo:

Manage Permissions via GitHub:

Bonus: Verify Connection

NOTE: SSH key management is local to their machine; access control is managed via GitHub

Do the email addresses need to be the same in:

Let's now see the breakdown of the command used in SSH key generation:

What ssh-keygen -t ed25519 -C "anyuser@gmail.com" -f ~/.ssh/github_anyuser command does:

Breakdown of Each Flag and Argument:

What Files Are Created?

Why Use Each Option?

Example Without Flags (What Happens?)

Pro Tip:

How SSH behaves with multiple keys in the agent

So, What’s the Use of the ~/.ssh/config File If We Don’t Mention IdentitiesOnly yes?

Example — Without IdentitiesOnly yes

Example — With IdentitiesOnly yes

So What’s the Point of ~/.ssh/config Without It?

TL;DR:

Pro Tip:

Final Summary

Alternative Approaches

Git Configuration Methods

What `ssh-keygen -t ed25519 -C "anyuser@gmail.com" -f ~/.ssh/github_anyuser` command does:

So, What’s the Use of the `~/.ssh/config` File If We Don’t Mention `IdentitiesOnly yes`?

Example — Without `IdentitiesOnly yes`

Example — With `IdentitiesOnly yes`

So What’s the Point of `~/.ssh/config` Without It?