Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-46754

2.73+ SSH agent sometimes will not start if using passphrase-protected ed25519 key

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    • Jenkins 2.73.1 RC
      Jenkins plugins as stored in my lts-with-plugins branch SHA f45cc34ca0

      The Jenkins 2.73.1 LTS release fails to connect my ssh agents which use an ed25519 passphrase protected private key.  These agents connected successfully with Jenkins 2.60.3 LTS and earlier.

      I've confirmed that dsa passphrase protected private keys work in all cases and that rsa passphrase protected private keys work in all cases. The rsa private keys and ed25519 private keys which are not passphrase protected work in all cases.

      It appears to only be ed25519 private keys which are passphrase protected that have a problem in two of my six tested configurations with 2.73.1 LTS.  Those same configurations work as expected with 2.60.3 LTS.

      Failures include a stack trace:

      [09/08/17 08:56:01] SSH Launch of mark-pc2-beemarkwaite on mark-pc2.markwaite.net failed in 113 ms
      Sep 08, 2017 8:56:01 AM com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator authenticate
      WARNING: Uncaught exception escaped doAuthenticate method
      java.lang.NoSuchMethodError: org.mindrot.jbcrypt.BCrypt.pbkdf([B[BI[B)V
      at com.trilead.ssh2.signature.OpenSshCertificateDecoder.generateKayAndIvPbkdf2(OpenSshCertificateDecoder.java:135)
      at com.trilead.ssh2.signature.OpenSshCertificateDecoder.createKeyPair(OpenSshCertificateDecoder.java:78)
      at com.trilead.ssh2.crypto.PEMDecoder.decodeKeyPair(PEMDecoder.java:493)
      at com.trilead.ssh2.auth.AuthenticationManager.authenticatePublicKey(AuthenticationManager.java:225)
      at com.trilead.ssh2.Connection.authenticateWithPublicKey(Connection.java:483)
      at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.doAuthenticate(TrileadSSHPublicKeyAuthenticator.java:109)
      at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.authenticate(SSHAuthenticator.java:438)
      at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.authenticate(SSHAuthenticator.java:458)
      at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:1321)
      at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:804)
      at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:793)
      at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      at java.lang.Thread.run(Thread.java:748)
      

       
      The other agent fails with a similar stack trace in the log file:

      Sep 08, 2017 9:06:13 AM com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator authenticate
      WARNING: Uncaught exception escaped doAuthenticate method
      java.lang.NoSuchMethodError: org.mindrot.jbcrypt.BCrypt.pbkdf([B[BI[B)V
      	at com.trilead.ssh2.signature.OpenSshCertificateDecoder.generateKayAndIvPbkdf2(OpenSshCertificateDecoder.java:135)
      	at com.trilead.ssh2.signature.OpenSshCertificateDecoder.createKeyPair(OpenSshCertificateDecoder.java:78)
      	at com.trilead.ssh2.crypto.PEMDecoder.decodeKeyPair(PEMDecoder.java:493)
      	at com.trilead.ssh2.auth.AuthenticationManager.authenticatePublicKey(AuthenticationManager.java:225)
      	at com.trilead.ssh2.Connection.authenticateWithPublicKey(Connection.java:483)
      	at com.cloudbees.jenkins.plugins.sshcredentials.impl.TrileadSSHPublicKeyAuthenticator.doAuthenticate(TrileadSSHPublicKeyAuthenticator.java:109)
      	at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.authenticate(SSHAuthenticator.java:438)
      	at com.cloudbees.jenkins.plugins.sshcredentials.SSHAuthenticator.authenticate(SSHAuthenticator.java:458)
      	at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:1321)
      	at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:804)
      	at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:793)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      	at java.lang.Thread.run(Thread.java:748)
      
      [09/08/17 09:06:13] SSH Launch of debian9-a-coleen on debian9-a.markwaite.net failed in 135 ms
      

      Problem does not appear in 2.71, 2.72, 2.73, or 2.75 on the two failing machines.
      Problem is visible in 2.73.1-rc, 2.76, and 2.77 on the two failing machines.

          [JENKINS-46754] 2.73+ SSH agent sometimes will not start if using passphrase-protected ed25519 key

          The only commit backported from cores after 2.75 is dc8000cc1e36399595883858c3aae8f135177d49, remoting bump (https://github.com/jenkinsci/remoting/compare/remoting-3.10...remoting-3.11). The commit does not affect effective dependencies on core in any way (except for remoting itself).

          Oliver Gondža added a comment - The only commit backported from cores after 2.75 is dc8000cc1e36399595883858c3aae8f135177d49, remoting bump ( https://github.com/jenkinsci/remoting/compare/remoting-3.10...remoting-3.11 ). The commit does not affect effective dependencies on core in any way (except for remoting itself).

          markewaite, I am wondering if you managed to retest with the new RC with remoting update rolled back.

          Oliver Gondža added a comment - markewaite , I am wondering if you managed to retest with the new RC with remoting update rolled back.

          Mark Waite added a comment - - edited

          olivergondza I tested many different scenarios with the new version (with remoting 3.10 instead of remoting 3.11) and saw results that surprised me.  I'm assembling a table to represent what I observed.  I need to confirm the data in the table one more time, then will enter it today.  It may be 8+ hours before I can enter that table.

          Before the table is available and confirmed, the short summary is that all the configurations I tested worked for all cases if no passphrases were involved, and all cases I tested worked for rsa and dsa keys if passphrases were involved.  The failures I saw were in ed25519 with passphrases, but I did not see ed25519 with passphrase failures on all configurations (even though I'm using the same docker definitions everywhere).

          I am sure there is some issue here, since the stack trace indicates some configurations can't do ed25519.  I don't think the issue is enough to stop LTS release, since it is only a single case, and only on some of my configurations.

           

          Mark Waite added a comment - - edited olivergondza I tested many different scenarios with the new version (with remoting 3.10 instead of remoting 3.11) and saw results that surprised me.  I'm assembling a table to represent what I observed.  I need to confirm the data in the table one more time, then will enter it today.  It may be 8+ hours before I can enter that table. Before the table is available and confirmed, the short summary is that all the configurations I tested worked for all cases if no passphrases were involved, and all cases I tested worked for rsa and dsa keys if passphrases were involved.  The failures I saw were in ed25519 with passphrases, but I did not see ed25519 with passphrase failures on all configurations (even though I'm using the same docker definitions everywhere). I am sure there is some issue here, since the stack trace indicates some configurations can't do ed25519.  I don't think the issue is enough to stop LTS release, since it is only a single case, and only on some of my configurations.  

          Jesse Glick added a comment -

          Seems like we are missing some functional tests in ssh-slaves. You can use docker-fixtures if necessary to reproduce the exact scenario being described in an automated test. That would allow us to detect regressions earlier.

          https://github.com/jenkinsci/jenkins/commit/035d73102a6e39ad175c1b90f57016a270ec89db in 2.73 might be related, though this seems to contain a method of the specified signature so I am not sure what the issue is. Core bundles org.mindrot:jbcrypt:0.4 while org.jenkins-ci:trilead-ssh2:build-217-jenkins-11 requests org.connectbot.jbcrypt:jbcrypt:1.0.0 but AFAIK they are the same modulo packaging.

          Jesse Glick added a comment - Seems like we are missing some functional tests in ssh-slaves . You can use docker-fixtures if necessary to reproduce the exact scenario being described in an automated test. That would allow us to detect regressions earlier. https://github.com/jenkinsci/jenkins/commit/035d73102a6e39ad175c1b90f57016a270ec89db  in 2.73 might be related, though this seems to contain a method of the specified signature so I am not sure what the issue is. Core bundles org.mindrot:jbcrypt:0.4 while org.jenkins-ci:trilead-ssh2:build-217-jenkins-11 requests org.connectbot.jbcrypt:jbcrypt:1.0.0 but AFAIK they are the same modulo packaging.

          Jesse Glick added a comment -

          In any event I cannot see any reason why a Remoting version change would cause this issue, which seems to be about versions of third-party libraries.

          Jesse Glick added a comment - In any event I cannot see any reason why a Remoting version change would cause this issue, which seems to be about versions of third-party libraries.

          Jesse Glick added a comment -

          The plugin of interest is ssh-slaves, not ssh-agent which is unrelated.

          I am confused since markewaite said five days ago on the list that the errors resulted from use of a new version of git-client, not anything specific to core. Was that not in fact true?

          Jesse Glick added a comment - The plugin of interest is ssh-slaves , not ssh-agent which is unrelated. I am confused since markewaite said five days ago on the list that the errors resulted from use of a new version of git-client , not anything specific to core. Was that not in fact true?

          Mark Waite added a comment - - edited

          Here is what I observed in tabular form:

          Machine /
          OS
          rsa
          no phrase
          rsa
          has phrase
          dsa
          no phrase
          dsa
          has phrase
          ed25519
          no phrase
          ed25519
          has phrase
          mark-pc1 /
          Ubuntu 16.04
          ok ok   ok ok agent: ok
          jgit: ok
          mark-pc2 /
          Ubuntu 16.04
          ok ok   ok ok agent: no
          jgit: no
          debian8 /
          Debian 8
          ok ok   ok ok agent: no
          jgit: no
          debian9-a /
          Debian 9
          ok ok   ok ok agent: ok
          jgit: ok
          ubuntu14b /
          Ubuntu 14.04
          ok ok   ok ok agent: ok
          jgit: ok
          ubuntu14c /
          Ubuntu 14.04
          ok ok   ok ok agent: ok
          jgit: ok

          I haven't yet found the relevant difference between the ed25519 has phrase (ed25519 with passphrase) cases which fail and those which succeed.

          Each of the machines listed on the horizontal axis is running Docker from the same Dockerfile definition as all the other rows.  Each is using the same credentials from the repository.  Each is using the same agent names. Each agent uses an independent directory (should be no contamination of one agent with another).

          I've tested ed25519 agents with passphrases on Debian 9 (two different accounts), Ubuntu 14, and Ubuntu 16.  Those 4 variants all behave the same.  The agents start when the request comes from mark-pc1 or debian9-a, and they do not start when the request comes from mark-pc2 or debian8.

          I ran the same set of tests with the earlier Jenkins 2.73.1 release candidate (which used remoting 3.11) and showed no difference.  As far as I can tell, the change from remoting 3.10 to remoting 3.11 has not changed this behavior in any way.

          Mark Waite added a comment - - edited Here is what I observed in tabular form: Machine / OS rsa no phrase rsa has phrase dsa no phrase dsa has phrase ed25519 no phrase ed25519 has phrase mark-pc1 / Ubuntu 16.04 ok ok   ok ok agent: ok jgit: ok mark-pc2 / Ubuntu 16.04 ok ok   ok ok agent: no jgit: no debian8 / Debian 8 ok ok   ok ok agent: no jgit: no debian9-a / Debian 9 ok ok   ok ok agent: ok jgit: ok ubuntu14b / Ubuntu 14.04 ok ok   ok ok agent: ok jgit: ok ubuntu14c / Ubuntu 14.04 ok ok   ok ok agent: ok jgit: ok I haven't yet found the relevant difference between the ed25519 has phrase (ed25519 with passphrase) cases which fail and those which succeed. Each of the machines listed on the horizontal axis is running Docker from the same Dockerfile definition as all the other rows.  Each is using the same credentials from the repository.  Each is using the same agent names. Each agent uses an independent directory (should be no contamination of one agent with another). I've tested ed25519 agents with passphrases on Debian 9 (two different accounts), Ubuntu 14, and Ubuntu 16.  Those 4 variants all behave the same.  The agents start when the request comes from mark-pc1 or debian9-a, and they do not start when the request comes from mark-pc2 or debian8. I ran the same set of tests with the earlier Jenkins 2.73.1 release candidate (which used remoting 3.11) and showed no difference.  As far as I can tell, the change from remoting 3.10 to remoting 3.11 has not changed this behavior in any way.

          Mark Waite added a comment - - edited

          jglick my flawed test from 5 days ago was only testing jgit based clone.  I assumed that the problem was due to my change from JGit 4.5.3 to JGit 4.8.0 (testing the transition of git client plugin to Java 8).  

          Unfortunately, the comparison I performed at that time was to check that mark-pc1 (Ubuntu 16.04) could clone ed25519 passphrase protected repositories with JGit 4.5.3 from its docker environment, while mark-pc2 (Ubuntu 16.04) could not clone ed25519 passphrase protected repositories with JGit 4.8.0 from its docker environment.

          That comparison was flawed because those two configurations (mark-pc1 vs. mark-pc2) behave differently for ed25519 passphrase protected keys.  I don't yet understand why they behave differently, since they are running from the same docker definition, using the same docker version, with the same operating system version, current operating system updates installed on both, and using the same agents for their tests.

          When I added agents which use a passphrase protected ed25519 private key, I saw failure patterns that matched the JGit failures.  I've since confirmed again that the difference was not related to the change from JGit 4.5.3 to JGit 4.8.0.  I'm running JGit 4.5.3 in all the scenarios above, and seeing that JGit 4.5.3 clone of ed25519 passphrase protected repositories is failing in the same configurations where ed25519 passphrase protected agents fail to start.

          I removed all the docker images on one of the two failing docker machines (debian8), and it continues to have the same behavior, failing to connect any agent which uses a passphrase protected ed25519 private key.

          Mark Waite added a comment - - edited jglick my flawed test from 5 days ago was only testing jgit based clone.  I assumed that the problem was due to my change from JGit 4.5.3 to JGit 4.8.0 (testing the transition of git client plugin to Java 8).   Unfortunately, the comparison I performed at that time was to check that mark-pc1 (Ubuntu 16.04) could clone ed25519 passphrase protected repositories with JGit 4.5.3 from its docker environment, while mark-pc2 (Ubuntu 16.04) could not clone ed25519 passphrase protected repositories with JGit 4.8.0 from its docker environment. That comparison was flawed because those two configurations (mark-pc1 vs. mark-pc2) behave differently for ed25519 passphrase protected keys.  I don't yet understand why they behave differently, since they are running from the same docker definition, using the same docker version, with the same operating system version, current operating system updates installed on both, and using the same agents for their tests. When I added agents which use a passphrase protected ed25519 private key, I saw failure patterns that matched the JGit failures.  I've since confirmed again that the difference was not related to the change from JGit 4.5.3 to JGit 4.8.0.  I'm running JGit 4.5.3 in all the scenarios above, and seeing that JGit 4.5.3 clone of ed25519 passphrase protected repositories is failing in the same configurations where ed25519 passphrase protected agents fail to start. I removed all the docker images on one of the two failing docker machines (debian8), and it continues to have the same behavior, failing to connect any agent which uses a passphrase protected ed25519 private key.

          Jesse Glick added a comment -

          Well if you can at least consistently reproduce the error on one of the machines, it should be possible to track down the root cause in a debugger. Grab me sometime to walk you through it if you are unsure how.

          Jesse Glick added a comment - Well if you can at least consistently reproduce the error on one of the machines, it should be possible to track down the root cause in a debugger. Grab me sometime to walk you through it if you are unsure how.

          Jesse Glick added a comment -

          Diagnosed; will put together a PR to fix the problem, to include an explanation of the issue (JBCrypt version clash in jenkins.war).

          Jesse Glick added a comment - Diagnosed; will put together a PR to fix the problem, to include an explanation of the issue (JBCrypt version clash in jenkins.war ).

          Jesse Glick added a comment -

          Provisional statement of impact: if you are using 2.73+ and have an ed25519-format private key using passphrase protection, and try to connect either to an SSH agent or to a Git server like GitHub using JGit, you have a 50% chance of it blowing up with a cryptic error (which in the case of agent connection appears only in the system log, not launch log). Worked reliably in previous releases. This key algorithm is apparently recommended over earlier formats by security experts.

          Jesse Glick added a comment - Provisional statement of impact: if you are using 2.73+ and have an ed25519-format private key using passphrase protection, and try to connect either to an SSH agent or to a Git server like GitHub using JGit, you have a 50% chance of it blowing up with a cryptic error (which in the case of agent connection appears only in the system log, not launch log). Worked reliably in previous releases. This key algorithm is apparently recommended over earlier formats by security experts.

          Jesse Glick added a comment -

          Assuming that this could affect GitHub users based on this post. AFAIK markewaite has only personally tested it with BitBucket.

          For Git usage, the workaround would be to use CLI Git, since AFAIK that just passes in GIT_ASKPASS and lets the Git executable deal with decryption of the private key. markewaite & I have discussed the possibility of having the CLI Git implementation be passed a private key which was already decrypted by Jenkins code, which would solve a bunch of thorny issues surrounding helper process handling; on the other hand it would leave it more vulnerable to problems like this one: dealing with details of encryption algorithms.

          Another workaround would be to use a private key without a passphrase from Jenkins: since Jenkins Credentials would be storing the passphrase anyway, it is unclear what incremental security benefit there really is to using a passphrase for such keys. Mainly it is just more convenient to configure if your personal computer is using a passphrase-protected key and you do not care to run the tool to convert it.

          For SSH agents, I am not sure what good workaround there would be. CloudBees customers could try the cloudbees-ssh-slaves plugin, which goes through a different code path, though I have no idea if it even supports the pbkdf passphrase hashing apparently used in ed25519 keys. Or you could use CommandLauncher and then your support is as good as your OpenSSH installation, which I presume handles the newest standards fine.

          Jesse Glick added a comment - Assuming that this could affect GitHub users based on this post . AFAIK markewaite has only personally tested it with BitBucket. For Git usage, the workaround would be to use CLI Git, since AFAIK that just passes in GIT_ASKPASS and lets the Git executable deal with decryption of the private key. markewaite & I have discussed the possibility of having the CLI Git implementation be passed a private key which was already decrypted by Jenkins code, which would solve a bunch of thorny issues surrounding helper process handling; on the other hand it would leave it more vulnerable to problems like this one: dealing with details of encryption algorithms. Another workaround would be to use a private key without a passphrase from Jenkins: since Jenkins Credentials would be storing the passphrase anyway, it is unclear what incremental security benefit there really is to using a passphrase for such keys. Mainly it is just more convenient to configure if your personal computer is using a passphrase-protected key and you do not care to run the tool to convert it. For SSH agents, I am not sure what good workaround there would be. CloudBees customers could try the cloudbees-ssh-slaves plugin, which goes through a different code path, though I have no idea if it even supports the pbkdf passphrase hashing apparently used in ed25519 keys. Or you could use CommandLauncher and then your support is as good as your OpenSSH installation, which I presume handles the newest standards fine.

          Jesse Glick added a comment -

          danielbeck asks about Subversion. Since SVNKit does seem to call com.trilead.ssh2.Connection.authenticateWithPublicKey, it could potentially be affected as well—unverified. In that case since there is no support in the Jenkins plugin for CLI-based checkouts, the only workaround be to use an unencrypted private key.

          Jesse Glick added a comment - danielbeck asks about Subversion. Since SVNKit does seem to call com.trilead.ssh2.Connection.authenticateWithPublicKey , it could potentially be affected as well—unverified. In that case since there is no support in the Jenkins plugin for CLI-based checkouts, the only workaround be to use an unencrypted private key.

          Jesse Glick added a comment -

          BTW I am adding statements about user impact to this issue; discussion of the origin of the problem and nature of the fix should go into PR 3026.

          Jesse Glick added a comment - BTW I am adding statements about user impact to this issue; discussion of the origin of the problem and nature of the fix should go into PR 3026 .

          Code changed in jenkins
          User: Daniel Beck
          Path:
          content/_data/changelogs/lts.yml
          content/doc/upgrade-guide/2.73.adoc
          http://jenkins-ci.org/commit/jenkins.io/ac48867bd1839ede182ef2a98b7c8f6da3c91c90
          Log:
          Note details on JENKINS-46754

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Daniel Beck Path: content/_data/changelogs/lts.yml content/doc/upgrade-guide/2.73.adoc http://jenkins-ci.org/commit/jenkins.io/ac48867bd1839ede182ef2a98b7c8f6da3c91c90 Log: Note details on JENKINS-46754

          Code changed in jenkins
          User: R. Tyler Croy
          Path:
          content/_data/changelogs/lts.yml
          content/doc/upgrade-guide/2.73.adoc
          http://jenkins-ci.org/commit/jenkins.io/78b392bef2fe9c9aba2e3db309c89bdca2942aaa
          Log:
          Merge pull request #1131 from daniel-beck/JENKINS-46754

          Note details on JENKINS-46754

          Compare: https://github.com/jenkins-infra/jenkins.io/compare/352a9939f8c3...78b392bef2fe

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: R. Tyler Croy Path: content/_data/changelogs/lts.yml content/doc/upgrade-guide/2.73.adoc http://jenkins-ci.org/commit/jenkins.io/78b392bef2fe9c9aba2e3db309c89bdca2942aaa Log: Merge pull request #1131 from daniel-beck/ JENKINS-46754 Note details on JENKINS-46754 Compare: https://github.com/jenkins-infra/jenkins.io/compare/352a9939f8c3...78b392bef2fe

          Jesse Glick added a comment - - edited

          Affected private keys are those that require a passphrase and start with the line:

          -----BEGIN OPENSSH PRIVATE KEY-----
          

          Currently it seems ssh-keygen will only use this format when -t ed25519 is specified (older types such as RSA have distinct headers and internal formats), but in principle other (future?) key types could share this new format.

          Jesse Glick added a comment - - edited Affected private keys are those that require a passphrase and start with the line: -----BEGIN OPENSSH PRIVATE KEY----- Currently it seems ssh-keygen will only use this format when -t ed25519 is specified (older types such as RSA have distinct headers and internal formats), but in principle other (future?) key types could share this new format.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/pom.xml
          test/src/test/java/jenkins/ClassPathTest.java
          http://jenkins-ci.org/commit/jenkins/1784f90806c1c1f39e307c722a3dd4f63850877e
          Log:
          [FIXED JENKINS-46754] Remove org.mindrot:jbcrypt:0.4 since we already bundle org.connectbot.jbcrypt:jbcrypt:1.0.0.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/pom.xml test/src/test/java/jenkins/ClassPathTest.java http://jenkins-ci.org/commit/jenkins/1784f90806c1c1f39e307c722a3dd4f63850877e Log: [FIXED JENKINS-46754] Remove org.mindrot:jbcrypt:0.4 since we already bundle org.connectbot.jbcrypt:jbcrypt:1.0.0.

          Jesse Glick added a comment -

          Merged toward 2.79.

          Jesse Glick added a comment - Merged toward 2.79.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer.java
          src/main/java/org/jenkinsci/test/acceptance/plugins/ssh_credentials/SshPrivateKeyCredential.java
          src/main/java/org/jenkinsci/test/acceptance/plugins/ssh_slaves/SshSlaveLauncher.java
          src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/Dockerfile
          src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.pass
          src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.priv
          src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.pub
          src/test/java/plugins/SshSlavesPluginTest.java
          http://jenkins-ci.org/commit/acceptance-test-harness/7544f951fb4b854cd5db89c60ea48da9178c0f6a
          Log:
          JENKINS-46754 Reproduce bug and demonstrate fix.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer.java src/main/java/org/jenkinsci/test/acceptance/plugins/ssh_credentials/SshPrivateKeyCredential.java src/main/java/org/jenkinsci/test/acceptance/plugins/ssh_slaves/SshSlaveLauncher.java src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/Dockerfile src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.pass src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.priv src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.pub src/test/java/plugins/SshSlavesPluginTest.java http://jenkins-ci.org/commit/acceptance-test-harness/7544f951fb4b854cd5db89c60ea48da9178c0f6a Log: JENKINS-46754 Reproduce bug and demonstrate fix.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer.java
          src/main/java/org/jenkinsci/test/acceptance/plugins/ssh_credentials/SshPrivateKeyCredential.java
          src/main/java/org/jenkinsci/test/acceptance/plugins/ssh_slaves/SshSlaveLauncher.java
          src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/Dockerfile
          src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.pass
          src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.priv
          src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.pub
          src/test/java/plugins/SshSlavesPluginTest.java
          http://jenkins-ci.org/commit/acceptance-test-harness/3a09d8b9b0b2317c0c3c5a690aa4564a9693a63d
          Log:
          Merge pull request #354 from jglick/jbcrypt-JENKINS-46754

          JENKINS-46754 Reproduce bug and demonstrate fix

          Compare: https://github.com/jenkinsci/acceptance-test-harness/compare/539505e2ff4c...3a09d8b9b0b2

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer.java src/main/java/org/jenkinsci/test/acceptance/plugins/ssh_credentials/SshPrivateKeyCredential.java src/main/java/org/jenkinsci/test/acceptance/plugins/ssh_slaves/SshSlaveLauncher.java src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/Dockerfile src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.pass src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.priv src/main/resources/org/jenkinsci/test/acceptance/docker/fixtures/SshAgentContainer/ed25519.pub src/test/java/plugins/SshSlavesPluginTest.java http://jenkins-ci.org/commit/acceptance-test-harness/3a09d8b9b0b2317c0c3c5a690aa4564a9693a63d Log: Merge pull request #354 from jglick/jbcrypt- JENKINS-46754 JENKINS-46754 Reproduce bug and demonstrate fix Compare: https://github.com/jenkinsci/acceptance-test-harness/compare/539505e2ff4c...3a09d8b9b0b2

          R. Tyler Croy added a comment -

          I have written a script, linked via Gist, which will help administrators identify whether their system is problematic.

          R. Tyler Croy added a comment - I have written a script, linked via Gist, which will help administrators identify whether their system is problematic.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/pom.xml
          test/src/test/java/jenkins/ClassPathTest.java
          http://jenkins-ci.org/commit/jenkins/fa96a02a3e39c0fa1d561ef254f6d36e40ed3b5e
          Log:
          [FIXED JENKINS-46754] Remove org.mindrot:jbcrypt:0.4 since we already bundle org.connectbot.jbcrypt:jbcrypt:1.0.0.

          (cherry picked from commit 1784f90806c1c1f39e307c722a3dd4f63850877e)

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/pom.xml test/src/test/java/jenkins/ClassPathTest.java http://jenkins-ci.org/commit/jenkins/fa96a02a3e39c0fa1d561ef254f6d36e40ed3b5e Log: [FIXED JENKINS-46754] Remove org.mindrot:jbcrypt:0.4 since we already bundle org.connectbot.jbcrypt:jbcrypt:1.0.0. (cherry picked from commit 1784f90806c1c1f39e307c722a3dd4f63850877e)

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/java/hudson/slaves/SlaveComputer.java
          core/src/main/java/jenkins/model/Jenkins.java
          pom.xml
          http://jenkins-ci.org/commit/jenkins/f9ad963d1fb7e9840cd79bf084c3ab180708aca0
          Log:
          Revert "JENKINS-46754 Revert "Upgrade Remoting to 3.11 (#2988)""

          This reverts commit f6ef88211b22d0aec54431820cfb5e5a9fa91610.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/java/hudson/slaves/SlaveComputer.java core/src/main/java/jenkins/model/Jenkins.java pom.xml http://jenkins-ci.org/commit/jenkins/f9ad963d1fb7e9840cd79bf084c3ab180708aca0 Log: Revert " JENKINS-46754 Revert "Upgrade Remoting to 3.11 (#2988)"" This reverts commit f6ef88211b22d0aec54431820cfb5e5a9fa91610.

            jglick Jesse Glick
            markewaite Mark Waite
            Votes:
            1 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: