If the operation you're performing is a checkout, why use the ssh-agent wrapper? Why not use the same credentials ID as an argument to checkout rather than wrapping checkout in ssh-agent?
On Mon, Jul 13, 2020 at 8:45 AM Randall Becker <the.n.e....@gmail.com> wrote: > I wish it was that simple. The issue definitely appears to be the encoding > of the private key during a key exchange. When using SSH-Agent and git > commands from within a shell in the pipeline, the authentication works > fine. So this is likely an interaction with the GitSCM plugin not being > aware of IBM-1047 encodings. > > On Sunday, 12 July 2020 16:08:31 UTC-4, Ivan Fernandez Calvo wrote: >> >> I think that this is the reason why it does not work >> https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker- >> >> El sábado, 11 de julio de 2020, 22:25:08 (UTC+2), Randall Becker escribió: >>> >>> I'm having issues trying to get an agent to authenticate using the SSH >>> Agent plugin on a R2.4 z/OS USS agent with a Docker Jenkins controller. The >>> goal is to convince GitSCM to actually fetch properly. We get SSH >>> authentication errors no matter what happens. This is using Pipelines. >>> >>> I've tried >>> sshagent (credentials: ['mvs-randall']) { >>> checkout([$class: 'GitSCM', >>> branches: [[name: '*/development']], >>> extensions: [ >>> [$class: 'CleanBeforeCheckout'], >>> [$class: 'SubmoduleOption', >>> disableSubmodules: false, parentCredentials: true, >>> recursiveSubmodules: true, >>> reference: '', trackingSubmodules: false]], >>> doGenerateSubmoduleConfigurations: >>> false, submoduleCfg: [], >>> userRemoteConfigs: [[url: >>> 'g...@xx.xxx.xxx.xxx:proj/repo.git'']]]) >>> } >>> and >>> checkout([$class: 'GitSCM', >>> branches: [[name: '*/development']], >>> extensions: [ >>> [$class: 'CleanBeforeCheckout'], >>> [$class: 'SubmoduleOption', >>> disableSubmodules: false, parentCredentials: true, >>> recursiveSubmodules: true, >>> reference: '', trackingSubmodules: false]], >>> doGenerateSubmoduleConfigurations: >>> false, submoduleCfg: [], >>> userRemoteConfigs: [[credentialsId: >>> 'mvs-randall',url: 'g...@xx.xxx.xxx.xxx:proj/repo.git']]]) >>> >>> Both result in Permission denied (publickey). >>> >>> I've done the same thing on many other platforms with no problem. This >>> seems very R2.4 specific. There was a change in the supported file >>> encodings as well - we used to use -Dfile.encoding=utf8 in the agent config >>> (because this is an IBM that likes EBCDIC), but had to move to >>> -Dfile.encoding=ISO8859-1 and everything seems messed up now. IBM had this >>> funky script they recommend that massages the key into an IBM-1047 encoding >>> but that does not help at all - in fact the GitSCM agent cannot process any >>> results if that script is used. >>> >>> Help! >>> >>> 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 jenkinsci-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtHp9izxgfqe5w3U1YoaY4uSeoNaQwKLd5kWWRfkW1nV%2BA%40mail.gmail.com.
