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

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

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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)
      

        Attachments

          Issue Links

            Activity

            Hide
            eskp 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.

            Show
            eskp 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.
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - Is anyone experiencing this issue despite setting the hudson.model.User.allowNonExistentUserToLogin system property?
            Hide
            jonathonmg Jonathon Golden added a comment -

            Daniel Beck,

            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.

            Show
            jonathonmg Jonathon Golden added a comment - Daniel Beck , 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.
            Hide
            sauraus 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.

            Show
            sauraus 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.
            Hide
            jglick 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.

            Show
            jglick 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.

              People

              • Assignee:
                kohsuke Kohsuke Kawaguchi
                Reporter:
                jchauncey Jonathan Chauncey
              • Votes:
                29 Vote for this issue
                Watchers:
                45 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: