I believe you can setup aliases in ssh_config where you specify the actual hostname and the key to use. Which is what I've used in the past to get the right key to just work with git (and gitolite).<p><pre><code> Host github-yipit-main
Hostname github.com
IdentityFile ~/.ssh/yipit_main_rsa
</code></pre>
then just go about your merry way of:<p><pre><code> git clone git@github-yipit-main:/yipit/yipit-main.git</code></pre>
It seems like it would be easier to just create another github user, add it to your organization as a read-only user, and then add each machine's ssh key to that user as a real ssh key rather than a deploy key. The downside is that you can't restrict certain machines to certain repositories, but the upside is that it's a lot less complex.
I was looking at this sideways until I read the last statement about the future. There is something bothersome to me about deploying code directly from a code repository. Things I can think of that bother me about it, not clear what code has and has not been deployed, code is not explicitly validated (automatically, manually, on a build/test lab), and it isn't clear who triggered the release.<p>I think it also bothers the side of me coming from compiled languages where there is more to a code release then copy files from a to b.
If anyone is interested in something very like this, but as-a-service, check out <a href="https://CircleCi.com" rel="nofollow">https://CircleCi.com</a>. We do continuous deployment so long as your tests pass, with key management to support this kind of flow.<p>(Though to be honest, this flow seems overly complex, and I'm not 100% sure what problem it's solving).
best way: don't deploy from github. you should have an internal github server (github enterprise). don't rely on the site to secure your production code. they have had security problems in the past.