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

SSH Slaves plugin fails the host verification of slaves with an IllegalArgumentException

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • ssh-slaves-plugin
    • Java 64bit 1.8.0.131
      Jenkins 2.46.3
      ssh-slaves-plugin 1.18 (and 1.19)

      When we upgrade the ssh slaves plugin on the latest stable jenkins we get :

      ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins.
      java.lang.IllegalArgumentException
        at com.trilead.ssh2.Connection.setServerHostKeyAlgorithms(Connection.java:1311)
        at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:796)
        at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:792)
        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:745)
      [06/13/17 13:10:39] Launch failed - cleaning up connection
      [06/13/17 13:10:39] [SSH] Connection closed.
      

       

          [JENKINS-44832] SSH Slaves plugin fails the host verification of slaves with an IllegalArgumentException

          Jesse Glick added a comment -

          Not sure how to reproduce from scratch—from code inspection it looks like there are some conditions where getPreferredKeyAlgorithms could return null or an empty list, which is invalid. What is the verification strategy for the affected slave?

          Anyway I think I can just disable the fix of JENKINS-42959 in cases where it would cause this exception, perhaps.

          Jesse Glick added a comment - Not sure how to reproduce from scratch—from code inspection it looks like there are some conditions where getPreferredKeyAlgorithms could return null or an empty list, which is invalid. What is the verification strategy for the affected slave? Anyway I think I can just disable the fix of JENKINS-42959 in cases where it would cause this exception, perhaps.

          Jesse Glick added a comment -
          		if ((algos == null) || (algos.length == 0))
          			throw new IllegalArgumentException();
          

          Jesse Glick added a comment - if ((algos == null ) || (algos.length == 0)) throw new IllegalArgumentException();

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/hudson/plugins/sshslaves/SSHLauncher.java
          src/main/java/hudson/plugins/sshslaves/verifiers/SshHostKeyVerificationStrategy.java
          http://jenkins-ci.org/commit/ssh-slaves-plugin/b9620eebd571c47f25e4c190ef6ea620b41f5c5a
          Log:
          [FIXED JENKINS-44832] IAE under unknown conditions due to empty or null list of preferred key algorithms.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/hudson/plugins/sshslaves/SSHLauncher.java src/main/java/hudson/plugins/sshslaves/verifiers/SshHostKeyVerificationStrategy.java http://jenkins-ci.org/commit/ssh-slaves-plugin/b9620eebd571c47f25e4c190ef6ea620b41f5c5a Log: [FIXED JENKINS-44832] IAE under unknown conditions due to empty or null list of preferred key algorithms.

          Nikolas Falco added a comment -

          The actual configuration for nodes is "Know host file Verification Strategy" (that means ~/.ssh/known_hosts file)

          With version 1.17 all slaves work without issue updating to 1.19 no way to connect. I got that error.

          I've try also to change the Verification Strategy save and back to Know host (maybe serialisation is changed) but with no luck.

          Actual setting for all slaves

          A known_hosts file on master

          jglick let me know if you need other file to profile the issue.

          Nikolas Falco added a comment - The actual configuration for nodes is "Know host file Verification Strategy" (that means ~/.ssh/known_hosts file) With version 1.17 all slaves work without issue updating to 1.19 no way to connect. I got that error. I've try also to change the Verification Strategy save and back to Know host (maybe serialisation is changed) but with no luck. Actual setting for all slaves A known_hosts file on master jglick let me know if you need other file to profile the issue.

          Jesse Glick added a comment -

          Based on the screenshot from nfalco I presume that KnownHosts.getPreferredServerHostkeyAlgorithmOrder is the culprit here. Indeed there are various documented conditions under which it would return null.

          Jesse Glick added a comment - Based on the screenshot from nfalco I presume that KnownHosts.getPreferredServerHostkeyAlgorithmOrder is the culprit here. Indeed there are various documented conditions under which it would return null.

          Jesse Glick added a comment -

          Releasing as 1.20.

          Jesse Glick added a comment - Releasing as 1.20.

          Jesse Glick added a comment -

          Potentially the better fix would be to return super.getPreferredKeyAlgorithms(computer) in this case. At any rate, my patch ought to restore the 1.17 behavior in this situation, which I guess is good enough for now. mc1arke can look into refinements later.

          Jesse Glick added a comment - Potentially the better fix would be to return super.getPreferredKeyAlgorithms(computer) in this case. At any rate, my patch ought to restore the 1.17 behavior in this situation, which I guess is good enough for now. mc1arke can look into refinements later.

          Nikolas Falco added a comment -

          I post also the config.xml of my 1.17 configuration (I'm back)

          Nikolas Falco added a comment - I post also the config.xml of my 1.17 configuration (I'm back)

          Jesse Glick added a comment -

          Nothing new there—the only relevant aspect of the configuration in Jenkins is that you are using the known-hosts option. The question (if anyone cares) is why getPreferredServerHostkeyAlgorithmOrder failed. UnknownHostException trying to look up the slave? More likely, no known-hosts entry for that machine in recommendHostkeyAlgorithms, or multiple entries with different key types. Again I will leave it to mc1arke to evaluate what the desirable behavior is—I am just releasing a hotfix.

          At any rate, try updating to 1.20 when it becomes available on the update center, which should be soon.

          Jesse Glick added a comment - Nothing new there—the only relevant aspect of the configuration in Jenkins is that you are using the known-hosts option. The question (if anyone cares) is why getPreferredServerHostkeyAlgorithmOrder failed. UnknownHostException trying to look up the slave? More likely, no known-hosts entry for that machine in recommendHostkeyAlgorithms , or multiple entries with different key types. Again I will leave it to mc1arke to evaluate what the desirable behavior is—I am just releasing a hotfix. At any rate, try updating to 1.20 when it becomes available on the update center, which should be soon.

          Nikolas Falco added a comment -

          I've download the hpi from the Jenkins JFrog repository

          It works, follow the log of one node:

          Warning: no key algorithms provided; JENKINS-42959 disabled
          [06/13/17 17:58:56] [SSH] Opening SSH connection to 10.0.7.188:22.
          [06/13/17 17:58:57] [SSH] SSH host key matches key in Known Hosts file. Connection will be allowed.
          [06/13/17 17:58:58] [SSH] Authentication successful.
          [06/13/17 17:58:58] [SSH] The remote users environment is:
          

          Nikolas Falco added a comment - I've download the hpi from the Jenkins JFrog repository It works, follow the log of one node: Warning: no key algorithms provided; JENKINS-42959 disabled [06/13/17 17:58:56] [SSH] Opening SSH connection to 10.0.7.188:22. [06/13/17 17:58:57] [SSH] SSH host key matches key in Known Hosts file. Connection will be allowed. [06/13/17 17:58:58] [SSH] Authentication successful. [06/13/17 17:58:58] [SSH] The remote users environment is:

            jglick Jesse Glick
            admincrowdiugo IUGO Admin
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: