Can you use the work around described in JENKINS-22694?

Register that user name and password in a credential, then use that credential in the job definition (rather than embedding the user name and password in the URL).

Alternately, can you use the work around of using an ssh URL to access that same repository instead of using an https URL?

Alternately, can you somehow include the username and password information in your downstream tasks using another technique?

Another possibility might be to try using JGit as the git implementation, instead of command line git.

As I stated in the bug I need to use this URL syntax, because of certain post build processors.

I tried the ssh URL and JGit, this are my test results:

Using JGit and https://
Failed to connect to repository : org.eclipse.jgit.errors.TransportException: https://username@bitbucket.org/user/repository.git: not authorized

Using JGit and git://
Failed to connect to repository : org.eclipse.jgit.errors.NotSupportedException: URI not supported: git://username@bitbucket.org/user/repository.git

Using JGit and ssh://
No error message, but the build runs in a endless loop.

Using Git command line and ssh://
Failed to connect to repository : Command "C:/Progra~2/Git/bin/git.exe -c core.askpass=true ls-remote -h ssh://username@bitbucket.org/user/repository.gitHEAD" returned status code 128:
stdout:
stderr: Unable to open connection:
Host does not existfatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists

I confirmed with git client plugin 1.16.1 and git plugin 2.3.5 that a private bitbucket repository with embedded user name and password fails to fetch. The remote.origin.url is correctly set in the workspace repository and is usable by "git remote update".

If I login to that slave, change directory to that repository and perform a "git remote update origin", the changes are fetched into the repository from the bitbucket URL.

I think that shows the problem is specific to a private bitbucket repository with https protocol and embedded user name and password from a Jenkins job. Change any one of those items (for example, use a credential instead of embedding the user name/password, or use a public bitbucket repository, or use a different protocol) and it seems to work. I realize none of those alternatives meet the needs of flaviodonze, but I now better understand the symptoms of the bug.

Also seeing this.
This may be a recurrence of this bug - JENKINS-20533.

nickcmaynard I don't think that it is a recurrence of JENKINS-20533, since that bug was fixed by deletion of a problematic code path, and that code path has definitely not been reintroduced.

Unfortunately, all that means is that I don't know where the bug is, only where it likely isn't.

I'm seeing this on a different host than Bitbucket - namely IBM's DevOps Services Git hosting.
The URLs for this look something like https://email%40domain.tld:password@hub.jazz.net/git/blah/blah

I've the same problem and in one case it appeared in jobs running on 'master'. What solved problem in this case was putting ssh key in <jenkins user home directory>/.ssh/id_rsa. So it seems it's a ssh access issue. What's bad - there are no records about the problem in jenkins log.

Now I have the second case. The same symptoms but on JClouds provided slaves and I wonder what should I do.

uvizhe I am surprised that you're having a problem which is specific to bitbucket and a username / password embedded directly in the URL. From other bug reports, it seems you're using GitHub Enterprise, not bitbucket.

Up to this time, I've only heard of this problem affecting bitbucket users, and only with the user name and password embedded directly into the URL.

If you resolved the issue by adding .ssh/id_rsa to the home directory of your Jenkins user, then you should also be able to use the Jenkins credentials plugin to insert that same private key into Jenkins, then reference that private key from the Git configuration within the specific job using that repository.