On Wed, Apr 24, 2019 at 11:09 AM Randall Becker wrote: > This is a new situation that I have encountered after a clean install of > 2.164. Attempting to use an SSH keypair (with passphrase) to talk to > BitBucket.org, in a Multibranch Pipeline job. The key is properly > configured as an Private Key (entered manually) with a Passphrase. > > When I hit Scan Multibranch Pipeline Now, Jenkins immediately prompts the > JVM's stderr for the passphrase. As an example: > > Enter passphrase for key '/tmp/ssh6766884284790436436.key': > > I also get an error in the Multibranch scan log: > > > git ls-remote [email protected]:group/repo.git # edited, of course > ERROR: [Wed Apr 24 16:58:41 UTC 2019] Could not update folder level actions > from source 73a4292e-,,,, > hudson.plugins.git.GitException: Command "git ls-remote > [email protected]:group/repo.git" returned status code 128: > stdout: > stderr: Permission denied (publickey). > fatal: Could not read from remote repository. > > > This is bizarre. I'm running Ubuntu 16.04 using the default JRE. This did > not happen on earlier versions of Jenkins that were running in Docker > images - I had to remove Docker for VPN reasons. > > I'm basically off the air at this point. Did I just miss a plugin or do > something silly? > > Command line git uses ssh for communications with git servers through the secure shell protocol. The ssh command is designed to prompt the user for the passphrase. The ssh command prompts for a passphrase in cases that are sometimes surprising (at least for the git plugin). You probably have one of those cases.
I would guess that your Jenkins server process (the Java process running the master) is attached to a controlling terminal or it has environment variables set which make the ssh command line process believe that it is attached to a controlling terminal. That causes the ssh command line to prompt for the passphrase on the private key. Refer to https://github.com/jenkinsci/git-client-plugin/commit/882ecdfb53d627eeeea130720685681ce2553193 for the commit message that describes the change that was made in the git client plugin to handle that case, and the property you can set to enable that change. Alternatives you can choose: 1. Run Jenkins without a controlling terminal (for example, if running in Docker, be sure that you "detach") 2. Use private keys without passphrases 3. Set the Java property org.jenkinsci.plugins.gitclient.CliGitAPIImpl.useSETSID=true on the command line that starts the master I suspect that the critical difference between your prior condition and the current condition is that the Jenkins process is now attached to a controlling terminal. Mark Waite > TIA, > Randall > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/cf306a8d-14c2-4ebc-9173-3ddeab0a1020%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/cf306a8d-14c2-4ebc-9173-3ddeab0a1020%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Thanks! Mark Waite -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtEfqfYqPKqdL79i2kNRYCvPaB8SJnswcOicHagdV5KbdQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
