SSH Agent, z/OS USS, and git authentication problems

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

SSH Agent, z/OS USS, and git authentication problems

Randall Becker
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: '[hidden email]: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: '[hidden email]: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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/d10d6a9f-0a30-47d4-8d8d-c57ff644390eo%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: SSH Agent, z/OS USS, and git authentication problems

Ivan Fernandez Calvo
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: '[hidden email]: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: '[hidden email]: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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/94a39cf1-295e-4b51-a42b-3b586e422542o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: SSH Agent, z/OS USS, and git authentication problems

Randall Becker
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 <a href="https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;">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: '[hidden email]: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: '[hidden email]: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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: SSH Agent, z/OS USS, and git authentication problems

Mark Waite-2
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 <[hidden email]> 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: '[hidden email]: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: '[hidden email]: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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com.

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

Re: SSH Agent, z/OS USS, and git authentication problems

Randall Becker
That's what we were trying to do originally. There is a problem. When GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even though the original private key and passphrase are coming from a UTF8/US-ASCII controller. When this goes to git and then SSH, the file is still encoded as IBM1047 and is when it hits the KEX code, fails. When we use the SSH Agent, this problem does not occur. I want to use the correct using GitSCM credential ID, but it does not work. I do not have a decent debug environment that would clearly demonstrate this, isolate the section of code where this is (not) happening, or allow me to easily fix this. The most important bit is that the private key should be encoded in UTF8 or US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the SSH Agent Plugin does this correctly.

On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="YRDeWMvWBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">the....@...> 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 <a href="https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;">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: '[hidden email]: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: '[hidden email]: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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="YRDeWMvWBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkins...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: SSH Agent, z/OS USS, and git authentication problems

Mark Waite-2
https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411 has specific code for z/OS.  I do not have access to z/OS so cannot test that code.  It was merged based on a submission from people that said it works.  

You're welcome to suggest improvements in that area with the understanding that I can only evaluate that code by inspection, not by execution.

Mark Waite

On Thu, Jul 16, 2020 at 7:49 AM Randall Becker <[hidden email]> wrote:
That's what we were trying to do originally. There is a problem. When GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even though the original private key and passphrase are coming from a UTF8/US-ASCII controller. When this goes to git and then SSH, the file is still encoded as IBM1047 and is when it hits the KEX code, fails. When we use the SSH Agent, this problem does not occur. I want to use the correct using GitSCM credential ID, but it does not work. I do not have a decent debug environment that would clearly demonstrate this, isolate the section of code where this is (not) happening, or allow me to easily fix this. The most important bit is that the private key should be encoded in UTF8 or US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the SSH Agent Plugin does this correctly.

On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
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 <[hidden email]> 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: '[hidden email]: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: '[hidden email]: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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtEQ4yjwgmziHnRpd-fY3_6U%2B0FhuvpuRkgfAZcZXeC81w%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: SSH Agent, z/OS USS, and git authentication problems

Randall Becker
I'm going to try the ibm.system.encoding property to see whether that makes a difference. It would almost make sense to have the encoding externalized as a plugin property available in a pipeline. I think part of our issue is that we run multi-platform and multi-encoding, which seems out of scope for the change. The ibm.system.encoding seems to be coming from the agent without explicit action from the controller. I'm wondering whether starting the agent with -Dibm.system.encoding=ISO8859-1 might fix our situation (or make it worse). Will try this. The bigger issue is that this is a more pervasive situation than just the GitSCM but really applies to any String instantiated by the agent.

On Friday, 17 July 2020 09:47:19 UTC-4, Mark Waite wrote:
<a href="https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgit-client-plugin%2Fblob%2Feeec334af0b6447f3db9fb88d55728911a092d73%2Fsrc%2Fmain%2Fjava%2Forg%2Fjenkinsci%2Fplugins%2Fgitclient%2FCliGitAPIImpl.java%23L2411\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMmzeoW0X9kaUNTyQEvPF5w8zXQg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgit-client-plugin%2Fblob%2Feeec334af0b6447f3db9fb88d55728911a092d73%2Fsrc%2Fmain%2Fjava%2Forg%2Fjenkinsci%2Fplugins%2Fgitclient%2FCliGitAPIImpl.java%23L2411\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMmzeoW0X9kaUNTyQEvPF5w8zXQg&#39;;return true;">https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411 has specific code for z/OS.  I do not have access to z/OS so cannot test that code.  It was merged based on a submission from people that said it works.  

You're welcome to suggest improvements in that area with the understanding that I can only evaluate that code by inspection, not by execution.

Mark Waite

On Thu, Jul 16, 2020 at 7:49 AM Randall Becker <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="v1o9m0L3BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">the....@...> wrote:
That's what we were trying to do originally. There is a problem. When GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even though the original private key and passphrase are coming from a UTF8/US-ASCII controller. When this goes to git and then SSH, the file is still encoded as IBM1047 and is when it hits the KEX code, fails. When we use the SSH Agent, this problem does not occur. I want to use the correct using GitSCM credential ID, but it does not work. I do not have a decent debug environment that would clearly demonstrate this, isolate the section of code where this is (not) happening, or allow me to easily fix this. The most important bit is that the private key should be encoded in UTF8 or US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the SSH Agent Plugin does this correctly.

On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
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 <[hidden email]> 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 <a href="https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;">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: '[hidden email]: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: '[hidden email]: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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com.

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="v1o9m0L3BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkins...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5b54587a-b885-4442-ad68-0314ff51cb03o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: SSH Agent, z/OS USS, and git authentication problems

Randall Becker
In reply to this post by Mark Waite-2
I'm going to have to dig deeper and probably debug the GitSCM plugin on the agent. -Dibm.file.encoding does not help the situation. I have a call later today that might shed some light on the situation.

On Friday, 17 July 2020 09:47:19 UTC-4, Mark Waite wrote:
<a href="https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgit-client-plugin%2Fblob%2Feeec334af0b6447f3db9fb88d55728911a092d73%2Fsrc%2Fmain%2Fjava%2Forg%2Fjenkinsci%2Fplugins%2Fgitclient%2FCliGitAPIImpl.java%23L2411\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMmzeoW0X9kaUNTyQEvPF5w8zXQg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgit-client-plugin%2Fblob%2Feeec334af0b6447f3db9fb88d55728911a092d73%2Fsrc%2Fmain%2Fjava%2Forg%2Fjenkinsci%2Fplugins%2Fgitclient%2FCliGitAPIImpl.java%23L2411\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMmzeoW0X9kaUNTyQEvPF5w8zXQg&#39;;return true;">https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411 has specific code for z/OS.  I do not have access to z/OS so cannot test that code.  It was merged based on a submission from people that said it works.  

You're welcome to suggest improvements in that area with the understanding that I can only evaluate that code by inspection, not by execution.

Mark Waite

On Thu, Jul 16, 2020 at 7:49 AM Randall Becker <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="v1o9m0L3BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">the....@...> wrote:
That's what we were trying to do originally. There is a problem. When GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even though the original private key and passphrase are coming from a UTF8/US-ASCII controller. When this goes to git and then SSH, the file is still encoded as IBM1047 and is when it hits the KEX code, fails. When we use the SSH Agent, this problem does not occur. I want to use the correct using GitSCM credential ID, but it does not work. I do not have a decent debug environment that would clearly demonstrate this, isolate the section of code where this is (not) happening, or allow me to easily fix this. The most important bit is that the private key should be encoded in UTF8 or US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the SSH Agent Plugin does this correctly.

On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
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 <[hidden email]> 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 <a href="https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;">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: '[hidden email]: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: '[hidden email]: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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com.

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="v1o9m0L3BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkins...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ead1fb3b-8b71-4b57-ad81-e18bb761b6cbo%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: SSH Agent, z/OS USS, and git authentication problems

Randall Becker
Turns out, you cannot use a key-pair with a passphrase in this situation. SSH key-pairs without a passphrase works correctly (but passphrases are mandatory in our shop).

On Monday, 20 July 2020 14:14:47 UTC-4, Randall Becker wrote:
I'm going to have to dig deeper and probably debug the GitSCM plugin on the agent. -Dibm.file.encoding does not help the situation. I have a call later today that might shed some light on the situation.

On Friday, 17 July 2020 09:47:19 UTC-4, Mark Waite wrote:
<a href="https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgit-client-plugin%2Fblob%2Feeec334af0b6447f3db9fb88d55728911a092d73%2Fsrc%2Fmain%2Fjava%2Forg%2Fjenkinsci%2Fplugins%2Fgitclient%2FCliGitAPIImpl.java%23L2411\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMmzeoW0X9kaUNTyQEvPF5w8zXQg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgit-client-plugin%2Fblob%2Feeec334af0b6447f3db9fb88d55728911a092d73%2Fsrc%2Fmain%2Fjava%2Forg%2Fjenkinsci%2Fplugins%2Fgitclient%2FCliGitAPIImpl.java%23L2411\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMmzeoW0X9kaUNTyQEvPF5w8zXQg&#39;;return true;">https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411 has specific code for z/OS.  I do not have access to z/OS so cannot test that code.  It was merged based on a submission from people that said it works.  

You're welcome to suggest improvements in that area with the understanding that I can only evaluate that code by inspection, not by execution.

Mark Waite

On Thu, Jul 16, 2020 at 7:49 AM Randall Becker <[hidden email]> wrote:
That's what we were trying to do originally. There is a problem. When GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even though the original private key and passphrase are coming from a UTF8/US-ASCII controller. When this goes to git and then SSH, the file is still encoded as IBM1047 and is when it hits the KEX code, fails. When we use the SSH Agent, this problem does not occur. I want to use the correct using GitSCM credential ID, but it does not work. I do not have a decent debug environment that would clearly demonstrate this, isolate the section of code where this is (not) happening, or allow me to easily fix this. The most important bit is that the private key should be encoded in UTF8 or US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the SSH Agent Plugin does this correctly.

On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
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 <[hidden email]> 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 <a href="https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;">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: '[hidden email]: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: '[hidden email]: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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/d10d3393-1dcb-4673-9ca5-0817ea7630b9o%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: SSH Agent, z/OS USS, and git authentication problems

jeremy mordkoff
CI and passphrases never mix :) You're going to need some password-less keys even if they have limited access. 

On Monday, July 20, 2020 at 4:48:23 PM UTC-4, Randall Becker wrote:
Turns out, you cannot use a key-pair with a passphrase in this situation. SSH key-pairs without a passphrase works correctly (but passphrases are mandatory in our shop).

On Monday, 20 July 2020 14:14:47 UTC-4, Randall Becker wrote:
I'm going to have to dig deeper and probably debug the GitSCM plugin on the agent. -Dibm.file.encoding does not help the situation. I have a call later today that might shed some light on the situation.

On Friday, 17 July 2020 09:47:19 UTC-4, Mark Waite wrote:
<a href="https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgit-client-plugin%2Fblob%2Feeec334af0b6447f3db9fb88d55728911a092d73%2Fsrc%2Fmain%2Fjava%2Forg%2Fjenkinsci%2Fplugins%2Fgitclient%2FCliGitAPIImpl.java%23L2411\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMmzeoW0X9kaUNTyQEvPF5w8zXQg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fgit-client-plugin%2Fblob%2Feeec334af0b6447f3db9fb88d55728911a092d73%2Fsrc%2Fmain%2Fjava%2Forg%2Fjenkinsci%2Fplugins%2Fgitclient%2FCliGitAPIImpl.java%23L2411\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMmzeoW0X9kaUNTyQEvPF5w8zXQg&#39;;return true;">https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L2411 has specific code for z/OS.  I do not have access to z/OS so cannot test that code.  It was merged based on a submission from people that said it works.  

You're welcome to suggest improvements in that area with the understanding that I can only evaluate that code by inspection, not by execution.

Mark Waite

On Thu, Jul 16, 2020 at 7:49 AM Randall Becker <[hidden email]> wrote:
That's what we were trying to do originally. There is a problem. When GitSCM creates the GIT_SSH content on z/OS agent the file name is encoded as an IBM1047 EBCDIC regardless of the -Dfile.encoding argument, even though the original private key and passphrase are coming from a UTF8/US-ASCII controller. When this goes to git and then SSH, the file is still encoded as IBM1047 and is when it hits the KEX code, fails. When we use the SSH Agent, this problem does not occur. I want to use the correct using GitSCM credential ID, but it does not work. I do not have a decent debug environment that would clearly demonstrate this, isolate the section of code where this is (not) happening, or allow me to easily fix this. The most important bit is that the private key should be encoded in UTF8 or US-ASCII when supplied to GIT_SSH, not the default encoding. Somehow, the SSH Agent Plugin does this correctly.

On Monday, 13 July 2020 17:41:07 UTC-4, Mark Waite wrote:
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 <[hidden email]> 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 <a href="https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsupport.cloudbees.com%2Fhc%2Fen-us%2Farticles%2F224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOb1O5Zl8JGiWtE0c-pFPkQeybdA&#39;;return true;">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: '[hidden email]: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: '[hidden email]: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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-users/b071384e-8160-4522-9237-d036af9a6c15o%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5b5ea582-cae9-4a5f-90f2-50d423206e4ao%40googlegroups.com.