In this article you will go through:

• Basic Use Case: deploy keys for a single repository
• Advanced Use Case: multiple deploy keys for multiple repositories

I am working with Github, but this configuration can be applied to other Git providers.

I am working on a Mac (Unix) environment but these commands can be easily applied to a Windows environment.

Basic Use Case: deploy keys for a single repository

To avoid entering your credentials each time you act on your Git repository, you want to manage deploy keys for your different environments. For this, you will need an ssh key.

To create an ssh key suitable for Github, use this command:

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

This command will prompt the naming proposal, if it is the first time you create an ssh key, just press enter until the command is over.

At this point you should head to the most important folder of this topic:

cd ~/.ssh/

You should now have 2 files in there:

• id_ed25519.pub
• id_ed25519

They represent your public key and your private key. You can find more information about this authentication pattern all over the internet.

The last action is to reference your public key on your Github repository. To do this, head to your Github repository under the section: Settings / Deploy keys. Press the Add deploy key button and you will be asked to paste the content of your file id_ed25519.pub

At this point, you should be able to perform actions on your git repository without having to insert your credentials.

git fetch

This command should validate that you can connect and authenticate to your repository.

Advanced Use Case: multiple deploy keys for multiple repositories

Git as a way to configure multiple deploy keys with patterns to apply them. The first thing you will need to do is create a config file.

nano ~/.ssh/config

In this file, you will specify with ssh key file to use for the different hosts you are connecting to. It can become complex and a lot of options are available for these configurations. Once you will be comfortable with the concept, you will be able to add options.

But to make it simple and clear here is my own ~/.ssh/config

Host project1.github.com
 Hostname github.com
 IdentityFile ~/.ssh/key_project1Host project2.github.com
 Hostname github.com
 IdentityFile ~/.ssh/key_project2

This is all you need in your config file to automatically handle your ssh keys for each of your projects.

For clarity purposes, I have configured my ssh keys to have the name key_project1 and key_project2 but you could use any name. It is up to you.

You can create as many keys as you want through the ssh-keygen command described in the first use case.

The last step is to configure the remote origin on each project. This step happens inside the directory of your project, in the /.git/config file. You need to modify the parameter “url” of the remote origin.

To follow our example from before, here is my /.git/config file from my project names project1

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
[remote "origin"]
        url = git@project1.github.com:Cach54/project1.git
        fetch = +refs/heads/*:refs/remotes/origin/*

At this point, you should be able to perform actions on your git repository without having to insert your credentials.

git fetch

Proceed to the test with this command.

Troubleshooting

I am managing a lot of different projects, on different repositories, and for different companies. So I am often confronted with changes in my config file and sometimes it can become messy.

Git as some kind of config caching and it can cause your configuration to run into issues, especially if you are using the same email address for multiple keys.

So, after you do any modification, I advise you to use this command

ssh-add -D

This will remove the cached keys and basically reload the configuration you created in your ~/.ssh/config file.

For debug operations, I advise using this command:

ssh -v git@github.com

You should be able to see what is going during the connection process to the repositories.

What’s Next

• Dockerize your keys to use Git inside your Docker containers without having to manually duplicate your configuration
• Replicate the same process for your Staging and Production environment

Let me know if you are still having trouble configuring your deploy keys on your environments, I will be happy to help and update this article.

Thank you for reading my lines.