通过 apache_mod_krb 进行 Git 身份验证

发布于 2024-09-12 20:05:03 字数 1167 浏览 2 评论 0原文

我正在使用 git repo 和 git-http-backend。在 apache2 中，我有位置需要克隆和推送操作的身份验证。当我使用 AuthType Basic 保护它的位置时一切正常，git 通过身份验证，可以克隆和推送，但如果我将类型更改为 KerberosV5，git 无法使用正确的凭据访问存储库。如果我使用浏览器，我可以访问保护 kerberos 的位置。

git clone http://[email protected]/git/myapp.git
Initialized empty Git repository in /tmp/myapp/.git/
Password:
error: The requested URL returned error: 401 while accessing http://[email protected]/git/myapp.git/info/refs
fatal: HTTP request failed

并在apache错误日志中

[Fri Aug 06 17:15:50 2010] [debug] src/mod_auth_kerb.c(1579): [client 192.168.12.153]  kerb_authenticate_user entered with user (NULL) and auth_type KerberosV5 
[Fri Aug 06 17:15:50 2010] [debug] src/mod_auth_kerb.c(1579): [client 192.168.12.153]kerb_authenticate_user entered with user (NULL) and auth_type KerberosV5

git-core 1:1.7.1-1~bpo50+1 apache2 2.2.9-10+lenny8 libapache2-mod-auth-kerb 5.3-5

原文

I'm using git repo with git-http-backend. In apache2 I have location what needs authentication for clone and push actions. When I protected it location with AuthType Basic
all works is fine, git passes authentication and can clone and push, but if I change type to KerberosV5 git can't access to repo with correctly credentials. If I'm using my browser I have access to location what to protect kerberos.

git clone http://[email protected]/git/myapp.git
Initialized empty Git repository in /tmp/myapp/.git/
Password:
error: The requested URL returned error: 401 while accessing http://[email protected]/git/myapp.git/info/refs
fatal: HTTP request failed

and in apache error logs

[Fri Aug 06 17:15:50 2010] [debug] src/mod_auth_kerb.c(1579): [client 192.168.12.153]  kerb_authenticate_user entered with user (NULL) and auth_type KerberosV5 
[Fri Aug 06 17:15:50 2010] [debug] src/mod_auth_kerb.c(1579): [client 192.168.12.153]kerb_authenticate_user entered with user (NULL) and auth_type KerberosV5

git-core 1:1.7.1-1~bpo50+1 apache2 2.2.9-10+lenny8
libapache2-mod-auth-kerb 5.3-5

分享到QQ

分享到微博

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

发布评论

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

不再让梦枯萎 2024-09-19 20:05:03

curl 中的问题，因为 debian 中的 git 是使用curl 选项 ANY_AUTH 编译的，当 git 客户端尝试连接到网络服务器并首先要求它协商身份验证时，它无法执行此操作，git don'不要尝试基本身份验证。

使用 Git 2.3.1（2015 年第一季度/第二季度），这将更加强大：请参阅 commit 4dbe664< /a> 作者：brian m.卡尔森（bk2204）：

remote-curl：如果协商失败，则退回到Basic身份验证

使用 mod_auth_kerb 的 Apache 服务器可以配置为允许用户
使用 Negotiate（使用 Kerberos 票证）进行身份验证或
基本身份验证（使用 Kerberos 密码）。很多时候，一个人会
希望使用协商身份验证（如果可用），但又会回退
如果票证丢失或过期，则转至基本身份验证。

但是，libcurl 会非常努力地使用 Basic 之外的其他内容
身份验证，甚至通过 HTTPS。
如果提供 Basic 和其他选项，libcurl 将永远不会尝试使用 Basic，即使其他选项失败。
教导 HTTP 客户端代码停止尝试以下身份验证机制
第一次失败后不要使用密码（当前是协商），因为如果他们第一次失败，他们将永远不会成功。

当 git 客户端尝试连接到网络服务器并首先要求它协商身份验证但它无法做到时，git 不要尝试基本身份验证。

~~使用 Git 2.32（2021 年第 2 季度）~~（请参阅下面的第二部分）：之前，当使用 https://user:pass@site/ 等 URL 访问服务器时>，在“协商”身份验证失败后，Git 不会使用嵌入在 URL 中的凭据材料回退到基本身份验证。
~~现在（Git 2.32），Git 做到了~~（还没有，但很快）。

请参阅提交 1b0d954（2021 年 3 月 22 日），作者：Christopher Schenk (chschenk)。
^{（由 Junio C Hamano -- gitster -- 合并于提交 5013802，2021 年 3 月 30 日）}

remote-curl：回到基本状态如果协商失败则进行身份验证
^{签署人：Christopher Schenk}

当在像这样的 URL 中提供用户名和密码时 https://myuser:[email protected]/myrepo.git 并且服务器支持协商身份验证方法，git 不会回退到基本身份验证，并且 libcurl 几乎不会尝试进行身份验证使用协商方法。
在第一次失败后停止使用协商身份验证方法，因为如果第一次尝试失败，它将永远不会成功。

但是，这仍在进行中：

请参阅提交 ecf7b12、提交 b694f1e（2021 年 5 月 18 日），作者：杰夫·金 (peff)。
^{（由 Junio C Hamano -- gitster -- 合并于提交 c69f2f8，2021 年 5 月 21 日）}

恢复“remote-curl：回退如果协商失败，则进行基本身份验证”
^{报告人：Ben Humphreys}
^{签字人：杰夫·金}

这将恢复提交1b0d954（remote-curl ：如果协商失败，则回退到基本身份验证，2021-03-22，Git v2.32.0-rc0 -- 合并在第5批中列出。
该提交确实修复了它想要解决的情况（即使在 URL 中提供了凭据，也避免了协商），但它造成了更严重的回归：我们现在从未达到“我们有用户名和密码，尝试过”的条件他们，但服务器仍然给我们一个 401"。
这有两个不好的影响：
我们从不调用credential_reject()，因此助手存储的虚假凭证将永远存在
我们从不返回 HTTP_NOAUTH，，因此用户收到的错误消息是“请求的 URL 返回错误：401”，而不是“身份验证失败”代码>”。
正确执行此操作似乎并不简单，因为我们不知道协商身份验证是否存在问题。
由于这是即将发布的 v2.23.0 版本（我们在 -rc0 中）中的回归，因此让我们暂时恢复并单独进行修复。
（请注意，这不是纯粹的恢复；之前的提交添加了显示回归的测试，因此我们现在可以将其翻转为 expect_success）。

Problem in curl, because git in debian was compiled with curl option ANY_AUTH, and when git client try connect to webserver and first ask it negotiate auth and it can't do it, git don't try basic auth.

That will be more robust, with Git 2.3.1 (Q1/Q2 2015): see commit 4dbe664 by brian m. carlson (bk2204):

remote-curl: fall back to Basic auth if Negotiate fails

Apache servers using mod_auth_kerb can be configured to allow the user
to authenticate either using Negotiate (using the Kerberos ticket) or
Basic authentication (using the Kerberos password). Often, one will
want to use Negotiate authentication if it is available, but fall back
to Basic authentication if the ticket is missing or expired.

However, libcurl will try very hard to use something other than Basic
auth, even over HTTPS.
If Basic and something else are offered, libcurl will never attempt to use Basic, even if the other option fails.
Teach the HTTP client code to stop trying authentication mechanisms that
don't use a password (currently Negotiate) after the first failure, since if they failed the first time, they will never succeed.

when git client try connect to webserver and first ask it negotiate auth and it can't do it, git don't try basic auth.

It will, ~~with Git 2.32 (Q2 2021)~~ (see second part below): before, when accessing a server with a URL like https://user:pass@site/, Git did not to fall back to the basic authentication with the credential material embedded in the URL after the "Negotiate" authentication failed.
~~Now (Git 2.32), Git does~~ (not yet, but soon).

See commit 1b0d954 (22 Mar 2021) by Christopher Schenk (chschenk).
^{(Merged by Junio C Hamano -- gitster -- in commit 5013802, 30 Mar 2021)}

remote-curl: fall back to basic auth if Negotiate fails
^{Signed-off-by: Christopher Schenk}

When the username and password are supplied in a url like this https://myuser:[email protected]/myrepo.git and the server supports the negotiate authenticaten method, git does not fall back to basic auth and libcurl hardly tries to authenticate with the negotiate method.
Stop using the Negotiate authentication method after the first failure because if it fails on the first try it will never succeed.

However, this is still in progress:

See commit ecf7b12, commit b694f1e (18 May 2021) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit c69f2f8, 21 May 2021)}

Revert "remote-curl: fall back to basic auth if Negotiate fails"
^{Reported-by: Ben Humphreys}
^{Signed-off-by: Jeff King}

This reverts commit 1b0d954 (remote-curl: fall back to basic auth if Negotiate fails, 2021-03-22, Git v2.32.0-rc0 -- merge listed in batch #5).
That commit does fix the situation it intended to (avoiding Negotiate even when the credentials were provided in the URL), but it creates a more serious regression: we now never hit the conditional for "we had a username and password, tried them, but the server still gave us a 401".
That has two bad effects:
we never call credential_reject(), and thus a bogus credential stored by a helper will live on forever
we never return HTTP_NOAUTH, so the error message the user gets is "The requested URL returned error: 401", instead of "Authentication failed".
Doing this correctly seems non-trivial, as we don't know whether the Negotiate auth was a problem.
Since this is a regression in the upcoming v2.23.0 release (for which we're in -rc0), let's revert for now and work on a fix separately.
(Note that this isn't a pure revert; the previous commit added a test showing the regression, so we can now flip it to expect_success).

回复收藏 0 原文

空名 2024-09-19 20:05:03

在curl中出现问题，因为debian中的git是用curl选项ANY_AUTH编译的，当git客户端尝试连接到网络服务器并首先要求它协商身份验证但它无法做到这一点时，git不要尝试基本身份验证，因为基本身份验证的安全性较低比谈判。当我尝试使用curl --anyauth时，我也可以从网络服务器获取数据，但是如果我更改--basic一切正常，问题是我无法告诉git应该使用什么auth。

回复收藏 0 原文

‘画卷フ 2024-09-19 20:05:03

这是 libcurl 中的一些奇怪的事情，而不是 Git 中的问题。有一个解决方法。如果您不将用户名和密码传递给库，Libcurl 不会启用任何身份验证代码。如果您也使用不需要用户名和密码的协商（kerberos），就会发生这种情况。简单的解决方案：

echo http://x:[email protected] > ~/.git-credentials
git config --global credential.helper store

x:x 是用户名和密码。您可以在那里使用任何随机字符串。只需要在 libcurl 中启用身份验证的代码路径即可。然后 kerberos 就可以工作了（对我有用:)）。

It's something weird in libcurl, not a problem in Git. There is a workaround. Libcurl doesn't enable any authentication code if you don't pass username and password to the library. This happens if you use negotiate (kerberos) too which doesn't require username and password. The simple solution:

echo http://x:[email protected] > ~/.git-credentials
git config --global credential.helper store

x:x is the username and password. You can use any random string there. It's only needed to enable the code path to authentication in libcurl. Then kerberos will work (works for me :) ).

回复收藏 0 原文

~没有更多了~