How to Clone Multiple GitHub Repos with Deploy Keys

You have a single user account (deploy-user) on a server instance and you want to deploy multiple GitHub repositories with the same deploy key. You successfully do that for the first repo repo-first. But when you try to do that for the second repo repo-second. GitHub stops you.

In fact, when you add the same deploy key to the second repo, GitHub shows you an error message that says, GitHub gives you an error message Error: Key already in use. In their documentation, they state that

Once a key has been attached to one repository as a deploy key, it cannot be used on another repository.

“Error: Key Already in Use – User Documentation.” Accessed January 2, 2019. https://help.github.com/articles/error-key-already-in-use/#deploy-keys.

Now you can take that key and add it to your user account in GitHub instead. But that would grant read and write access to ALL the repos for deploy-user.

That’s incredibly insecure. So what do you do if you want to have deployment for your repos in the same machine but using deploy keys?

Step 1: Create different key-pairs for different repos for same server user account

This step is pretty simple. I prefer to create the different keys like this

ssh-keygen -t rsa -b 4096 -C "repo-first@servername-deploy-user"
ssh-keygen -t rsa -b 4096 -C "repo-second@servername-deploy-user"

And then I typically copy out the public keys this way:

cat /home/deploy-user/.ssh/repo-first.pub

From this, I’ll copy and add the keys to the respective repos. Typically, I also disallow write access for these keys. This time, you should successfully add the deploy keys to both repos.

Step 2: Set up the SSH Configuration Per Repo

I’ll edit the ssh configuration this way. As the deploy-user, I run vim ~/.ssh/config. It opens up the configuration file and add the configuration like this:

Host alias-repo-first github.com
  Hostname github.com
  IdentityFile /home/deploy-user/.ssh/repo-first

Host alias-repo-second github.com
  Hostname github.com
  IdentityFile /home/deploy-user/.ssh/repo-second

Why do you need this? Because when you run the git clone command, git will automatically pick the default SSH key id_rsa to attempt the connection. Therefore, we need this configuration to get around this automatic selection of the SSH key.

Note: there’s a space between the alias and github.com for each set of configuration under the Host key.

Step 3: Verify the SSH Configuration

To test this works, exit the configuration file and type the following:

ssh -T git@alias-repo-first

You should see the following if successful:

Hi Organization/repo-first! You've successfully authenticated, but GitHub does not provide shell access.

Repeat the same for each repo’s configuration.

Step 4: Clone the Repo

This is the easiest step. Run the git clone command for each repo.

git clone git@alias-repo-first:Organization/repo-first.git

That should solve the situation of cloning multiple GitHub repos with purely deploy keys.

Conclusion

Just to summarize, these are the steps.

How to Clone Multiple GitHub Repos with Deploy Keys

  1. Create 1 pair of SSH key per repo

    For example, ssh-keygen -t rsa -b 4096 -C "repo-first@servername-deploy-user"

  2. Set up SSH config file

    Indicate which key-pair for which repo. Example,
    Host alias-repo-first github.com
    Hostname github.com
    IdentityFile /home/deploy-user/.ssh/repo-first

  3. Verify the configuration

    Test your configuration using ssh -T git@alias-repo

  4. Clone the repo

    Now the moment of truth. git clone git@alias-repo-first:Organization/repo-first.git

This is post #2 since I devote to publishing every week.

Photo by Brina Blum on Unsplash

Publish Every Week

Even though I am in the software business, I like to read widely and outside my field. Sometimes, the non-software and non-business related stuff give me fresh ideas. Other times, they outright inspire me in ways I did not expect. For example, a particular thread by Nick Maggiulli inspired me to pursue publishing a page every week.

What I am going to do is to write out the three things I learn from his thread and that I’ll be experimenting with in the next few months.

Lesson 1: Just Publish Every Week

Nick is currently at post number 104. Which means he has published a post for 104 consecutive weeks. That’s some consistency. Another writer I admire is Tren Griffin from Microsoft. He has now written at least 1 post per week for over 200 consecutive weeks on his blog 25iq. This is something I will be focusing on in this blog starting with the first week of 2019.

Lesson 2: Your Friends and Family won’t care. That’s fine.

I have always cared a bit too much about how other people think. The approach I will take is to accept that most of the people in my life currently won’t care what I write because that’s not what they are interested in.

Tiago Forte, another person I follow but works outside my field, has a similar point. Which is why he writes about getting new readers into your blog by simply asking new people you meet to add to your email list.

He also expects these people to unsubscribe if it’s not what they want in their life. Those who are interested will stay and that’s how he slowly built up an audience.

But, first things first. I’m not going to expect the people in my life to care what I write in this blog by default.

Lesson 3: Reach out to your heroes

Nick put in a shift and wrote a quality post. However, like the proverbial tree in the forest with no one to hear, his post would be as good as non-existent if he didn’t get it out.

Therefore, he emailed one of his heroes, Jason Zweig directly. The fact that Jason subsequently tweeted it out is good feedback that Nick wrote something of a sufficient quality.

I will go as far to say, even if Jason didn’t respond, that’s also good feedback to work on his writing further.

And this wasn’t the only time Nick reached out to his heroes and benefitted from the reaching out. The advice he received also helped him get over the hump when he got stuck.

Bonus Lesson : Occasional Hits and Long Stretches of Slow Growth in between

I cannot recommend enough to read the whole thread. In it, you get an impression that Nick probably had long stretches of slow or non growth in between posts that struck gold. I’m going to end this post with this bonus lesson. All the lessons:

  1. Publish every week
  2. It’s fine when family and friends don’t read
  3. Reach out to your heroes

They work as a stack. Lesson 3 doesn’t work if I don’t appreciate Lesson 2, and get past how most people won’t read my blog. Both lessons don’t matter if I don’t even publish every week in the first place.

This concludes my first published page for 2019. I have written other stuff before this. Regardless, for purely emotional reasons, I will classify this as my post #1. As in the first post since I devote myself to publishing every week.

Photo by Charles Deluvio 🇵🇭🇨🇦 on Unsplash