管理 github 组织存储库上的 ssh 公钥

发布于 2024-11-29 23:46:26 字数 519 浏览 1 评论 0原文

我想知道是否有人有一个好的、干净的、安全的方法来管理其服务器上的 github 组织存储库访问?

您似乎只能将公钥附加到您的个人帐户,而不能仅限制对组织的访问。

我们有一个测试服务器,我们在其中放置多个项目,因此部署密钥,因为它们需要是唯一的,这并不理想。为组织提供全局访问权限会很好,但我不想让我们有自由职业者的服务器完全访问我的个人帐户(服务器可以访问组织,这很好,但也我的个人项目和我所属的所有其他组织,这很糟糕)。

我看到的两种解决方法是要么设置一个虚拟的 github 用户来通过,这看起来很愚蠢,要么启用 ssh 代理转发,这感觉像是一个安全风险(我不是最好的服务器管理员)。

一位朋友建议将服务器设置为远程推送,但这似乎是一个创可贴解决方案。

我认为有一种更简单的方法来设置组织存储库的访问权限,因为我认为这将是每个人的基本需求。

如果有人愿意分享已经/正在为他们的 github 组织工作的东西,我会洗耳恭听。

我可能会硬着头皮创建一个虚拟 github 用户,然后就到此为止了,我需要完成工作。

I was wondering if anyone has a good, clean, safe way to manage github Organization repository access on their servers?

It seems that you can only attach pub keys to your personal account and cannot restrict access solely to an organization.

We've got a beta server where we put multiple projects so deploy keys, because they need to be unique, aren't ideal. It would be nice to give global access to the organization, but I don't want to give the server, which we have freelancers on, full access to my personal account (The server gets access to the organization, which is good, but also to my personal projects and every other organization I belong to, which is bad).

The two workarounds that I see is to either set up a dummy github user to go through, which seems stupid, or to enable ssh agent forwarding, which feels like a security risk (I'm not the best server-admin).

A friend suggested setting up the server as a remote to push to, but it seems like a band-aid solution.

I would like to think there's an easier way to set up access for an organization's repo as I would think it would be a fundamental need for everyone.

I'm all ears if anyone would like to share something that has/is working for their github organization.

I'll probably just bite the bullet and create a dummy github user and call it a day, I need to get work done.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

音盲 2024-12-06 23:46:26

sergey_mo 的答案(以及直接回答 Michał Szajbe 的最后一个问题)的替代方案是创建多个 ssh 密钥,如 githib 上 chalien 所记录:

https://gist.github.com/jexchan/2351996

An alternative to the answer from sergey_mo (and as a direct answer Michał Szajbe's final question) is to create multiple ssh keys as documented by chalien on githib:

https://gist.github.com/jexchan/2351996

燕归巢 2024-12-06 23:46:26

我不明白为什么添加虚拟帐户对于自动部署来说如此糟糕,只要您在推送到 GitHub 之前运行自己的 beta 服务器作为暂存区域即可。也就是说,如果您希望 betacode 是私有的。

通常的 GitHub 方式是添加所有协作者,并且只拥有一个稳定的项目和一个 beta 分支。您会自动将当前的 beta 版本拉到 beta 服务器进行测试(那里不需要 ssh 密钥),如果测试成功,您会将 beta 分支的合并拉入稳定项目。

I don't understand why adding a dummy-account is so bad for automatic deployment, as long as you run your own beta-server as a staging area before pushing to GitHub. That is, if you want the betacode to be private.

The usual GitHub-way would be to add all the collaborators and simply have a stable project and a beta fork. You'd automatically pull the current beta version to your beta server for testing (no ssh key needed there) and if your tests succeed, you pull in the merges from the beta fork to the stable project.

岁月静好 2024-12-06 23:46:26

关于 CI 的小注释:
例如,如果您使用 Jenkins 并且需要它访问多个项目,您将需要:
1. 将公钥添加到一个github用户帐户
2. 将此用户添加为所有者(以访问所有项目)或每个项目中的协作者。

一个系统用户的许多公钥将不起作用,因为 GitHub 将找到第一个匹配的部署密钥,并会发回错误,例如 “错误:对 user/repo2 的权限被 user/repo1 拒绝”

http://help.github.com/ssh-issues/

Small note about CI:
For instance, if you use Jenkins and you need it to access more then 1 project you will need to:
1. add public key to one github user account
2. add this user as Owner (to access all projects) or as a Collaborator in every project.

Many public keys for one system user will not work because GitHub will find first matched deploy key and will send back error like "ERROR: Permission to user/repo2 denied to user/repo1"

http://help.github.com/ssh-issues/

冬天旳寂寞 2024-12-06 23:46:26

您可以通过让不同用户运行您的应用程序(每个应用程序一个用户)来解决此问题。我指的是服务器用户,而不是 github 用户。无论如何,在多应用程序服务器上这是一个很好的做法。

每个用户都有自己的 ssh 密钥对,因此您有许多唯一的部署密钥(每个 github 存储库一个)。

我尽可能使用这种方法。然而,在某些情况下,单个用户运行多个应用程序,并且可能无法使用 github 的部署密钥来完成。我也在寻找针对此类情况的良好解决方案。

You can work around this by having your applications run by different users (one user per application). I mean server users, not github users. It's a good practice anyway on multi-app servers.

Each user then has it's own ssh keypair, so you have many unique deploy keys (one per github repo).

I use this approach whenever possible. However there are situations when more than one app is run by a single user and it probably can't be done with github's deploy keys. I'm also looking for a good solution to such cases.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文