我已经将 EPEL 存储库中的 gitolite3 安装到 Centos6.4 中。有许多我不喜欢的地方，所以我开始着手进行更改。首先，我创建了一个名为“git”的附加用户和组，以与晦涩难懂的 gitolite3 用户保持距离。其次，我使用自定义文件夹 /Server/Projects 而不是 /var/lib/gitolite3。我确保所有权和权限相同。
设置也没有问题（su - git，然后使用管理员客户端密钥设置 gitolite3）。
通常，在客户端计算机上，该命令ssh git@myserver info会生成一个很好的 gitolite 纯文本返回，列出存储库和权限。但现在它要求我输入密码。显然，gitolite 不再通过此用户连接到 ssh 端口，但通常的 bash 是连接的。
我不是 SSH 专家，所以出了点问题，或者我忘记做了一些事情。我应该去哪里找？我认为 /usr/share/gitolite3/gitolite3-shell 是 git 用户发出 SSH 请求时 SSHD 应该调用的应用程序。
答案1
SSH 并不容易。我自己已经解决了这个问题，但并不明显。这主要是 SELinux 的问题，但我发现我也没有正确设置公钥。
首先，我（重新）创建了用于管理 gitolite 服务器的本地计算机的公钥（admin.pub），将其复制到服务器 git 用户主文件夹，使用该公钥重新运行（在 git 用户的主文件夹中）gitolite 设置。这里需要注意的是，我的本地计算机是带有 msys-git 的 Windows，因此问题并不简单。
# su - git
$ cd /Server/Projects
$ gitolite setup --pubkey admin.pub
..这解决了公钥问题。selinux 的学习难度更大，但实际上，当您只是复制时，您会丢失所有原始 /var/lib/gitolite3 文件夹上下文标签。要恢复标签（使用 semanage），请引用与原始文件夹相同的标签（使用 -e 标志），到您设置当前 gitolite 文件夹的位置。由于这只会添加到现有的 selinux 文件上下文中，因此您还需要从 selinux 文件上下文中恢复这些上下文。最后一个陷阱是使用绝对路径，而不是相对路径。您可以看到使用 ll 命令所做的事情：
# semanage fcontext -a -e /var/lib/gitolite3 /Server/Projects
# restorecon -R /Server/Projects
# ll -aZ
现在，在您的本地机器上，使用下面的命令从公钥来源的计算机尝试所有操作，对我来说，它有效。请注意，我不知道只有ssh git@unclefloserver info当服务器实际上拥有请求用户/计算机组合的公钥时，才会返回一个不错的 gitolite3 repo info 输出。我也不太理解这个概念，而且我是从另一台电脑上尝试的。
> git clone git@server:gitolite-admin
非常感谢@Etan Reisner 的持续支持。