I use it to set user access to my company's servers with ansible automatically. I just have to set a list of github usernames and it generates a list of users with their ssh key access setup !
If someone hacked GitHub they'd just get the _public_ keys, same as the ones listed in the link. You can't login on a server with the public key.
What he has done is that by adding github ids, he gets the public keys of all the users and adds them to his servers. Now all the users' public keys are already in the system. Now they can login with their private keys and this private key remains _only_ on their own system. Not on GitHub or server.
If someone hacked github, they could substitute their own evil key for one of the developers' keys and the automation would add that key to appropriate places, giving access to whomever has the evil private key.
On the other hand, OP probably trusts the contents of source repositories stored on github (few people use commit and tag signing); if so he already trusts github with everything.
It really depends upon if the git repo is gpg signed. We really don't know enough about the automation to make any assumptions.
Were I to do it I would require gpg signed commits and setup the trust chain a bit differently. But you're right its likely just a list of git repos that aren't signed.
Signing of the repo contents (commits/tags) doesn't help anyhow with user ssh keys. If the automation gets the keys from github it effectively trusts github completely, irrespective of the situation with repos.
Additionally, if you use gpg to build your ssh keys and have a trust/sign chain you could then pull this stuff with impunity as long as you keep the trust chain issues sorted.
It's an attempt to solve the key distribution problem. By having you verify your keys on third party sites, a MITM or NSL attack (providing you with fake keys so your messages can be intercepted) gets a lot harder as you have to attack n sites simultaneously instead of one.
I also view this as information leakage. I keep some of my online pseudonyms completely separated, and stuff like that allows people to link them together, if I was not careful enough to use a separate ssh key.
Seems like this would be a good way to frame somebody else. Hack into a server, do some damage/steal files, and drop somebody elses public key on the server.
"But I didnt do it!" - Then why was your key on the server?
Something similar has been available on Launchpad for years. There's a tool called "ssh-import-id". If I want to give you access to an Ubuntu server, I might type "ssh-import-id kentwistle". This would fetch public keys that the kentwistle user on Launchpad has published over HTTPS and then add them to ~/.ssh/authorized_keys.
I don't think there's any reason that ssh-import-id needs to be Launchpad-specific.
Github leverages such content-type negotiation for other resources too: add .diff or .patch to commits or pull requests. There's a way to get git am compatible data too.
