Github provides two ways to authenticate with your repository—over HTTPS with a password, and over SSH using private keys. While both work fine, if you want to switch, you’ll need to configure your local repo to use the new credentials.

Moving To SSH Authentication

Github defaults to HTTPS authentication, using the password for your Github account. Whenever you go to clone a repo, you’ll have to manually select “SSH” as the option for the clone URL if you prefer using that.

While SSH is often best for authenticating connections to Linux servers, Github recommends HTTPS because it’s easy for people and causes less confusion. However, it’s worse for automation, not technically as secure as an RSA key, and can be an annoyance typing it out each time, even with credential caching.

To switch over is pretty simple—you will need to create a new SSH key if you don’t have one, add it to your account, and then swap your local repo over to the new endpoint if you’ve already cloned.

First, check if you have an SSH key already. Your default one is usually stored here on Linux/macOS:

cat ~/.ssh/

On Windows, it depends on the program you’re using. It’s sometimes stored in %HOMEDRIVE%%HOMEPATH%.ssh, but may be different based on what you’re using Git from. In most cases, we recommend using Windows Subsystem For Linux (WSL) which works like a VM and stores the key in a traditional Linux environment.

If you don’t have one, you can make one with ssh-keygen:

ssh-keygen -t rsa -f ~/.ssh/id_rsa

Once you have the key, head over to your Github user settings under “SSH and GPG Keys,” and paste in the contents of into a new key.

Once done, you should be authenticated, provided Git is set up to use this key.

Swapping an HTTPS Repo To SSH Authentication

If you cloned from Github using HTTPS, your repository will already be linked to Github using that remote URL. To fix this, you’ll need to remove the HTTPS remote, usually called origin, and add it back with the proper git@github URI that uses SSH.

git remote rm origin
git remote add origin

Then push to origin as normal:

git fetch origin
git push --set-upstream origin/master

If you’re cloning a new repo, you’ll just need to make sure that it’s set to “SSH” in the future, and that the URI is configured as

Using a Different SSH Key

If you have multiple SSH keys you need to use though, things can get complicated, which is why Github recommends passwords to newcomers. Say you clone the repo on your desktop, but then want to work from your laptop. You’d have to either add a new key to your Github account, or transfer the key to the laptop.


If you can, you should add a new key. Github supports multiple of them for a reason, and you can give them different names to organize them. Sometimes though, you’ll only have one key, and need to fix things on the client side.

If you just want to use the same key, it’s fine to transfer id_rsa and to the new machine. But, if that machine already has its own SSH key, you’ll need to use multiple keys.

You can do that by editing SSH’s hosts config file:

nano ~/.ssh/config

Add two blocks with different names. In this use case, it’s setting up different keys for a personal account vs. a company account.

Host personal
  IdentityFile ~/.ssh/githubpersonal
  IdentitiesOnly yes

Host work
  IdentityFile ~/.ssh/githubwork
  IdentitiesOnly yes

You will need two keys named  and, or whatever names you choose to give them. Lastly, you’ll need to remove the remote again and add it back, specifying the name of the block in the host configuration file (which may not match the key name):

git remote rm origin
git remote add origin git@personal:username/repository.git

In this command, “personal” is replacing the hostname,, in the URL. The reason this is necessary is because SSH’s config defaults to choosing a key based on hostname, which in both the personal and work blocks is just You must manually specify so Git can select the proper one.

Profile Photo for Anthony Heddings Anthony Heddings
Anthony Heddings is the resident cloud engineer for LifeSavvy Media, a technical writer, programmer, and an expert at Amazon's AWS platform. He's written hundreds of articles for How-To Geek and CloudSavvy IT that have been read millions of times.
Read Full Bio »