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).
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.
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.
> not clear what code has and has not been deployed
You can have your production machines deploy from specific branches. In other words, master is the development branch, some-version-branch is the production branch. You can also do it vice versa. You can use tags. Lots of solutions.
> code is not explicitly validated (automatically, manually, on a build/test lab)
If you use the structure above, you wouldn't commit to a production branch unless you did that. Another solution is to force validation/testing using hooks before allowing a commit to a production branch on your development machine.
> and it isn't clear who triggered the release.
Not sure what you mean here ... every commit is recorded, so you always know who did what.
I guess it depends on your deployment system, if there is an automated system watching that branch on a central repo, you assume any commit is rolled out and who ever pushed triggered it via commit.
I know where you are coming from with compiled languages. A big reason for creating this flow was for working with repositories that are not our primary code repository. We have several internal tools and forks that don't have a complex deployment process. We wanted the simplicity of being able to push to master and knowing that it will be out in ~30 minutes. Our primary code base is rolled out with Fabric instead of Chef (for now) but Fabric will still need to execute a pull from Github at some point during the rollout.
If anyone is interested in something very like this, but as-a-service, check out https://CircleCi.com. We do continuous deployment so long as your tests pass, with key management to support this kind of flow.
(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.
How is that more secure? They're both running the same code base. That means they have the same vulnerabilities. Both also need to be public facing to deploy code.
> Just make sure your server are on the same network.
Using a VPN? Or are you hosting your own stuff?
If your public facing server gets breached and it is sitting on your actual internal network or is connected through a VPN ... well, that means the attacker just got a free pass right through your firewall.
I used to put my production boxes on a VPN, but now I don't have to because I can deploy from GitHub. That was the main reason I signed up with GitHub.
