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 <[email protected]> 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: >>> '[email protected]: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: '[email protected]: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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtHp9izxgfqe5w3U1YoaY4uSeoNaQwKLd5kWWRfkW1nV%2BA%40mail.gmail.com.
