Fatal编程技术网
  • git/
  • apache_mod_krb上的Git身份验证

apache_mod_krb上的Git身份验证

git http authentication

apache_mod_krb上的Git身份验证,git,http,authentication,kerberos,Git,Http,Authentication,Kerberos,我正在使用GitRepo和GitHTTP后端。在apache2中，我有克隆和推送操作需要身份验证的位置。当我用AuthType Basic保护它的位置时 一切正常，git通过了身份验证，可以克隆和推送，但如果我将类型更改为KerberosV5，git将无法使用正确的凭据访问repo。如果我使用浏览器，我可以访问要保护kerberos的位置 git clone http://user@mydomain.com/git/myapp.git Initialized empty Git reposito

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

git clone http://user@mydomain.com/git/myapp.git
Initialized empty Git repository in /tmp/myapp/.git/
Password:
error: The requested URL returned error: 401 while accessing http://user@mydomain.com/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.9-10+lenny8
curl中的libapache2 mod auth kerb 5.3-5

问题，因为debian中的git是使用curl选项ANY_auth编译的，当git客户端尝试连接到Web服务器并首先要求它协商auth时，它不能这样做，git不要尝试basic auth，因为basic的安全性低于协商。当我尝试curl——anyauth时，我也可以从Web服务器获取数据，但如果我改变了——basic一切都很好，问题是我不能告诉git auth应该使用什么。

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

echo http://x:x@git.example.com > ~/.git-credentials
git config --global credential.helper store
x:x是用户名和密码。您可以在那里使用任意随机字符串。只需要在libcurl中启用身份验证的代码路径。然后kerberos将起作用（对我有效：）

curl中的问题，因为debian中的git是使用curl选项
ANY_AUTH
编译的，当git客户端尝试连接到Web服务器并首先要求它协商AUTH，但它无法完成时，git不要尝试基本AUTH

使用Git 2.3.1（2015年第一季度/第二季度），这将更加稳健：参见：

remote curl
：如果协商失败，返回到
Basic
auth 使用mod_auth_kerb的Apache服务器可以配置为允许用户 使用协商（使用Kerberos票证）或 基本身份验证（使用Kerberos密码）。通常，人们会 希望使用协商身份验证（如果可用），但请后退 如果票证丢失或过期，则进行基本身份验证

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

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

使用Git2.32（2021年第2季度）（参见下面的第二部分）：在使用类似
URL的URL访问服务器之前https://user:pass@站点/
，Git在“协商”身份验证失败后，没有返回到URL中嵌入凭证材料的基本身份验证。
现在（Git2.32），Git做到了（还没有，但很快）

参见（2021年3月22日）作者 （于2021年3月30日合并）

：如果协商失败，则返回基本身份验证 签字人：克里斯托弗·申克

在url中提供用户名和密码时，如下
https://myuser:secret@git.exampe/myrepo.git
并且服务器支持协商身份验证方法，git不会退回到基本身份验证，并且
libcurl
几乎不会尝试使用协商方法进行身份验证

在第一次失败后停止使用协商身份验证方法，因为如果第一次尝试失败，它将永远不会成功

然而，这项工作仍在进行中：

参见（2021年5月18日）by.
（于2021年5月21日合并）

：如果协商失败，则返回基本身份验证” 报告人：本·汉弗莱斯
签字人：杰夫·金

这将恢复（
remote curl
：如果协商失败，则返回到基本身份验证，2021-03-22，Git v2.32.0-rc0--中列出）

该提交确实解决了它想要解决的问题（即使URL中提供了凭据，也避免了协商），但它造成了更严重的倒退：我们现在从未达到“我们有用户名和密码，尝试过，但服务器仍然给了我们401”的条件

这有两个坏影响：

  • 我们从不调用
    credential\u reject（）
    ，因此助手存储的伪造凭证将永远存在
  • 我们从不返回
    HTTP\u NOAUTH，
    ，因此用户得到的错误消息是“
    请求的URL返回错误：401
    ”，而不是“
    身份验证失败
    ”
    • 正确地执行此操作似乎不是一件小事，因为我们不知道协商身份是否是一个问题。
    由于这是即将发布的v2.23.0版本（我们在
    -rc0
    中）中的一个回归，所以现在让我们回到过去，分别进行修复

    （请注意，这不是一个纯粹的恢复；之前的提交添加了一个显示回归的测试，因此我们现在可以将其切换到
    expect\u success
    ）

    不知何故，我怀疑Git目前是否支持通过Kerberos进行身份验证。只是想确认一下，您的客户端正在Debian Lenny上运行？是的，客户端正在Lenny上运行。我知道Git不支持通过Kerberos进行身份验证，比如SSO（有帮助票证），但kerberos可以在apache中模拟基本身份验证，但这不起作用。是否有解决方法？例如使用git选项或环境变量强制进行基本身份验证？如果您碰巧知道，2.5.1中还没有此更改？@kkm在git 2.3.1中，那么我的问题似乎有所不同。如果找不到任何内容，我将搜索更多内容并发布一个单独的问题来帮助解决这个问题。