Git: cloning a repository with automatic windows authentication doesn't work anymore

Created on 17 May 2017 · 11Comments · Source: git-for-windows/git

Cloning a repository which is protected with kerberos (windows authentication) doesn't work anymore.
This did work in the past. I now updated my git for windows client and now it doesn't work anymore. I think my old version was 1.9.4 but I'm not sure and I don't have the old installer anymore. I have to say that it is a pretty long time since I last used git for windows with a kerberos protected repository.

curl --negotiate -u : http://myserver.net/myrepo does work

[x] I was not able to find an open or closed issue matching what I'm seeing

All related issues I found are marked as resolved.

Setup

Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.13.0.windows.1
built from commit: eba7af3dbb4c846c6303c5f64102acee696c9ab0
sizeof-long: 4
machine: x86_64

Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

What options did you set as part of the installation? Or did you choose the
defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Disabled
Enable Symlinks: Disabled

Any other interesting things about your environment that might be related
to the issue you're seeing?

Details

Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

What commands did you run to trigger this issue? If you can provide a
Minimal, Complete, and Verifiable example
this will help us understand the issue.

git clone http://:@myserver.net/myrepo

What did you expect to occur after running these commands?

a successful clone

What actually happened instead?

fatal: Authentication failed for http://:@myserver.net/myrepo

bug git-upstream

Source

domruf

Most helpful comment

@dscho sure, will do.

leitec on 6 Apr 2018

👍2

All 11 comments

That's a little scarce information. No chance for me to help. Maybe you can help yourself further after setting GIT_TRACE_CURL=1.

dscho on 29 May 2017

I did try it with GIT_TRACE_CURL=1 but that did help much.

10:56:15.498475 http.c:638 10:56:15.499475 http.c:638 10:56:15.511477 http.c:638 10:56:15.511477 http.c:638 10:56:15.537479 http.c:638 10:56:15.538479 http.c:585 10:56:15.538479 http.c:597 10:56:15.538479 http.c:597 10:56:15.538479 http.c:597 10:56:15.538479 http.c:597 10:56:15.538479 http.c:597 10:56:15.538479 http.c:597 10:56:15.538479 http.c:597 10:56:15.544480 http.c:585 10:56:15.544480 http.c:597 10:56:15.544480 http.c:585 10:56:15.544480 http.c:597 10:56:15.544480 http.c:585 10:56:15.544480 http.c:597 10:56:15.545480 http.c:585 10:56:15.545480 http.c:597 10:56:15.545480 http.c:585 10:56:15.545480 http.c:597 10:56:15.545480 http.c:585 10:56:15.545480 http.c:597 10:56:15.545480 http.c:585 10:56:15.545480 http.c:597 10:56:15.545480 http.c:585 10:56:15.545480 http.c:597 10:56:15.545480 http.c:585 10:56:15.545480 http.c:597 10:56:15.545480 http.c:611 10:56:15.545480 http.c:626 ... 10:56:15.545480 http.c:638 == Info: Couldn't find host myserver.net in the _netrc file; using defaults == Info: timeout on name lookup is not supported == Info: Trying 10.20.30.40... == Info: TCP_NODELAY set == Info: Connected to myserver.net (10.20.30.40) port 80 (#0) => Send header, 0000000179 bytes (0x000000b3) => Send header: GET /myrepo/info/refs?service=git-upload-pack HTTP/1.1 => Send header: Host: myserver.net => Send header: User-Agent: git/2.13.0.windows.1 => Send header: Accept: */* => Send header: Accept-Encoding: gzip => Send header: Pragma: no-cache => Send header: <= Recv header, 0000000037 bytes (0x00000025) <= Recv header: HTTP/1.1 401 Authorization Required <= Recv header, 0000000037 bytes (0x00000025) <= Recv header: Date: Wed, 31 May 2017 08:56:15 GMT <= Recv header, 0000000016 bytes (0x00000010) <= Recv header: Server: Apache <= Recv header, 0000000029 bytes (0x0000001d) <= Recv header: WWW-Authenticate: Negotiate <= Recv header, 0000000023 bytes (0x00000017) <= Recv header: Vary: Accept-Encoding <= Recv header, 0000000024 bytes (0x00000018) <= Recv header: Content-Encoding: gzip <= Recv header, 0000000021 bytes (0x00000015) <= Recv header: Content-Length: 900 <= Recv header, 0000000025 bytes (0x00000019) <= Recv header: Content-Type: text/html <= Recv header, 0000000002 bytes (0x00000002) <= Recv header: <= Recv data, 0000000900 bytes (0x00000384) <= Recv data: ... == Info: Connection #0 to host myserver.net left intact`

I also looked at the server log file and there is no further request from the client after the server has send the WWW-Authenticate: Negotiate response.

domruf on 31 May 2017

git clone http://:@myserver.net/myrepo

Can you try without the :@ hack? I.e.

git clone http://myserver.net/myrepo

(Newer Git versions use the Negotiate header as an indicator that empty credentials should be sent unless credentials were already provided.)

dscho on 1 Jun 2017

I do use the newest version 2.13.0.windows.1

When I don't use the :@ hack, I get a Username prompt

Cloning into 'myrepo'... 12:24:10.432692 http.c:638 == Info: Couldn't find host myserver.net in the _netrc file; using defaults 12:24:10.433692 http.c:638 == Info: timeout on name lookup is not supported 12:24:10.442692 http.c:638 == Info: Trying 10.20.30.40... 12:24:10.442692 http.c:638 == Info: TCP_NODELAY set 12:24:10.468692 http.c:638 == Info: Connected to myserver.net (10.20.30.40) port 80 (#0) 12:24:10.469692 http.c:585 => Send header, 0000000187 bytes (0x000000bb) 12:24:10.469692 http.c:597 => Send header: GET /myrepo/info/refs?service=git-upload-pack HTTP/1.1 12:24:10.469692 http.c:597 => Send header: Host: myserver.net 12:24:10.469692 http.c:597 => Send header: User-Agent: git/2.13.0.windows.1 12:24:10.469692 http.c:597 => Send header: Accept: */* 12:24:10.469692 http.c:597 => Send header: Accept-Encoding: gzip 12:24:10.469692 http.c:597 => Send header: Pragma: no-cache 12:24:10.469692 http.c:597 => Send header: 12:24:10.646692 http.c:585 <= Recv header, 0000000037 bytes (0x00000025) 12:24:10.646692 http.c:597 <= Recv header: HTTP/1.1 401 Authorization Required 12:24:10.646692 http.c:585 <= Recv header, 0000000037 bytes (0x00000025) 12:24:10.646692 http.c:597 <= Recv header: Date: Tue, 13 Jun 2017 10:24:10 GMT 12:24:10.646692 http.c:585 <= Recv header, 0000000016 bytes (0x00000010) 12:24:10.646692 http.c:597 <= Recv header: Server: Apache 12:24:10.648692 http.c:585 <= Recv header, 0000000029 bytes (0x0000001d) 12:24:10.648692 http.c:597 <= Recv header: WWW-Authenticate: Negotiate 12:24:10.648692 http.c:585 <= Recv header, 0000000019 bytes (0x00000013) 12:24:10.648692 http.c:597 <= Recv header: Content-Length: 0 12:24:10.648692 http.c:585 <= Recv header, 0000000002 bytes (0x00000002) 12:24:10.648692 http.c:597 <= Recv header: 12:24:10.648692 http.c:638 == Info: Connection #0 to host myserver.net left intact Username for 'http://myserver.net': ^C

domruf on 13 Jun 2017

Hello,

I am seeing the same problem with the same symptoms as @domruf:

https://:@our.server.here/ results in a failed HTTP Basic attempt
https://our.server.here/ results in a username/password dialog
curl -u : --negotiate https://our.server.here/ from Git Bash seems to authenticate, although I tested against another Kerberos-enabled HTTP service

I can add that I tracked this down to changes between 2.10.1 and 2.10.2. 2.10.1 is the last functioning release that I could find. I tested up to 2.13.1.2.

leitec on 16 Jun 2017

Setting http.emptyauth to true resolved the problem with our server. The auto setting did not work.

This was documented here (and elsewhere): https://github.com/Microsoft/Git-Credential-Manager-for-Windows/issues/337

leitec on 13 Sep 2017

The auto setting did not work.

Hrm. This is unsettling, as your trace shows:

12:24:10.648692 http.c:597 <= Recv header: WWW-Authenticate: Negotiate

In https://github.com/git-for-windows/git/blob/v2.14.1.windows.1/http.c#L131-L137 we specifically list only Basic and Digest as useless for empty authentication, not Negotiate, and later the curl_empty_auth_enabled() function tests the list of authentication methods received from the server whether we should go ahead and try empty credentials.

Since I have not been given any chance to reproduce this here (which has the upside of not putting more load on me, so all is good), maybe you can recompile Git using Git for Windows' SDK after adding debug print statements showing the values of curl_empty_auth, http_auth_methods_restricted, http_auth_methods and empty_auth_useless at the beginning of the curl_empty_auth_enabled() function, then call the compiled Git (using /usr/src/git/git --exec-path=/usr/src/git -c http.emptyauth=auto ...).

dscho on 15 Sep 2017

@domruf @leitec what is the state of this? Did some incidental bug fix happen? Or does the bug still show for v2.17.0?

dscho on 4 Apr 2018

Sorry @dscho, I missed your response from September. I haven't had a chance to try building from source, so I tested with the latest binary, 2.16.2. I still see the problem when http.emptyauth is not set to true.

However, I can now also reproduce the behavior on a Linux host, so as far as I can tell this is not a Git for Windows problem.

leitec on 4 Apr 2018