Authentication not supported error while pushing project to remote TFS server - eclipse

I am trying to push my code from Eclipse to git in my organisation TFS(Team Foundation Server).
I have followed the link https://www.visualstudio.com/en-us/docs/git/share-your-code-in-git-eclipse to push the code.
But while pushing the branch to tfs server I am getting error.
org.eclipse.jgit.errors.TransportException: http://***.*******.*******.***:****/tfs/****/****/**********/***/********: authentication not supported
at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:488)
at org.eclipse.jgit.transport.TransportHttp.openPush(TransportHttp.java:387)
at org.eclipse.jgit.transport.PushProcess.execute(PushProcess.java:154)
at org.eclipse.jgit.transport.Transport.push(Transport.java:1200)
at org.eclipse.egit.core.op.PushOperation.run(PushOperation.java:197)
at org.eclipse.egit.ui.internal.push.ConfirmationPage$2.run(ConfirmationPage.java:209)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
I have tried various ways to find a perfect solution but till now I have not found any. Can anyone help me with this.
Also would like to highlight the tfs remote repository already has a readme.md file, would that cause any issue while pushing the code. If yes can anyone provide a viable solution.
Note :- I need the solution which I can use in Eclipse to solve this issue.

The possible solutions to your problem are explained in the FAQ:
the reason is that NTLM authentication is not supported by the JGit plugin of Eclipse, which is used indirectly by Team Explorer Everywhere (aka TEE) by means of EGit.
Possible solutions with TFS 2015 RTM and up:
enable HTTP Basic Authentication on TFS (within IIS); this is a server side change;
use CNTLM to overcome the limitation of JGit and use properly the NTLM authentication; this is a client side modification you could do on your Eclipse installation;
enable Kerberos authentication in IIS on your TFS server, as explained in the above mentioned FAQ as well; this is already the default on TFS 2017+.
With TFS 2017 RTW and up you could create a Personal Access Token with scope at least Code (read and write), then you could use it instead of your password in the Eclipse EGit configuration.

Install TortoiseGit, do Pull... and Push.... Try again in Eclipse. Worked for me.

Related

GitHub Copilot - please login to github and try again

For Intellij plugin, GitHub Copilot shows error please login to github and try again.
I have already done the following:
Authenticated GitHub Copilot with my GitHub user and password.
Allowed GitHub Copilot in GitHub account profile.
Restarted the IDE multiple times after the plugin installation.
I have license for Github Copilot.
What should I do to resolve this error?
You have multiple discussion reporting this error.
discussions 18132 includes:
Behind corporate proxy. Used latest stable version with CLion 1.1.28.1744 and added -Dcopilot.agent.disabled=true to Custom VM properties.
Also delete github-copilot.local.xml and github-copilot.xml in .config/JetBrains/CLion2022.2/options.
This has since been answered by GitHub staff member Benjamin Muskalla (Aug. 11th, 2022):
We’re happy to announce that the latest release of Copilot for Visual Studio Code and Copilot for IntelliJ contains preliminary support for connecting through HTTP proxy servers.
The current version supports basic HTTP proxy setups, with and without basic authentication.
For Jetbrains IntelliJ
Ensure you have Copilot for IntelliJ 1.1.29.1869 or higher installed in your IDE.
Setup the HTTP proxy in your Preferences.
Restart your editor so the proxy configuration is applied correctly to all components requiring connections via the proxy.
For Visual Studio Code
Ensure you have Copilot for VS Code 1.39.6432 or higher installed in your editor.
To set up your proxy, go to your VSCode Settings and ensure your HTTP proxy configuration is set up properly.
Alternatively, Copilot uses the http_proxy and https_proxy variables from your environment.
Restart your editor so the proxy configuration is applied correctly to all components requiring connections via the proxy.

Unable to clone git repository in Eclipse using https and SSH links

While trying to clone a Git repository in Eclipse Luna, I'm getting the error shown below using the https link:
I added the said values in the Git configuration using this link - "SSL host could not be verified" error but I'm still getting the same error.
I'm sure that the URL is correct. Not too sure if there's something wrong with proxy settings (I don't think so).
On the other hand, I tried the ssh link by generating keys and putting them into the enterprise gitlab account and also on the pc (windows) but I'm still being unsuccessful doing that and getting the same error shown in the image below except for the last point.
I checked the error log, while using the https link it says 'not authorized' and 'Auth fail' when I try to use the ssh link.
I'm listed as the member of the repository and I'm using my email and password of the enterprise account to access it, but no luck.
Help much appreciated. Thank you.
First, if you are using a private GitHub Enterprise in an enterprise, SSH URLS are rarely allowed.
For HTTPS URLs, you need to make sure your proxy configuration ignore host setting in Eclipse includes the domain name of the GitHub Enterprise (on premise) private server, or it will try to contact the proxy every time (and fail)
I have face same problem. To resolve this problem make sure your repository access level is public. It will solve this issue.
Assuming that your company uses their own certificate authority, their root certificate has most probably been added to your computer's trust store. However, Java by default uses its own trust store, so Eclipse does not know about it.
The best solution is to make Eclipse use the system trust store. See this answer for Windows or this answer for macOS.

Eclipse with TFS plugin - endless login loop

I have a problem in eclipse with the tfs plugin. I try to login and it stuck in some kind of login loop.
I looked here and in google. Nothing help.
I found this posts:
Eclipse with TFS plugin - looping login
http://social.msdn.microsoft.com/Forums/vstudio/en-US/5e3f8b3a-d623-4401-b9f1-50f1f52ab299/eclipse-tfs-plugin-keeps-signing-in-in-loop-followed-by-there-were-some-problems-message
I tried to clean cookies and password and everything possible in IE
I reinstalled the plugin. I updated everything possible, checked for eclipse indigo last version (3.2.7)
Nothing worked. Anyone can help me?
The forum posts you referenced are about the Team Foundation Service, not the on-premise server. Since the service uses Microsoft Accounts (previously known as Live Id's) it depends on cookies in your browser.
The on-premise version of Team Foundation Server uses your domain account which isn't stored as a cookie, but which is stored in the Windows Credentials Vault by default for Windows processes. Try going through the stored credentials to make sure your username/password or TFS server isn't mentioned there. If it is, either update it or remove it.
Can you verify whether the same account settings are correctly picked up by Visual Studio/Team Explorer (if you have it installed on the same machine)? Eclipse and Team Explorer should use the same credential vault.

EGit Clone Does not work

I can clone from command line but not via EGit (Eclipse). Extensive Googling did not yield an answer. This has been asked many times before, and I tried pretty much everything suggested.
I keep getting" cannot open git-upload-pack". Yes, I can clone from command line and then import. Then commit via Eclipse and push from command line. I have been doing so for a while now. Everything except pull and push works. Is this functionality just broken?
if you are sitting behind a proxy check your Eclipse proxy settings
any errors in the Eclipse error log ?
EGit 1.3.0 can definitively clone over https
what kind of http authentication does your git server want ? JGit/EGit at the
moment only supports basic and digest authentication
is your server using a self-signed SSL certificate ? Then you either need to
tell Java (on the EGit end) that it should trust this certificate or switch
off the SSL certificate using the git configuration parameter https.verify=false
The following describes the issue. There is no solution.
http://code.google.com/p/gitblit/issues/detail?id=4
EGit/JGit 3.0.0 now properly ignores hostname verification failures if http.sslVerify=false. This matches the behavior of native git.
The previous workaround was to generate a new self-signed, SSL certificate for the ip address/hostname you wished to serve on.
Another issue we came across: if you have an instance of Fiddler running, then it will (in effect) put a proxy between you and the outside world.
Kill Fiddler or limit what HTTPS trafic is decrypted by Fiddler for GIT to work correctly.

Nuget Server returning 403's and 404's

I'm trying to host nuget on my Amazon EC2 VPS, and I'm having issues.
I've followed the instructions here ( Hosting your own NuGet Feeds )
I've read this thread ( NuGet: remote server returned an Error(403) Forbidden ) along the same lines.
I'm not running TFS
It "could" be a proxy issue, but I'm not entirely sure how to check.
My NuGet feed is located at http://nuget.infinitas.ws. You'll notice that both http://nuget.infinitas.ws/nuget/Packages and http://nuget.infinitas.ws/Packages are throwing errors.
Any help with this will be greatly appreciated.
You are probably running the NuGet.Server in a Web Site-project. Try to run it via an ASP.NET Web Application instead (in Visual Studio you can create one via File -> New -> Project -> ASP.NET Web Application)
Have you tried the latest version (1.5)?
The release notes include some changes related to proxy authentication:
Support for Proxies that require authentication
When using NuGet behind a proxy that requires authentication, NuGet will now prompt for proxy credentials. Entering credentials allows NuGet to connect to the remote repository.
I realize I'm a little late to the party but I've just spent a frustrating couple of hours with the same problem.
I found that switching the Application Pool from "Classic" to "Integrated" fixed the problem