Photo by Markus Spiske on Unsplash

Passwords are so ‘00s!

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

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:

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), (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

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:

The process will look like this:

Keypair Generation with OpenSSH

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

OpenSSH Key Awareness

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:

GitHub Settings

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/ will copy your public key. Then let GitHub know about it:

GitHub SSH Key Addition

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

The very first time this command is run, the console may warn you: “the authenticity of ‘’ 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

Photo by Jean-Louis Paulin on Unsplash

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


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:

Don’t forget

Next time you clone a repository address, make sure you “clone with SSH”:


Happy SSHing!



Data Scientist

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store