Dealing with SSH keys is confusing. Every machine you run should have a unique SSH key.

SSH keys typically consist of 2 files:

  • id_rsa – Your Private Key. Used ONLY on your local machine.
  • – Your Public Key. Give it to others (pub for public).


The names themselves don’t matter, so feel free to rename them. It’s what the files contain that’s important.

If you ever lose or have a key compromised, generate a new one. As long as we are using them for version control, they are perfectly disposable. Don’t forget to delete old keys from your GitHub and Bitbucket accounts!

Steps with ** typically only ever need to be done once per computer.

Step 1: Generating an SSH key **

Once you’ve generated a key, it can be used for multiple services (GitHub, Bitbucket, etc).

You can check if you have any keys installed by looking in the ~/.ssh directory.

ls -al ~/.ssh

The default names are “id_rsa” and ““.

To generate a key, use ssh-keygen:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

I’ll be keeping the default names (~/.ssh/id_rsa and ~/.ssh/

By default, when you set a pass-phrase, you will be prompted for it every time you access the remote repository. Phrases are strongly recommended, because security. However, this behaviour can be changed (see Appendix A and B).


Step 1b: Backup your Keys! (optional) **

This isn’t necessary, but now would be a good time to backup your keys.

Ideally you should have some real and proper way to backup your keys, but here’s my lazy way:

cd ~/.ssh
mkdir backup
cp id_rsa* backup

You’ll always be using the originals (~/.ssh/id_rsa), but in case you accidentally overwrite them, you have a copy in the /backup folder.

Step 2: Install Public Key on your services **

If you haven’t already, install xclip.

sudo apt-get install xclip

SSH Keys need to be copied exactly, so xclip handles your clipboard for you.

Copy your Public Key with this command:

xclip -sel clip < ~/.ssh/

Your clipboard will now contain your Public SSH key.

Next, go add the Public SSH Key to your accounts. Do this by pasting the clipboard in to the box provided.

For GitHub, you can find it under Settings/SSH Keys.

For details, see Step 4:

For Bitbucket, you can find it under Manage Account/SSH Keys.

For details, see Step 6:

Give the keys added to your accounts good names, something about the computer they belong to. That way it’s easier to know what machines they belong to if you ever need to generate new ones.

Step 3. Change remote’s from HTTPS to SSH

To login using your SSH key, you need to change the remote from an HTTPS URL to an SSH URI.

To check your remote’s, run the following command to list them:

git remote -v
  • HTTPS URLs typically begin with https://
  • SSH URIs typically begin with [email protected] (the user), and use a colon : to separate HOST and PATH, not a slash

On GitHub, to find out your repository SSH URI, click SSH below the clone URL box.

click on SSH for your SSH clone URI

click on SSH for your SSH clone URI

On Bitbucket, click the drop-down box beside the URI to change it.

change the clone URI to SSH


Once you’ve configured the SSH keys, you should always check-out using SSH URIs instead of HTTPS.

git clone [email protected]:povrazor/dairybox.git

Since you probably didn’t do that, here’s how we can change the remote:

git remote set-url origin [email protected]:povrazor/dairybox.git

Adjust the code above accordingly if you used Bitbucket instead of GitHub.


Step 4. Done…?

That’s actually it, assuming we don’t mind punching in our pass-phrase every time.

We do mind though.

Appendix A: ssh-agent (i.e. the temporary solution)

If we want to create a temporary shell that will remember the pass-phrase, use this command:

ssh-agent bash

Then to add the SSH key.

ssh-add ~/.ssh/id_rsa

Again, this is only temporary. When you invoke exit, the pass-phrase will be forgotten.

Depending on the Linux configuration, doing ssh-add outside the ssh-agent shell may actually remember the pass-phrase permanently. But if you’re like me, running current Ubuntu’s, that wont cut it anymore.


Appendix B: SSH config (i.e. the permanent solution)

If it doesn’t already exist, create a file ~/.ssh/config

Add these lines to the file.

    User git
    IdentityFile ~/.ssh/id_rsa
    User git
    IdentityFile ~/.ssh/id_rsa


The first time you attempt to SSH to either website (i.e. any time you “git push” or “git pull“), you’ll be prompted for your pass-phrase. After entering it once, you shouldn’t have to enter it again until you reboot.


Appendix C: SSH config explained

The Host line in the SSH config is actually a unique name given to an SSH host. SSH will do a pattern match against what you have listed in your config as Hosts. The Host is not necessarily the host name, which we override using the HostName command (in fact, we’re also overriding the User name here).

If you were to add a section like this:

Host github-custom
    User git
    IdentityFile ~/.ssh/id_rsa_customkey

then you can specify a different SSH key to be used. In this case, I’m assuming I have an additional key pair named “id_rsa_customkey” and ““. I would have to add the Public Key to my GitHub account to use it.

To use the custom host, I would have to modify my URI.

git clone [email protected]thub-custom:povrazor/dairybox.git

Notice that my URI is github-custom and not

The original SSH URIs work correctly because we specifically gave them the same Host as as the HostName. Trickery. 🙂

Appendix D: Permissions

In case your permissions get messed up, the default settings for Ubuntu 14.04 are:

sudo chmod 600 ~/.ssh/id_rsa
sudo chmod 644 ~/.ssh/
sudo chmod 644 ~/.ssh/known_hosts
sudo chmod 664 ~/.ssh/config
sudo chmod 700 ~/.ssh