Passwords are so ‘00s!

How to log in to GitHub more securely (and faster)

6 min readSep 21, 2020

I was reading the Hackaday newsletter last Friday, and this article took me down the rabbit hole. I realise the article is raising the issue for the API, not the website, but it reminded me how often I had to type those credentials and how annoying I find it. So I started researching about SSH login for GitHub and, ultimately about SSH in general.

It was rather confusing at first as there is a plethora of applications and variations in use, methods, toolkits, etc. but, essentially, the core principles are:

SSH means “Secure SHell”.
It is a protocol that ensures the encryption of communications between a client and a server.
It uses the public-key cryptography system (also called asymmetric cryptography).
Public-key cryptography implies the use of a pair of keys, or keypair. One of the keys is called private and the other, public.
The private key is only known to the owner and is used to decrypt an encrypted message. It stays on your computer.
The public key is used to encrypt a message. This key must be shared with third parties (so the messages can be encrypted).
Public keys are susceptible to brute force attacks (as they are shared, they can be recovered by people with nefarious intentions) and, because of this exposure, a lot of algorithms have been/are being used to generate this keypair.

But let’s get back to our (my :-) ) GitHub situation!

The basics

First things first, we need a way to handle the SSH protocol. I had OpenSSH already installed but any other SSH client would have worked: PuTTY, dropbear, etc.

Next thing is to have an SSH keypair. Either you already have one and $ ls -a ~/.ssh will at least show 2 files: id_rsa (the private key), id_rsa.pub (the public key), either you need to create one:

Keypair generation

I haven’t really tried all the possibilities to see what encryption algorithm/key size combinations works. Ultimately, it is all about the trade-off performance-security and, as Peter Ruppel puts it:

To “Wouldn’t it be better to use 4096-bit RSA instead of Ed25519?”, he replies:
The short answer to this is: as long as the key strength is good enough for the foreseeable future, it doesn’t really matter. Because here we are considering a signature for authentication within an SSH session. The cryptographic strength of the signature just needs to withstand the current, state-of-the-art attacks.

The most common and, conveniently, the one illustrated in the GitHub docs is RSA-4096:

$ mkdir ~/.ssh
$ ssh-keygen -t rsa -b 4096 -C example@email.com

RSA encryption is safe from 1024 bit upwards, anything below 829 bit can be cracked (have a look at this Stack Exchange thread). That’s for a remote attack… for a local/physical attack, we are already doomed!

Anyway, running this command will prompt a couple of questions:

“Where do you want to save your keys?”
“What password do you want to use?”

The process will look like this:

Now that we have a key, the next thing to do is to let key-agent know that there is a key available for use. Key-agent is managing the SSH keys (for OpenSSH, at least). As it starts when an SSH connection is established, it is necessary to make sure the agent is running with $ eval "$(ssh-agent)".

Following this, a simple $ ssh-add ~/.ssh/id_rsa will add the private key to the agent (remember, this is the only key that matters to your side of the transaction).

There you go! Our house is in order!

Going public

Time to head to the GitHub, settings page > SSH and GPG keys > New SSH key:

As you can see, GitHub handles multiple SSH and GPG keys if necessary. In my case, the first key is used by a service that is linked to GitHub and the second is the one I’ve generated for my personal logins.

On Linux, using the command $ xclip -sel clip < ~/.ssh/id_rsa.pub will copy your public key. Then let GitHub know about it:

At this stage, GitHub sends you an email to let you know an SSH key has been added to your account (you also receive an email when you delete a key) and you are pretty much ready to convert your repo to SSH.

Authentication test

If you want to test the connection before changing the repository origin address, you can run: $ ssh -T git@github.com.

The very first time this command is run, the console may warn you: “the authenticity of ‘github.com’ can’t be established”. By typing yes the host is added to ~/.ssh/know_hosts permanently.

Then this message lets you know the connection has been successful:

Convert the login methods

Converting your login method is quite straight forward. It only takes 2 steps:

Check which one you are using at the moment with $ git remote -v.
Change to SSH with $ git remote set-url origin git@github.com:[username]/[repository].git.

Next time you pull/push the repository, you’ll be asked for the password specified during the keypair generation process.

Third time is the charm

Depending on your system, you might be asked for that password up to 3 times: the first time to query the ssh-agent about which public key to use, the second time to log in to the remote server and, finally, to copy the public key back onto your computer.

There are various ways around this:

Adding github.com to ~/.ssh/know_hosts.
Adding the public key to ~/.ssh/authorized_keys.
Adding the credential-helper to cache the password for a certain amount of time (in seconds): $ git config --global credential.helper 'cache --timeout 60'.
Using password-less SSH. (consider this option only if you have faith in how secure your computer is. See link at the bottom of the page for details) $ ssh-keygen -f ~/.ssh/id_rsa -p is used to change a key's passphrase.