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 w
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 GitSC
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:
>
>
> https://github.com/jenkinsci/
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 scop
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 th
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 co
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
wrote:
> I wish it was that simple. The issue definitely app
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
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 aut
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
10 matches
Mail list logo
