通过 SSH 访问远程 Git 存储库时使用 su/sudo

Question

假设在 Linux 服务器上有一个远程 Git 存储库R。 R归用户U所有，该用户根本不允许通过 SSH 进行远程登录（例如root ）。 该用户既不能使用基于密码的认证，也不能使用基于密钥的认证。 什么是允许的，但是，被登录为不同的用户，然后使用su或sudo发出命令当U。

是否可以将这两种方法结合起来，以便 Git 在远程服务器上使用su或sudo来访问存储库？

或者，是否有另一种方法可以访问R而不更改其访问权限或为U启用 SSH 登录？

PS：我不介意手动输入密码，例如在su提示符下，只要 Git 处理其余的。

编辑：

从评论看来，我需要澄清我想做这样的事情的原因。 R跟踪的文件是相关服务器正在使用的系统文件 - R不是裸存储库。 这意味着存储库无法真正移动，并非没有很多技巧。

让 Git 使用sudo将允许使用保护这些文件的相同安全模型访问R ，而不是通过必须单独配置和同步的单独途径。

Answer 1

哦，你可以

git config remote.origin.uploadpack "sudo -u U git-upload-pack"

让git fetch将sudo用于名为origin的远程。

您需要确保将 sudo 设置为允许此用户在没有密码的情况下执行此命令，因为我认为无法提示输入密码。

来源：

我发现自己想做一些类似的事情，并发现这个金块完全埋在man git-config

我应该指出，这仅完成了一半的工作，因为我只需要git fetch即可工作。 我想你可以用remote.origin.receivepack做类似的事情以使git push工作，但我还没有尝试过。

Answer 2

比 sshd dameon 更容易的是建立另一个侦听器：设置一个 Apache，它：

• 可以以root身份运行（如“我如何以root身份运行 Apache？ ”中所述，这不是一个好主意/做法，因为在 Apache 中发现的任何新漏洞都可以被利用为... root ）
• 可以将 git 查询重定向到git-http-backend脚本，该脚本允许通过 http 执行 git 命令（称为smart http ， 记录在此处）

这样，您就不必担心sudo和su 。

如果需要，您可以将其与身份验证步骤结合使用。

<Location /git>
  AuthType Basic
  AuthName "Private Git Access"
  AuthUserFile "/etc/git-auth-file"
  Require valid-user
</Location>

您甚至可以使用 gitolite添加授权。

Answer 3

Git 已经带有一些服务器功能，使客户端用户可以访问存储库。 一种似乎最适合您需求的服务解决方案是使用git-shell 。

git-shell允许您将 ssh-users 与 git-repositories 联系起来。 成功验证后，这些用户最终会进入 git-shell，它禁止 shell 操作，但是 - 如果通过 git 客户端访问 - 可以完全访问托管存储库。

您唯一必须做的是：

1. 转到服务器上的/etc/passwd

2. 找到您想要授予 git-access 的用户行（可能它的名字是git ）

   警告：不要更改当前用户的入口！ 您将无法再通过 shell 登录！

3. 将该用户的 shell-reference 从 (fe) /bin/bash更改为/usr/bin/git-shell （具体路径取决于您的系统配置）。

在pro git book中详细描述了这种场景的设置过程。

---

为了通过权限管理增强 gits 简单服务功能（在未来），您可以使用gitolite - 它使用gitolite-shell （并取代 git-shell）来提供它的神奇超能力。

Answer 4

一个非常简单的解决方案是将 repo git clone到“不同用户”（我将其称为 U2）的目录中，然后对该 repo 使用ssh访问。 git 是一个去中心化的 VCS，所以没有所谓的“拥有”回购。 所有存储库都处于平等地位。

您可以偶尔使用远程机器上的sudo手动将 U2 存储库中的更改推送回 U 存储库，或者您甚至可以设置一个提交后挂钩，自动将 U2 存储库的更改推送回原始 U 存储库。 只要没有其他人直接修改 U 存储库，提交后挂钩就可以正常工作。

如果您确实有人直接修改了 U 存储库，则需要有人在 U2 存储库或 U 存储库中引入更改并定期合并它们。 根据这些更改的范围，合并可能是微不足道的，也可能是复杂的。 但是，除非您有充分的理由，否则我建议禁止任何人直接修改 U 存储库。 在这种特殊情况下，无论如何，U2 存储库都将成为事实上的权威存储库。 因此，从某种意义上说，您可以将原始 U 存储库全部删除。

这实际上是另一种简单的方法，即通过移动 U 存储库，使 U2 用户可以直接访问它。 我知道您在问题中说您不想修改原始权限，但这听起来像是对 repo 的一种愚蠢且非常不标准的安排。 git repo 的全部意义在于使其可用于更改，如果您不能简单地做到这一点，那么我会说您的初始配置存在缺陷。