Home » Eclipse Projects » EGit / JGit » Authentication failure trying to access a TFS git repo
| Authentication failure trying to access a TFS git repo [message #1765071] |
Tue, 06 June 2017 11:37  |
|
When trying to fetch from a TFS git repo (HTTPS), I get the following error:
org.eclipse.jgit.api.errors.TransportException: https://tfs.corilus.be/tfs/Corilus/_git/CareConnect: cannot open git-upload-pack
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:135)
at org.eclipse.jgit.api.PullCommand.call(PullCommand.java:280)
at org.eclipse.egit.core.op.PullOperation$1.run(PullOperation.java:200)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2240)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
at org.eclipse.egit.core.op.PullOperation.execute(PullOperation.java:232)
at org.eclipse.egit.ui.internal.pull.PullOperationUI.execute(PullOperationUI.java:176)
at org.eclipse.egit.ui.internal.pull.PullOperationUI.access$0(PullOperationUI.java:168)
at org.eclipse.egit.ui.internal.pull.PullOperationUI$1.runInWorkspace(PullOperationUI.java:141)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.eclipse.jgit.errors.TransportException: https://tfs.corilus.be/tfs/Corilus/_git/CareConnect: cannot open git-upload-pack
at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:551)
at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:311)
at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1201)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:128)
... 10 more
Caused by: java.io.IOException: Authentication failure
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1733)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
at org.eclipse.jgit.transport.http.JDKHttpConnection.getResponseCode(JDKHttpConnection.java:98)
at org.eclipse.jgit.util.HttpSupport.response(HttpSupport.java:196)
at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:489)
... 15 more
One of my colleagues has the same problem, another one has no issues. I have not been able to detect any differences in setup.
From the line number in the stack trace, it appears as if EGit/JGit wants to use NTLM authentication, even though Basic authentication is supported by our TFS (we're using personal access tokens in TFS for basic authentication). In any case, no combination of authentication credentials (NTLM account, personal access token, bogus values, ...) works, or gives a different error message for that matter.
Does anyone have any idea what may trigger this error, or why it only happens for 2 out of 3 people?
Cheers,
Dennis
|
|
|
| Re: Authentication failure trying to access a TFS git repo [message #1765122 is a reply to message #1765071] |
Tue, 06 June 2017 20:44  |
 Thomas Wolf
Messages: 576
Registered: August 2016 |
Senior Member |
|
|
JGit and TFS apparently don't play well together :-(
Dennis Wagelaar wrote on Tue, 06 June 2017 11:37
From the line number in the stack trace, it appears as if EGit/JGit wants to use NTLM authentication
I read the stack trace a bit differently. JGit will try GSS/SPNEGO, Digest, and Basic authentication in that order, and finally tries with a NONE policy. It doesn't do NTLM (unless the JDK's HttpUrlConnection would try that on its own when JGit doesn't explicitly set its authentication headers?) . The exception you see is raised when none of the authentication methods succeed. Your server advertises Bearer, Basic, Negotiate, and NTLM. (Negotiate would be GSS/SPNEGO).
The only reason I see why Basic authentication might fail is perhaps that JGit always encodes the username:password as UTF-8. What does TFS expect? RFC 7617 specifies an optional charset parameter; if not sent, the encoding is unspecified. TFS doesn't send one, and JGit would ignore it anyway.
So if JGit encodes as UTF-8 but the TFS server expects something else like Cp1252 and the username or password contain non-ASCII characters, Basic authentication might fail.
The other issue is why GSS/SPNEGO, which should be tried first, doesn't succeed. Compare https://bugs.eclipse.org/bugs/show_bug.cgi?id=501167 . This could be a Kerberos configuration problem, or it might perhaps be a problem with JGit's way of trying to do SPNEGO authentication.
|
|
|
| Re: Authentication failure trying to access a TFS git repo [message #1765156 is a reply to message #1765122] |
Wed, 07 June 2017 07:10 |
|
Thanks for your reply! To clarify, our usernames don't contain special characters. Also, I've tested this problem with my colleague who DOESN'T have problems with EGit/TFS: he can pull and push just fine, even with my credentials. I've even put a snapshot of my Eclipse installation on his PC, and it works for him. We've both installed the same version of standalone git on our PCs (which are both up-to-date WIndows 10 installations), such that the System Settings in the EGit preferences panel matches. We're both running JDK 1.8.0_131 x64.
Cheers,
Dennis
|
|
| | | | |
| Re: Authentication failure trying to access a TFS git repo [message #1765285 is a reply to message #1765269] |
Thu, 08 June 2017 07:29 |
|
Thomas Wolf wrote on Thu, 08 June 2017 00:01Is the non-working log really complete? There's nothing at all after having received the server's 401 with the NTLMSSP_CHALLENGE header.
Yes, that suprised me as well: it just "stops". I've retried the git fetch, but that just generates the same log, and it stops again.
Cheers,
Dennis
|
|
|
| Re: Authentication failure trying to access a TFS git repo [message #1765397 is a reply to message #1765285] |
Fri, 09 June 2017 08:16 |
Thomas Wolf
Messages: 576
Registered: August 2016 |
Senior Member |
|
|
Dennis Wagelaar wrote on Thu, 08 June 2017 07:29Yes, that suprised me as well: it just "stops". I've retried the git fetch, but that just generates the same log, and it stops again.
Very strange. Here's what I see in these logs:
It's not the _final_ NONE request but the _initial_ NONE request triggered by the first call to HttpUrlConnection.getResponseCode() that triggers all the JDK-internal authentication machinery by calling getInputStream(), which then calls getInputStream0().
Looking at the working log:
That then gets back the 401, and HttpUrlConnection tries to transparently do the authentication stuff.
It finds the Negotiate header. Kerberos or SPNEGO don't seem to be configured in your setup; somehow that fails right away: the JDK cannot even instantiate its Negotiator due to an InvocationTargetException. If you set the system property "sun.security.krb5.debug" to "true", you should get a stack trace on stderr showing where that comes from. But probably it just means that Kerberos is not configured at all.
Next the JDK tries NTLM. In both the working and the non-working log, it cannot authenticate. In the non-working case, it just stops after first 401 gotten after the initial NTLM attempt. So it's not Basic auth that fails: neither the JDK nor JGit ever get there!
In the working case, NTLM authentication proceeds, but ultimately fails and gets a 401 again. HttpUrlConnection then retries and strangely enough gets a null NTLM authentication scheme, which then of course results in another 401. Only then it re-tries NTLM, but ultimately fails again and gets another 401. It then gets another null NTLM scheme and this time tries Basic and succeeds.
Now there's a couple of strange things in the log of the working case, too:
* Why does the JDK re-try NTLM the first time it gets a null scheme, but tries Basic the second time?
* Why does it get a null scheme at all?
* Why does NTLM not succeed? https://bugs.openjdk.java.net/browse/JDK-8033773 ?
And of course it's utterly unclear to me why in the non-working log there's nothing anymore after having received the initial NTLM 401 with the server's NTLMSSP_CHALLENGE header.
But in any case all this appears to happen in the JDK, before even JGit's own retry mechanisms could kick in.
I also see in the code that if this initial NONE request raises an IOException (even if it's an authorization failure), JGit's own retry mechanism will never kick in. That appears to happen in the non-working case, right in the middle of an NTLM authorization attempt.
|
|
| | | | |
Goto Forum:
Current Time: Fri Apr 19 19:38:38 GMT 2024
Powered by FUDForum. Page generated in 0.05050 seconds |
] 
Search
Help
Register
Login
Home
