[JENKINS-41715] Git credentials selection + git ls-remote test of config is wonky

There's something goofy going on. When configuring a job to reference a Git repository, and choosing an associated SSH+Key credential for access, we're seeing the following after choosing the right credential. However, ignoring this red error in the UI, saving the job configuration, and using those configured credentials works fine. More strangeness described after the error below:

Failed to connect to repository : Command "git ls-remote -h git@​gitlab.our.org:r701-cookbooks/r701-redhat-subs.git HEAD" returned status code 128:

stdout:

stderr: Permission denied, please try again.

Permission denied, please try again.

Received disconnect from xx.xx.10.102: 2: Too many authentication failures for git

fatal: The remote end hung up unexpectedly

This is of course gives users the idea that their credentials are wrong or broken, so they then go off wasting time on something that isn't a problem.

The other strangeness, is that if we see this error (before saving), and try to "re-toggle" our right credentials by selecting "-- none --", the UI resets the selection to the credentials we'd previously set.

That is:

1. Brand new job


2. Chose "Git"


3. Type repo as git@​gitlab.our.org:whatever/our-repo.git


4. Change '-- none --' credential to 'jblaine Gitlab SSH key'


5. Red error shown above shows. If we saved right now, the 'jblaine Gitlab SSH key' credentials chosen would in fact work fine to do the clone during the job build.


6. Change 'jblaine Gitlab SSH key' credential selection to '-- none --'


7. It immediately gets set back to 'jblaine Gitlab SSH key'


8. Change 'jblaine Gitlab SSH key' credential selection to '-- none --'. It STAYS this time.


9. Change '-- none --' credential to 'jblaine Gitlab SSH key'


10. Get the red error above...


11. Give up and click Save.


12. Build job. It works fine.

---
Originally reported by jblaine, imported from: Git credentials selection + git ls-remote test of config is wonky

• status: Open
  
• priority: Major
  
• component(s): git-client-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 2
  
• imported: 20251211-071809
  

Raw content of original issue

There's something goofy going on. When configuring a job to reference a Git repository, and choosing an associated SSH+Key credential for access, we're seeing the following after choosing the right credential. However, ignoring this red error in the UI, saving the job configuration, and using those configured credentials works fine. More strangeness described after the error below:


Failed to connect to repository : Command "git ls-remote -h git@gitlab.our.org:r701-cookbooks/r701-redhat-subs.git HEAD" returned status code 128:

stdout:

stderr: Permission denied, please try again.

Permission denied, please try again.

Received disconnect from xx.xx.10.102: 2: Too many authentication failures for git

fatal: The remote end hung up unexpectedly


This is of course gives users the idea that their credentials are wrong or broken, so they then go off wasting time on something that isn't a problem.


The other strangeness, is that if we see this error (before saving), and try to "re-toggle" our right credentials by selecting "-- none --", the UI resets the selection to the credentials we'd previously set.


That is:




	
Brand new job

	
Chose "Git"

	
Type repo as git@gitlab.our.org:whatever/our-repo.git

	
Change '-- none --' credential to 'jblaine Gitlab SSH key'

	
Red error shown above shows. If we saved right now, the 'jblaine Gitlab SSH key' credentials chosen would in fact work fine to do the clone during the job build.

	
Change 'jblaine Gitlab SSH key' credential selection to '-- none --'

	
It immediately gets set back to 'jblaine Gitlab SSH key'

	
Change 'jblaine Gitlab SSH key' credential selection to '-- none --'. It STAYS this time.

	
Change '-- none --' credential to 'jblaine Gitlab SSH key'

	
Get the red error above...

	
Give up and click Save.

	
Build job. It works fine.

environment

```
Git-Client Plugin 2.2.0 AND 2.2.1

Git Plugin 3.0.1

Jenkins 2.15 and Jenkins 2.32.2 both testing
```