If you’re a developer working on a project on Github, you may have noticed that the repository’s authentication is not always perfect. For example, if you try to access your project’s repository using your username and password, you may get an error message like this: Github Error: Invalid input for ‘username’: “”. You must provide a valid username. This problem can be solved by switching to SSH authentication for the repository. This will require some changes to your Github settings, but it’s a relatively easy process. Here are some tips on how to do this:

  1. Open up your Github settings and change the default authentication method from “password” to “ssh”. This will make sure that all future accesses to your project using your username and password will be through SSH instead of passwords.
  2. If you’re not already using SSH for the repository, you’ll need to add it as an authentication method in your Github settings. To do this, open up the Settings page of your account and click on the Add Authentication Method button. In the resulting window, enter ssh into the text field and click on OK. You’ll now be able to access your project using SSH instead of passwords!

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:

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:

Once you have the key, head over to your Github user settings under “SSH and GPG Keys,” and paste in the contents of id_rsa.pub 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.

Then push to origin as normal:

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 git@github.com.

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 id_rsa.pub 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:

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

You will need two keys named githubpersonal.pub  and githubwork.pub, 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):

In this command, “personal” is replacing the hostname, github.com, 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 github.com. You must manually specify so Git can select the proper one.