Embedding the user name and password in the URL directly will expose your user name and password in the job definition and may expose it in the job log. If you'll enter a credential with that same user name and password, you can then reference that credential without having the user name or the password visible in the job definition or in the console log from the build.

I agree that the plugin should also accept the user name and password embedded in the URL, but it does not currently. The work around of entering the user name and password as a credential is workable, and is more secure.

The more I look at this report, the less confident I am that I understand what is requested.

I'm able to clone with a username / password credential without using public / private keys with the following steps:

1. Configure a global username / password credential (through "Manage Credentials") with appropriate user name and password (no public key, no private key)
2. Create a new freestyle job - JENKINS-22909-username-password-credentials
3. Use git as the SCM for the job
4. Use an ssh URL for the repository. I used ssh://mwaite@mark-pc1.markwaite.net/var/lib/git/mwaite/bin.git
5. Use the previously defined username / password credential as the credential for that ssh URL
6. Run the job, confirm it succeeds

I suspect that my clone succeeds through an accident in that case. The accident is that my jenkins user is likely allowed to access that repository as user mwaite through ssh by default. When I run in a "clean" environment, username/password authentication fails for an ssh protocol URL unless I also use a private key.

Are there more steps you're taking to show the problem?

Have you used a more recent git client plugin and a more recent git plugin?

The issue is reproduced n number of times.

Still able to reproduce this with the latest available versions:
Jenkins ver. 1.644
Credentials Plugin 1.24
Git plugin 2.4.1
Git client plugin 1.19.1

I used RHEL 7.2 (x86_64) with openssh:
openssh.x86_64 6.6.1p1-23.el7_2
openssl.x86_64 1:1.0.1e-51.el7_2.2

In all my recent tests of credentials, I've never seen a case where an ssh URL was able to authenticate with a user name and password. When using an ssh URL, the plugin seems to expect that you are using a private key for authentication, rather than user name and password.

I'm not sure if this is related, however it sound's very similar: https://issues.jenkins-ci.org/browse/JENKINS-24368?focusedCommentId=246537&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-246537

jimklo I don't think they are related, since I believe they use different paths through the code for ssh based authentication and https based authentication. JENKINS-24368 is specific to https. (and seems to be specific to bitbucket) I can connect to a bitbucket repo with ssh, just not with https in certain configurations.

I do not want to sound pushy, but this issue was created since May 2014 and its now March 2016. Can someone that is responsible for resolving this bug give an indication as to when it will be resolved? Thanks!

jaswo I'm probably the only one that is close to "responsible for resolving this bug", so I'll give you my estimate. I don't know that it will be resolved any time within the next few years. A private key works quite well with ssh protocol, so I perceive there is a relatively simple work around to allow access to ssh protected git repositories.

I'm currently focused on other areas, like adding authenticated submodule access, and like processing the ~50 pull requests pending on the git plugin, and the ~5 pull requests pending on the git client plugin.

My first goal is to not regress functionality for the existing 70000+ installations of the plugin. I'd love to have additional help from others evaluating the pull requests, and submitting proposed improvements (fixes or features) with tests to support those additions. I'd also love to have additional automated tests for the existing features.

I have just encountered the same issue but happens only on Windows Slave if using SSH username thus credentialsID with the git plugin. On Linux Slave works, and as said it also works with ssh keys. So my workaround was to go with the ssh keys.

Won't implement this enhancement request.