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.
  • id_rsa.pub – Your Public Key. Give it to others (pub for public).

NEVER SHARE THE PRIVATE KEY!

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.

The default names are “id_rsa” and “id_rsa.pub“.

To generate a key, use ssh-keygen:

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

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).

Source: https://help.github.com/articles/generating-ssh-keys/

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:

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.

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

Copy your Public Key with this command:

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: https://help.github.com/articles/generating-ssh-keys/

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

For details, see Step 6: https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git

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:

  • HTTPS URLs typically begin with https://
  • SSH URIs typically begin with git@ (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.

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

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

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

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

Source: https://help.github.com/articles/changing-a-remote-s-url/

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:

Then to add the SSH key.

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.

Source: http://askubuntu.com/a/362287/364657

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.

Now REBOOT.

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.

Source: http://stackoverflow.com/a/4246809, http://nerderati.com/2011/03/17/simplify-your-life-with-an-ssh-config-file/

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:

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 “id_rsa_customkey.pub“. 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.

Notice that my URI is github-custom and not github.com.

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:

Details: http://www.howtogeek.com/168119/fixing-warning-unprotected-private-key-file-on-linux/