Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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_rsa


GitLab 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.


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.


You can, but the interface for doing so is significantly more annoying.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: