Re:Read-only deploy keys
by mianos on Tuesday June 16, 2015 @09:07PM
(#9729601)
Now we wait another five years for the ability to share deploy keys across repositories. If you have more than one project in your CI deployable app (for example a couple of internal python libraries), you can't use the same deploy keys. Their suggestion, "don't use modules, package everything in one application or use a full key". Now deploy keys can be R/O (fantastic), this limitation is double annoying.
[ Parent
| on HN ]
workaround - add this to ~/.ssh/config
Host *.github.com
IdentitiesOnly yes
IdentityFile ~/.ssh/%h_id_rsa
HostKeyAlias github.com
ProxyCommand nc github.com %p
use whatever.github.com as the hostname when cloning, and put the key in ~/.ssh/whatever.github.com_id_rsaGitLab CEO here, sharing deploy keys has been a feature for a long time in GitLab http://doc.gitlab.com/ce/ssh/README.html No need to wait five years :)
Rather than using Deploy Keys at all it seems completely better in almost every way to create a fake GitHub user and use its account's regular SSH key. You can, using Teams, give that user read-only access to whichever repo(s) it needs access to for deployment.
Github calls these "machine users". But it's more annoying to manage than the deploy keys UI.
Re:Read-only deploy keys
by BillinghamJ on Wednesday June 17, 2015 @03:45AM
(#9730483)
However Github doesn't actually have support for "machine users" - they're just normal user accounts with full GUI access on Github.com.
And if you are on Github's per-user pricing model, machine users are not free.
This is exactly what I do on bitbucket (which has had read only repo keys for a while) as repo keys are kind of a pain to use.
Machine users work pretty well for this. You can grant R/O access to a repo to the machine user.