[JIRA] [git-plugin] (JENKINS-28034) SCM polling not using correct user credentials

3 views
Skip to first unread message

oded@geek.co.il (JIRA)

unread,
Jul 16, 2015, 4:15:03 PM7/16/15
to jenkinsc...@googlegroups.com
Oded Arbel commented on Bug JENKINS-28034
 
Re: SCM polling not using correct user credentials

I had a similar problem, changing to JGit solved it.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

will.saxon@greenwayhealth.com (JIRA)

unread,
Aug 9, 2015, 2:01:03 PM8/9/15
to jenkinsc...@googlegroups.com

I came to file an issue about this same behavior. To clarify: when you configure the Git plugin to check out code, you can specify a credential and that works fine. The problem is that this credential is not provided to the polling session, so unless a valid private key exists in $HOME/.ssh, polling will fail with a permission denied error.

I don't know if it matters, but in our case we are disabling fast remote polling b/c we want to ignore certain paths while polling.

will.saxon@greenwayhealth.com (JIRA)

unread,
Aug 9, 2015, 2:10:01 PM8/9/15
to jenkinsc...@googlegroups.com
Will Saxon updated an issue
 
Jenkins / Bug JENKINS-28034

Illustrates normal build checkout vs. polling session. Note that polling does not attempt to set GIT_SSH.

Change By: Will Saxon
Attachment: log.txt

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 10, 2015, 10:29:01 AM8/10/15
to jenkinsc...@googlegroups.com
Mark Waite commented on Bug JENKINS-28034
 
Re: SCM polling not using correct user credentials

What you reported doesn't match what I see if my test environment. The remote polling works even with a repository which is completely isolated except for the credential that was added to allow the git plugin access to the repository.

Can you provide more details of the steps you take to show the problem so that others can duplicate it?

will.saxon@greenwayhealth.com (JIRA)

unread,
Aug 10, 2015, 10:32:01 AM8/10/15
to jenkinsc...@googlegroups.com

We're not using remote polling - we have 'force polling using workspace' enabled.

I can't spend any time on this right now but will try to get more details this evening. Maybe it's just something we're doing wrong in our environment.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 14, 2015, 7:48:01 AM8/14/15
to jenkinsc...@googlegroups.com

I will need more detailed information. I can't duplicate this problem as described here.

uwe.pachler.dg@gmail.com (JIRA)

unread,
Feb 25, 2019, 7:57:02 AM2/25/19
to jenkinsc...@googlegroups.com

I'm seeing the exact same problem. In addition what's been said above, I see 'using GIT_SSH' also in the poll log. However, authentication still fails.

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 25, 2019, 8:29:02 AM2/25/19
to jenkinsc...@googlegroups.com
Mark Waite updated Bug JENKINS-28034
 

Uwe Pachler I couldn't duplicate the problem. Considering the number of installations of the git plugin in the world and the number of repositories that are polled with ssh and authenticated with ssh, I suspect there is a local configuration error in your environment.

You might try the following techniques:

  • Create a separate user account with no private key
  • Use the private key from the Jenkins credential as the private key in that new account
  • Clone the repository with command line git in that new account with the private key from the Jenkins credential
  • If the private key uses a passphrase, be sure that the passphrase does not include characters which are special to the shell. The git client plugin releases prior to git client plugin 3.0.0-rc do not correctly handle passphrases which contain shell special characters
Change By: Mark Waite
Status: Open Fixed but Unreleased
Resolution: Cannot Reproduce

uwe.pachler.dg@gmail.com (JIRA)

unread,
Feb 25, 2019, 8:39:02 AM2/25/19
to jenkinsc...@googlegroups.com
 
Re: SCM polling not using correct user credentials

Wow, thanks for the quick response!

I too was suspecting it has something to do with our local configuration; however, I couldn't put my finger on it yet what it is. So far we've been using slave-local private keys (the ones stored in ~/.ssh/id_rsa on each build node of the cluster), and adding their public keys to the respective Bitbucket project (we're using a Bitbucket on-premise installation).

So what you're suggesting sounds pretty much like what we've been doing all along, although I'm certainly going to try that path again.

I'm also wondering if it may be an issue with Bitbucket itself, although, as previously stated, we've used SSH key auth in the past.

mark.earl.waite@gmail.com (JIRA)

unread,
Jan 23, 2020, 3:54:04 PM1/23/20
to jenkinsc...@googlegroups.com
Change By: Mark Waite
Status: Fixed but Unreleased Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages