Hello Team,
I am new to Jenkins setup. I am observing a strange behavior while setting up a new job, where the Jenkins successfully authenticates a private git repository over SSH and does not return an error.
Ideally, with none credentials, the Jenkins should throw an error. However, surprisingly it got authenticated (at the time of configuring the job). Later when I ran the job (with “none” credentials) it also cloned the repository contents in my workspace folder and the job turned out to be successful.
I dont understand the reason behind this behavior
I want that:
=> the Jenkins should throw authentication error while connecting the bitbucket url when I specify “none” in the “credentials” section
=> the Jenkins should successfully authenticate the bitbucket url when I specify / select a valid “Jenkins” user.
Command line git and the JGit implementation inside Jenkins both honor the ssh configuration of the user that is performing the git operation. If the user that is performing the git operation has an ssh private key already configured that allows access to the remote repository, it will use that when no credentials are configured. Some Jenkins users choose to place ssh private key credentials for their repositories in the home directory of the user account that is running the Jenkins agent and the Jenkins controller.
When no credentials are specified, command line git falls back to check for credentials that already exist. I suspect in your case that the account running the Jenkins controller or the Jenkins agent has ssh private key credentials already available.
Hello Mark,
Thank you very much for your inputs. However, I apologize to not understand what exactly you meant.
I remember some days back, in my previous Jenkins installation, using the “none” credentials threw an error. However something wrong happened, and I was force to re - setup Jenkins and since then I am facing this issue.
Can you kindly help me as to what changes should I do to ensure that the “none” option when selected, throws an error
That means you need to investigate the configuration of the user account that is running the controller and running the agent. In the home directory of that account, you’ll probably find a .ssh directory and inside that directory you’ll find one or more files that grant access to your git repository. You’ll need to remove those files.
Command line git uses the ssh command provided by the system. The ssh command provided by the system sees that there is a private key in .ssh/id_ed25519 and a matching public key in .ssh/id_ed25519.pub. It uses that private key / public key pair as its default. When the ssh command is called by command line git, it uses that private key to authenticate with GitHub.
