Thanks for the hint to use bitbucket.

I can see the failure if I configure a credential with a username and password for a private bitbucket git repository. If the bitbucket repository is public (which I had been using before), then the clone succeeds. More exploration will be required.

I don't see the same failure if I configure a credential with a username and password for a private github repository. Public github repositories also do not show any issue.

Posting a link to my earlier (wire) analysis on this (the bug is not directly related, but for me is dependent on getting this issue fixed): JENKINS-20939 12/Mar/14 3:44 AM

It appears that the authentication handshaking has changed since the earlier HTTP library

I finally had some time to dig into this.

What caused the problem for me was that when you copy the https address from a private repository on bitbucket it is displayed as:

https://username@bitbucket.org/username/repo.git

and for a public repo it is:

https://bitbucket.org/username/repo.git

Removing the `username@` from the url in the jenkins setup, fixes the problem for private repos.

A fix that would allow either format would be to strip the username@ from the url in the `checkCredentials()`: https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L1854

e.g something like this:

diff --git a/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java b/src/main/java/org/jenkins
index 9fd48ab..feb95d2 100644
--- a/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
+++ b/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
@@ -1843,6 +1843,7 @@ public class CliGitAPIImpl extends LegacyCompatibleGitAPIImpl {
      */
     private void checkCredentials(URIish u, StandardCredentials cred) {
         String url = u.toPrivateString();
+        url = url.replaceAll("[\\w]+@", "");
         final HttpClientBuilder clientBuilder = HttpClients.custom();
         final CredentialsProvider credentialsProvider = new BasicCredentialsProvider();
         clientBuilder.setDefaultCredentialsProvider(credentialsProvider);

I would expect that change to break several other use cases (like the ssh use case I use to push changes back to a GitHub repository). I think users will need to use the work around for the problem case you described (butbucket https URL's behave better without the username embedded in the URL).

checkCredentials() seems to only deal with HTTP so I can't see how that would affect ssh?

I just found this bug report as my credentials stopped working with my private bitbucket repo. Removing the @username from the url fixed it.

This is quite confusing as this was working before and the behavior of the credentials changed between 1.6.3 and 1.6.4
If the @username can not be stripped, you could perhaps add a hint in the error message telling the user to try without the @username ?

I am facing the same issue not able to connect to repository.
Git client plugin version is 1.10.2 and git plugin 2.2.5

I had restored jenkins using thin backup plugin after formatting the mac. Previously everything was working fine but not its not able to connect.

The call to checkCredentials() has been removed in git-client-plugin from 1.13.1 and beyond. Would you be willing to test a pre-release of git-client-plugin 1.13.1 for this case?

The git-client-plugin 1.14.0 release allows me to fetch and push from a private bitbucket repository using command line git.

I thought I had a problem with GitHub private repository access through https until I read the GitHub documentation which states that https access to a private repository must use a personal access token. Once I generated and used a personal access token in the credential, it worked as expected.