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

CLI commands with private key for nonexistent user fail with EOFException from DataInputStream.readBoolean

      This started with 1.556.

      root@recipe-test-centos-64-x86-64 ~]# java -jar /tmp/kitchen/cache/jenkins-cli.jar -s http://recipe-test-centos-64-x86-64.vagrantup.com:8080 -i /tmp/kitchen/cache/jenkins-key help
      Exception in thread "main" java.io.EOFException
      	at java.io.DataInputStream.readBoolean(DataInputStream.java:244)
      	at hudson.cli.Connection.readBoolean(Connection.java:94)
      	at hudson.cli.CLI.authenticate(CLI.java:553)
      	at hudson.cli.CLI._main(CLI.java:464)
      	at hudson.cli.CLI.main(CLI.java:382)
      

          [JENKINS-22346] CLI commands with private key for nonexistent user fail with EOFException from DataInputStream.readBoolean

          Daniel Beck added a comment -

          kohsuke Added documentation to the wiki. Please review the explanation.

          Daniel Beck added a comment - kohsuke Added documentation to the wiki. Please review the explanation.

          Nowell Strite added a comment - - edited

          Any thoughts on when a release would get cut with this included? we have been waiting back on 1.555 until this landed. Thanks for doing this!

          Nowell Strite added a comment - - edited Any thoughts on when a release would get cut with this included? we have been waiting back on 1.555 until this landed. Thanks for doing this!

          Code changed in jenkins
          User: Daniel Beck
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/84800166b075118cec1845e49aa230ef8a23799c
          Log:
          Noting #1593, #1579, move JENKINS-22346, #1558

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Daniel Beck Path: changelog.html http://jenkins-ci.org/commit/jenkins/84800166b075118cec1845e49aa230ef8a23799c Log: Noting #1593, #1579, move JENKINS-22346 , #1558

          Code changed in jenkins
          User: tfennelly
          Path:
          changelog.html
          cli/pom.xml
          core/pom.xml
          core/src/main/java/hudson/model/AbstractItem.java
          debian/debian/changelog
          plugins/pom.xml
          pom.xml
          test/pom.xml
          war/pom.xml
          http://jenkins-ci.org/commit/jenkins/7e5063937c31ee33de29254f1f13f5d4aa0d6174
          Log:
          Merge branch 'master' into JENKINS-27256

          • master:
            Updated changelog
            updated changelog as a part of the release
            [maven-release-plugin] prepare for next development iteration
            [maven-release-plugin] prepare release jenkins-1.604
            Noting #1597
            Noting #1593, #1579, move JENKINS-22346, #1558
            Remove two fixes that were backported to RC
            JENKINS-27183 Avoid deadlock when using build-monitor-plugin

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: tfennelly Path: changelog.html cli/pom.xml core/pom.xml core/src/main/java/hudson/model/AbstractItem.java debian/debian/changelog plugins/pom.xml pom.xml test/pom.xml war/pom.xml http://jenkins-ci.org/commit/jenkins/7e5063937c31ee33de29254f1f13f5d4aa0d6174 Log: Merge branch 'master' into JENKINS-27256 master: Updated changelog updated changelog as a part of the release [maven-release-plugin] prepare for next development iteration [maven-release-plugin] prepare release jenkins-1.604 Noting #1597 Noting #1593, #1579, move JENKINS-22346 , #1558 Remove two fixes that were backported to RC JENKINS-27183 Avoid deadlock when using build-monitor-plugin

          I am on 1.617 and I still get this error.

          Jonathon Golden added a comment - I am on 1.617 and I still get this error.

          Simon KP added a comment -

          1.617 here as well and I still have the issue that causes authentication to fail when a key is used but authentication is disabled.

          Simon KP added a comment - 1.617 here as well and I still have the issue that causes authentication to fail when a key is used but authentication is disabled.

          Daniel Beck added a comment -

          Is anyone experiencing this issue despite setting the hudson.model.User.allowNonExistentUserToLogin system property?

          Daniel Beck added a comment - Is anyone experiencing this issue despite setting the hudson.model.User.allowNonExistentUserToLogin system property?

          danielbeck,

          Starting Jenkins with that property I can pass the private key successfully if security is turned off but the user with the corresponding public key still exists at /var/lib/jenkins/users. With security is turned off, if I pass the key and that user does not exist I just get an auth failure. I'm assuming this is the expected behavior but it would be helpful if there was a way to pass the key every time and just proceed anonymously if there is no need for the key yet. The use case I'm interested in this for is when managing the Jenkins instances with Puppet. This behavior creates a major chicken and egg dilemma. There is a workaround described here: https://forge.puppetlabs.com/rtyler/jenkins but is is not very desirable. Given that I can at least seed the user with a config file managed with puppet and using the java arg you suggested I have a better workaround now. It would be nice, however, if instead it behaved the way I described above.

          Jonathon Golden added a comment - danielbeck , Starting Jenkins with that property I can pass the private key successfully if security is turned off but the user with the corresponding public key still exists at /var/lib/jenkins/users. With security is turned off, if I pass the key and that user does not exist I just get an auth failure. I'm assuming this is the expected behavior but it would be helpful if there was a way to pass the key every time and just proceed anonymously if there is no need for the key yet. The use case I'm interested in this for is when managing the Jenkins instances with Puppet. This behavior creates a major chicken and egg dilemma. There is a workaround described here: https://forge.puppetlabs.com/rtyler/jenkins but is is not very desirable. Given that I can at least seed the user with a config file managed with puppet and using the java arg you suggested I have a better workaround now. It would be nice, however, if instead it behaved the way I described above.

          Actually what I've found is that as long as the non-AD user has an email address associated with a user on the AD everything will work... very weird.

          Antek Baranski added a comment - Actually what I've found is that as long as the non-AD user has an email address associated with a user on the AD everything will work... very weird.

          Jesse Glick added a comment -

          Whatever was “fixed”, this exception is still thrown under some conditions.

          As best I can make out, SshCliAuthenticator will write a boolean zero or more times. Typically once, I guess, but it is in a loop of some kind (cannot understand what it is looping over), and maybe zero if a CLI authentication failure is thrown. Then CliManagerImpl.authenticate runs every CliTransportAuthenticator in parallel (?!). Finally CLI.authenticate expects to read a boolean for every private key, and sometimes there is nothing to read so it throws this EOFException instead of explaining what is going on.

          I think I can reproduce this when you have multiple private keys (say, both DSA and RSA) are not using -i, and none of them match.

          Jesse Glick added a comment - Whatever was “fixed”, this exception is still thrown under some conditions. As best I can make out, SshCliAuthenticator will write a boolean zero or more times. Typically once, I guess, but it is in a loop of some kind (cannot understand what it is looping over), and maybe zero if a CLI authentication failure is thrown. Then CliManagerImpl.authenticate runs every CliTransportAuthenticator in parallel (?!). Finally CLI.authenticate expects to read a boolean for every private key, and sometimes there is nothing to read so it throws this EOFException instead of explaining what is going on. I think I can reproduce this when you have multiple private keys (say, both DSA and RSA) are not using -i , and none of them match.

            kohsuke Kohsuke Kawaguchi
            jchauncey Jonathan Chauncey
            Votes:
            29 Vote for this issue
            Watchers:
            44 Start watching this issue

              Created:
              Updated:
              Resolved: