-
Bug
-
Resolution: Fixed
-
Blocker
-
Jenkins:2.222.3
git-client: 3.3.1
git-plugin: 4.3.0
z/OS R2.4
git 2.14
-
-
3.4.0
When attempting to clone a repository using an SSH key-pair in a pipeline, the clone fails with
Permission denied (publickey).
if the key has a passphrase. The authentication succeeds if there is no passphrase. Various encodings have been attempted to get past this, including utf8, ISO8859-1, and IBM-1047.
We are using an SSH Agent as a workaround for the time being, but that requires manually modifying the git configuration in new workspaces.
[JENKINS-63146] Pipeline Clone fails on zOS with SSH Key-pair with Passphrase
Randall Becker
created issue -
| Assignee | Original: Mark Waite [ markewaite ] |
Randall Becker
added a comment - Thanks. Any pointers on where the passphrase is passed in? I'm guessing this is an encoding issue. The credentials comes from a controller on x86 Gentoo Docker image of Jenkins, going to a z/OS agent. I'm not at all sure what happens with all the if (isZos()) { code branches. Sadly, this is not my native platform either, but I do have a machine on which I can try to debug the agent (with difficulty).
Randall Becker
added a comment - Thanks. Any pointers on where the passphrase is passed in? I'm guessing this is an encoding issue. The credentials comes from a controller on x86 Gentoo Docker image of Jenkins, going to a z/OS agent. I'm not at all sure what happens with all the if (isZos()) { code branches. Sadly, this is not my native platform either, but I do have a machine on which I can try to debug the agent (with difficulty). Search for the 'passphrase' in git-client-plugin. https://github.com/jenkinsci/git-client-plugin/blob/eeec334af0b6447f3db9fb88d55728911a092d73/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L1962
Randall Becker
added a comment - I am not sure about the line at 2167:
| try (PrintWriter w = new PrintWriter(passphraseFile, "UTF-8")) { |
| w.println(Secret.toString(sshUser.getPassphrase())); |
}
On the zOS machine, I think the passphrase file needs to be encoded in IBM-1047. I will verify with my contacts at IBM on this.
Randall Becker
added a comment - I am not sure about the line at 2167:
try (PrintWriter w = new PrintWriter(passphraseFile, "UTF-8")) {
w.println(Secret.toString(sshUser.getPassphrase()));
}
On the zOS machine, I think the passphrase file needs to be encoded in IBM-1047. I will verify with my contacts at IBM on this. Randall Becker
added a comment - So far, it looks like the IBM team is requesting a parameter to set the passphrase encoding rather than hard coding "UTF-8". Would that be possible?
Randall Becker
added a comment - So far, it looks like the IBM team is requesting a parameter to set the passphrase encoding rather than hard coding "UTF-8". Would that be possible? Is it the same encoding used for the process on the agent or does it need to be independent of the encoding used for the agent?
I could envision an agent specific environment variable defined for the zOS agent and not defined on other agents. If that variable is defined, then it could be used when encoding those temporary files that transmit credentials information to command line git.
If your repositories are not huge, you might consider enabling JGit and using JGit instead of command line git. It does not use temporary files for credentials so it should not rely on file encoding.
Randall Becker
added a comment - The situation is that original passphrase is coming from a UTF8 controller going to an IBM-1047 agent. So yes, this should be something on the agent config. Maybe something like -Dibm.passphrase.encoding=IBM-1047. I already tried JGit - it does not seem to like being on the platform at all. I could not make it work on R2.3 at all - either standalone or inside Jenkins.
Randall Becker
added a comment - The situation is that original passphrase is coming from a UTF8 controller going to an IBM-1047 agent. So yes, this should be something on the agent config. Maybe something like -Dibm.passphrase.encoding=IBM-1047. I already tried JGit - it does not seem to like being on the platform at all. I could not make it work on R2.3 at all - either standalone or inside Jenkins. I'd prefer a name like GitSCM.credentials.file.encoding since there may be other platforms that want to change the encoding of the files.
Can the encoding be used for all the git credentials files (username/password, private key, and passphrase files)?
Thanks for the report and good luck with your investigation. I don't have access to z/OS so can only offer to code review proposed changes. Refer to the CredentialsTest in git client plugin if you'd like an automated test environment that can check passphrase protected private keys.