可以使用默认的Windows凭据以非交互方式对远程Git存储库进

可以使用默认的Windows凭据以非交互方式对远程Git存储库进

关注
发信
关注(28)粉丝(399)

是否可以使用默认的Windows凭据以非交互方式对远程Git存储库进行身份验证?

本文介绍了是否可以使用默认的Windows凭据以非交互方式对远程Git存储库进行身份验证?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

限时删除！！

我的远程Git存储库由本地TFS服务器托管.有两种访问其内容的方法:

My remote Git repository is hosted by the on premises TFS server. There are two ways to access its content:

要使用Restful API，可以将powershell Invoke-RestMethod 命令与 -UseDefaultCredentials 一起使用，并且可以正常工作，没有任何问题.

To use the Restful API one can use the powershell Invoke-RestMethod command with the -UseDefaultCredentials and it works fine, no questions asked.

但是，对于 git clone ，我不知道如何使用默认凭据.管理凭据帮助器不使用它们.首次使用时，它会要求提供凭据.

With git clone, however, I have no idea how to use the default credentials. The manager credential helper does not use them. When used for the first time it asks for the credentials.

所以，我看到的选项是:

So, the options I see are:

  • 还有一个替代git客户端，可能功能有限，但足以运行可以使用默认Windows凭据的克隆.
  • 有一个用于Windows的凭据帮助器，可以使用默认的Windows凭据.
  • 对于Windows，有一个Askpass实现，可以使用默认的Windows凭据.

问题是我在网络上找不到实现这些选项中任何一个的任何东西.

The problem is that I could not find anything on the web that implements any of these options.

"> https://github.com/git-for-windows/git/wiki/FAQ#how-do-i-access在Microsoft团队基础基金会服务器存放在Windows域内部的一个存储库似乎不起作用.请注意:

The approach suggested in https://github.com/git-for-windows/git/wiki/FAQ#how-do-i-access-a-repository-hosted-on-a-microsoft-team-foundation-server-inside-a-windows-domain does not seem to work. Please, observe:

C:\xyz\DevOps> $GitApiUrl
http://tfsserver:8080/tfs/DefaultCollection/code/_apis/git/repositories/MyConfigData
C:\xyz\DevOps> $ProjectName
dev_smoketest56oc
C:\xyz\DevOps> Test-Path .\params.json
False
C:\xyz\DevOps> Invoke-RestMethod -Uri "$GitApiUrl/items?path=$ProjectName.json&api-version=4.1" -UseDefaultCredentials -OutFile params.json
C:\xyz\DevOps> Test-Path .\params.json
True

如您所见，Restful API无需输入凭据即可工作.现在让我们尝试git clone:

As you can see the Restful API works without asking for credentials. Now let us try git clone:

C:\xyz\DevOps> $env:GIT_TRACE=1
C:\xyz\DevOps> git clone http://:@tfsserver:8080/tfs/DefaultCollection/code/_git/MyApp a
09:13:21.405748 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
09:13:21.406249 git.c:415               trace: built-in: git clone http://:@tfsserver:8080/tfs/DefaultCollection/code/_git/MyApp a
Cloning into 'a'...
09:13:21.430369 run-command.c:637       trace: run_command: git remote-http origin http://:@tfsserver:8080/tfs/DefaultCollection/code/_git/MyApp
09:13:21.459149 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
09:13:21.460654 git.c:654               trace: exec: git-remote-http origin http://:@tfsserver:8080/tfs/DefaultCollection/code/_git/MyApp
09:13:21.460654 run-command.c:637       trace: run_command: git-remote-http origin http://:@tfsserver:8080/tfs/DefaultCollection/code/_git/MyApp
09:13:21.481711 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
09:13:21.539575 run-command.c:637       trace: run_command: 'git credential-manager erase'
09:13:21.642660 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
09:13:21.644162 git.c:654               trace: exec: git-credential-manager erase
09:13:21.644162 run-command.c:637       trace: run_command: git-credential-manager erase
fatal: Authentication failed for 'http://:@tfsserver:8080/tfs/DefaultCollection/code/_git/MyApp/'
C:\xyz\DevOps> $env:GIT_TRACE=0
C:\xyz\DevOps>

身份验证失败.

在bash控制台上:

$ GIT_CURL_VERBOSE=1

$ curl -v --ntlm -u : http://tfsserver:8080/tfs/DefaultCollection/code/_git/MyApp -o 1.html 2> out.txt

$ curl -v --ntlm -u : http://:@tfsserver:8080/tfs/DefaultCollection/code/_git/MyApp -o 2.html 2> out2.txt

文件1.html和2.html似乎代表了浏览器中的存储库网页，因此两个curl命令均成功.

The files 1.html and 2.html seem to represent the web page of the repository as in the browser, so both curl commands are successful.

输出文件out.txt和out2.txt非常相似，区别在于时间戳，引导和加密字符串.因此，这里是out.txt(我可以自由删除空行并擦洗一些字符串):

The output files out.txt and out2.txt are very similar, the differences are in timestamps, guids and crypto strings. So, here is out.txt (I took the liberty to remove empty lines and scrub a few strings):

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.17.155...* TCP_NODELAY set* Connected to tfsserver (192.168.17.155) port 8080 (#0)* Server auth using NTLM with user ''> GET /tfs/DefaultCollection/code/_git/MyApp HTTP/1.1
> Host: tfsserver:8080
> Authorization: NTLM ***SCRUBBED***
> User-Agent: curl/7.60.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Content-Type: text/html; charset=us-ascii
< Server: Microsoft-HTTPAPI/2.0
< WWW-Authenticate: NTLM ***SCRUBBED***
< Date: Thu, 15 Nov 2018 23:07:58 GMT
< Content-Length: 341
<
* Ignoring the response-body{ [341 bytes data]
100   341  100   341    0     0    642      0 --:--:-- --:--:-- --:--:--   642* Connection #0 to host tfsserver left intact* Issue another request to this URL: 'http://tfsserver:8080/tfs/DefaultCollection/code/_git/MyApp'* Found bundle for host tfsserver: 0x4116f20 [can pipeline]* Re-using existing connection! (#0) with host tfsserver* Connected to tfsserver (192.168.17.155) port 8080 (#0)* Server auth using NTLM with user ''> GET /tfs/DefaultCollection/code/_git/MyApp HTTP/1.1
> Host: tfsserver:8080
> Authorization: NTLM ***SCRUBBED***
> User-Agent: curl/7.60.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Expires: -1
< Server: Microsoft-IIS/8.5
< X-TFS-ProcessId: e5b67424-832f-468b-8787-c7c05aef5396
< ActivityId: 50f62941-8163-4ee9-9c2b-81359ca72838
< X-TFS-Session: 50f62941-8163-4ee9-9c2b-81359ca72838
< X-VSS-E2EID: 50f62941-8163-4ee9-9c2b-81359ca72838
< X-FRAME-OPTIONS: SAMEORIGIN
< X-VSS-UserData: 34be4ed8-c4fd-4e9f-bdae-d1843df36b0f:mkharitonov
< X-AspNetMvc-Version: 4.0
< X-AspNet-Version: 4.0.30319
< Set-Cookie: __RequestVerificationToken_L3Rmcw2=***SCRUBBED***; path=/; HttpOnly
< Set-Cookie: __RequestVerificationToken27563503a-8c73-4ee0-8930-e1f466b255f5=***SCRUBBED***; path=/; HttpOnly
< Persistent-Auth: true
< X-Powered-By: ASP.NET
< P3P: CP="CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT"
< Lfs-Authenticate: NTLM
< X-Content-Type-Options: nosniff
< Date: Thu, 15 Nov 2018 23:07:58 GMT
< Content-Length: 120608
<
{ [183 bytes data]
100  117k  100  117k    0     0   167k      0 --:--:-- --:--:-- --:--:--  167k* Connection #0 to host tfsserver left intact

推荐答案

我无法验证到最后，但是您可能应该在以下位置将 http.emptyAuth 设置为 true 配置(命令 git config --global http.emptyAuth true ).至少在设置它之后，我的git 2.19.1.windows.1已经向发布此协议的服务器发送了 Authorization:Negotiate ... 标头到服务器.

I cannot verify it to the end, but probably you should set http.emptyAuth to true in config (command git config --global http.emptyAuth true). At least after setting it my git 2.19.1.windows.1 has sent a Authorization: Negotiate ... header to a server which advertises this protocol.

底线:

git config --global http.emptyAuth true

如果LFS不在图片中，请执行此操作.如果涉及LFS，则在主机名前添加:@ ，例如

Does it if LFS is not in the picture. If LFS is involved, then prepend the host name with :@, e.g. 

http://:@tfsserver:8080/tfs/DefaultCollection/code/_git/MyApp

这篇关于是否可以使用默认的Windows凭据以非交互方式对远程Git存储库进行身份验证?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

1403页，肝出来的..

09-06 22:22
Powered by LMLPHP ©2025 可以使用默认的Windows凭据以非交互方式对远程Git存储库进 0.038659