gitolite:可以通过 ssh 连接,无法克隆

发布于 2025-01-06 14:40:45 字数 1026 浏览 0 评论 0原文

我使用本教程在我的服务器上安装了 gitolite。这属于“非root”方法。

当我尝试将 gitolite-admin 克隆回我的客户端时,它失败了。我收到此错误消息:

git clone [email protected]:gitolite-admin
Cloning into gitolite-admin...
fatal: The remote end hung up unexpectedly

另外:

git clone ssh://[email protected]:gitolite-admin
Cloning into gitolite0admin...
Using username "git-upload-pack 'gitolite".
fatal: The remote end hung up unexpectedly

我还尝试将 .git 附加到存储库名称的末尾,并且我还尝试添加 repositories/gitolite-admin (建议由上面链接的教程中的错误导致)并且这两者的组合都不起作用。我在谷歌上找不到关于“使用用户名”位的结果,这引起了我的兴趣。

我可以通过 ssh 连接到机器,它告诉我我可以访问 R 和 W gitolite-admin。那么,SSH 有效吗?

I installed gitolite on my server using this tutorial. This falls under the "non-root" method.

It fails when I try to clone gitolite-admin back to my client. I get this error message:

git clone [email protected]:gitolite-admin
Cloning into gitolite-admin...
fatal: The remote end hung up unexpectedly

Also:

git clone ssh://[email protected]:gitolite-admin
Cloning into gitolite0admin...
Using username "git-upload-pack 'gitolite".
fatal: The remote end hung up unexpectedly

I have also tried appending .git to the end of the repo name, and I have also tried adding repositories/gitolite-admin (suggested by the errors in the tutorial linked above) and a combination of both of these and none work. I can find no results on google regarding the "Using username" bit, which intrigues me.

I can connect to the machine via ssh, and it tells me that I have access to R and W gitolite-admin. So, SSH is working?

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

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

发布评论

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

评论(2

绿光 2025-01-13 14:40:45

检查 ssh 有关 gitolite 的部分:您可以连接到 server.com通过 ssh 仅意味着:

  • 您的 ssh 密钥已在 server.com@~/.ssh/authorized_keys 中注册,
  • 该密钥与 gitolite 无关“没有“command=”选项,这意味着“无论传入用户要求做什么,都强制运行此命令”)。
    您处于交互式会话中,可以执行您喜欢的任何命令。

我根本不喜欢第三方教程的是它尝试为 git 用户和 ssh 非 root 用户使用相同的名称

您应该保持独立

  • 非 root 用户不是帐户,只是一个 ssh 密钥,它将链接到 gitolite,具有 gitolite-admin 的管理员权限 仓库)
  • 托管帐户,应该是“git”,而不是gitolite,正是为了避免两种使用模式之间的混淆
    • git直接登录 server.com,此处无需 ssh):执行 git 命令所需的交互式会话(例如克隆服务器 gitolite 存储库,并执行 gitolite/src/gl-system-install)
    • ssh [电子邮件受保护] 其中将使用您的 ~/.ssh/id_rsa(.pub) 公共和私有密钥,作为 gitolite 的密钥,将授权您克隆 gitolite-admin 存储库并推送该存储库


“gitolite”不是真正的帐户,只是被授权在 server.com 上以“git”形式执行命令的名称 strong>(实际的“托管帐户”,如“托管 git 服务和存储库”)。
所有其他 git 用户也将在 server.com 上以 git 形式执行 git 命令。
特定用户 (gitolite) 将通过 强制命令机制,在 gitolite 安装期间设置权限,以授予“用户”克隆、修改和推送gitolite-admin的权限回购协议
(与您将添加的所有其他 ssh git 用户相比,这是它的唯一特殊性:他们无权访问特定的 git 存储库,即 gitolite-admin

尝试将两者命名为同名只是自找麻烦。

我不喜欢使用公钥/私钥的默认命名约定,因此我更喜欢在客户端上使用目标用户的名称定义这些密钥:

~/.ssh/gitolite.pub
~/.ssh/gitolite

然后我定义一个配置文件:~/.ssh/config 其中:(

host gitolite
     user git
     hostname server.com
     identityfile ~/.ssh/gitolite

请注意此处的用户:始终git
然后我可以克隆我的 gitolite-amin 存储库:

git clone gitolite:gitolite-admin
# modify locally
# git add -A ; git commit -m "my modifs"
git push origin master

Check the ssh parts about gitolite: the fact that you can connect to server.com through ssh only means:

  • your ssh key is registered in server.com@~/.ssh/authorized_keys
  • that key isn't related to gitolite 'there is no "command=" option, which means "regardless of what the incoming user is asking to do, forcibly run this command instead").
    You are in an interactive session, able to execute any command you like.

What I don't like at all about the third-party tutorial is that it tries using the same name for git user and ssh non-root user

You should keep separate:

  • the non-root user (which isn't an account, just an ssh key, which will be linked to gitolite, with admin privileges to the gitolite-admin repo)
  • the hosting account, which should be 'git', not gitolite, precisely to avoid confusion between the two usage mode:
    • git (log on directly on server.com, no ssh here): interactive session needed to execute git command (like cloning on the server the gitolite repo, and executing gitolite/src/gl-system-install)
    • ssh [email protected] which will use your ~/.ssh/id_rsa(.pub) public and private keys, which, being the ones of the gitolite, will authorize you to clone the gitolite-admin repo and push back that repo

Again:
'gitolite' is not a true account, only a name authorized to execute commands on server.com as 'git' (the actual "hosting account", as in "hosting git services and repos").
All the other git users will also execute git commands on server.com as git.
And that particular user (gitolite) will be linked to gitolite authorization layer through the forced-command mechanism, with privileges setup during the gitolite installation in order to grant that 'user' rights to clone, modify and push back gitolite-admin repo.
(That is its only particularity compared to all the other ssh git users you will add: they won't have access to that specific git repo which is the gitolite-admin one)

Trying to name the two with the same name is just asking for trouble.

I don't like using the default naming convention for the public/private keys, so I prefer on the client defining those keys with the name of the intended user:

~/.ssh/gitolite.pub
~/.ssh/gitolite

Then I define a config file: ~/.ssh/config with in it:

host gitolite
     user git
     hostname server.com
     identityfile ~/.ssh/gitolite

(Note the user here: always git)
Then I can clone my gitolite-amin repo:

git clone gitolite:gitolite-admin
# modify locally
# git add -A ; git commit -m "my modifs"
git push origin master
可爱咩 2025-01-13 14:40:45

对于后代,修复方法是确保 GIT_SSH 设置为 TortoisePlink.exe。 Git 无法使用它。

For posterity, the fix is to make sure that GIT_SSH is not set to TortoisePlink.exe. Git can't use it.

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