How to create ssh deploy keys for github

One issue with creating SSH keys is there are so many ways to do it and no one tells you why they do what they do. A quick search will reveal almost everyone has their own way of doing it.  If you are new to ssh keys I suggest you read this article really quick.

In the github docs they tell you how to create the ssh keys like this

ssh-keygen -t ed25519 -C "your_email@example.com" 

I prefer using the following command instead :

ssh-keygen -t ed25519 -f /home/akashicseer/tests/ssh/file_name -C "akashicseer@gmail.com"

Quick command facts:

1. ed25519 is basically the newest type of key, it is supposed to be the most secure
2. -C is for adding a comment to the key. This helps you identify it later in places like ~/.ssh/known_hosts, ~/.ssh/authorized_keys and when you use the command ssh-add -L which prints out your public key info
3. -t specifies the type of key. The above command tells ssh-keygen to create an ed25519 type of key more info
4. -f /home/akashicseer/tests/ssh/file_name This tells ssh-keygen where to put the file. If you don’t specify the name then it will use a default of something like id_ed25519 for private key and id_ed25519.pub for the public key. The code above will put the files named file_name (private key) and file_name.pub ( public key) in the folder /home/akashicseer/tests/ssh/ If you don’t specify the full path to the exact folder your keys will be put into your users home directory in the default .ssh location. On Ubuntu this is /home/username/.ssh/

NOTE: for ssh deploy keys, don’t specify a passphrase when you create them or you will have to manually enter it later when Packer or whatever you use runs your provisioning code. That means you won’t be able to automate if you enter a passphrase, because it will ask the terminal user to enter the phrase to do a git clone.

There are different types of ssh keys. If you don’t add the ed25519 part then a regular ssh key of type rsa is created, this is the default type of ssh key. Basically Github documentation is showing how to create a secure type of key to use with your code deployments. You will use this key to clone your repository to your server instances.

Creating the key is only half the battle. You must decide how you will create the key, especially if you are automating deployments. When automating deployments the process becomes very complicated.

First either you create the keys you need in the instance you are creating then use the github api to add them to the proper repo. Or you create the keys on a local development computer and use something like Hashicorp Packer to upload the files to the server instance during creation. The latter is the easiest way especially in automation of the infrastructure.

If you are creating your keys locally and using Packer to upload them, you will need to login to Github and go to the deploy keys section of the specific repo to add your public key. The public key is the one that ends in .pub usually. The easiest way to copy the key value is to use xclip which I mention in this article.

If fully automating the process and creating the key on the actual instance, you must remember to eventually remove older keys. Github lets you have like 50 keys per repo max. If your repo needs to be deployed to many instances, such as a microservice structure you can contact them to get added key abilities. You could also reuse the same key, but that would require keeping the private key in a repo as well which probably isn’t a very good idea at all, since ssh keys are the same as passwords basically.

Also remember this. If you are using deploy keys only to deploy by cloning the repo, then deleting the key after the clone is perfectly fine. You only need to use this key one time to clone (aka deploy ) your code, after this it is useless. You can and probably should create new SSH keys for deployment each time and remove them from Github after you deploy, then delete them from the server instance.

Unless you plan on keeping the same instance up and trying to pull from the repo etc. That is messy. Personally I’d prefer to use Packer to create new instances when I need to and redeploy. This has the added benefit that I can upgrade the instance with security etc., test it, add my app code, test it, then swap over after migrating the database and other files. This is like creating a clean slate every time.

You will also need to know how to add the keys to ssh-agent and use them, which I cover in this article.

Here is a link to a list of resources about ssh.