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

          Jonathan Chauncey created issue -

          Greg BOUGEARD added a comment -

          I have the same issue and there is the log I found (it used to work in 1.542 and does not anymore after updated to 1.556) :

          Mar 28, 2014 10:53:43 AM WARNING org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator authenticate

          CLI authentication failure
          java.io.EOFException
          at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
          at java.io.DataInputStream.readUTF(DataInputStream.java:589)
          at java.io.DataInputStream.readUTF(DataInputStream.java:564)
          at hudson.cli.Connection.readUTF(Connection.java:86)
          at hudson.cli.Connection.verifyIdentity(Connection.java:245)
          at org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:39)
          at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:109)

          Greg BOUGEARD added a comment - I have the same issue and there is the log I found (it used to work in 1.542 and does not anymore after updated to 1.556) : Mar 28, 2014 10:53:43 AM WARNING org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator authenticate CLI authentication failure java.io.EOFException at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340) at java.io.DataInputStream.readUTF(DataInputStream.java:589) at java.io.DataInputStream.readUTF(DataInputStream.java:564) at hudson.cli.Connection.readUTF(Connection.java:86) at hudson.cli.Connection.verifyIdentity(Connection.java:245) at org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:39) at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:109)

          Eric Helgeson added a comment -

          This worked as recently as 1.555. Broken in 1.556 & 1.557

          Eric Helgeson added a comment - This worked as recently as 1.555. Broken in 1.556 & 1.557

          Eric Helgeson added a comment -

          I see you are likely using the chef Jenkins recipe. To pin to 1.555, take a look here https://github.com/opscode-cookbooks/jenkins/issues/170

          Eric Helgeson added a comment - I see you are likely using the chef Jenkins recipe. To pin to 1.555, take a look here https://github.com/opscode-cookbooks/jenkins/issues/170
          Eric Helgeson made changes -
          Link New: This issue is related to JENKINS-20064 [ JENKINS-20064 ]

          John Engelman added a comment -

          Is this still an issue with the latest versions of Jenkins?

          John Engelman added a comment - Is this still an issue with the latest versions of Jenkins?

          Yes, I'm hitting this issue today with the latest version (1.570). Downgrading to 1.555 fixed the problem for now.

          Andrew Goktepe added a comment - Yes, I'm hitting this issue today with the latest version (1.570). Downgrading to 1.555 fixed the problem for now.

          John Engelman added a comment -

          I think the problem is this line: https://github.com/jenkinsci/jenkins/blob/0e339d7a454df119995b896eea14f09a099f99b5/core/src/main/java/hudson/model/User.java#L264
          which was introduced in https://github.com/jenkinsci/jenkins/commit/0e339d7a454df119995b896eea14f09a099f99b5.
          The User object is now re-throwing the UsernameNotFoundException instead of eating it and failing through to the UsernamePasswordAuthenticationToken.

          The Active Directory plugin throws this exception when the user is not found in AD environment: https://github.com/jenkinsci/active-directory-plugin/blob/master/src/main/java/hudson/plugins/active_directory/ActiveDirectoryAuthenticationProvider.java#L110

          So the question is, what's the correct solution? Should the Active Directory plugin be throwing a different exception in this instance (perhaps the UserMayOrMayNotExistException)? Or should Jenkins do something different when it encounters the UsernameNotFoundException?

          John Engelman added a comment - I think the problem is this line: https://github.com/jenkinsci/jenkins/blob/0e339d7a454df119995b896eea14f09a099f99b5/core/src/main/java/hudson/model/User.java#L264 which was introduced in https://github.com/jenkinsci/jenkins/commit/0e339d7a454df119995b896eea14f09a099f99b5 . The User object is now re-throwing the UsernameNotFoundException instead of eating it and failing through to the UsernamePasswordAuthenticationToken. The Active Directory plugin throws this exception when the user is not found in AD environment: https://github.com/jenkinsci/active-directory-plugin/blob/master/src/main/java/hudson/plugins/active_directory/ActiveDirectoryAuthenticationProvider.java#L110 So the question is, what's the correct solution? Should the Active Directory plugin be throwing a different exception in this instance (perhaps the UserMayOrMayNotExistException)? Or should Jenkins do something different when it encounters the UsernameNotFoundException?

          John Engelman added a comment -

          Nevermind...This doesn't appear related. The CLI fails regardless if the AD plugin is installed or not.

          John Engelman added a comment - Nevermind...This doesn't appear related. The CLI fails regardless if the AD plugin is installed or not.

          John Engelman added a comment -

          Ok, so I pulled the latest code and did some testing and this is what I've found.
          It is related to the change in User.java -https://github.com/jenkinsci/jenkins/blob/0e339d7a454df119995b896eea14f09a099f99b5/core/src/main/java/hudson/model/User.java#L264
          That line re-throws the UsernameNotFoundException.

          Scenario #1
          Security is not enabled. User passes a key to jenkins-cli -i <key-file> => returns an EOFException.
          Commented out throw UsernameNotFoundException in User.java.
          Test #1 -> pass key for user defined when security was enabled => Jenkins reports the user as authenticated
          Test #2 -> pass random private key => Jenkins reports Authentication failed.

          Scenario #2
          AD security is enabled. User passes a key for a user defined in Jenkin's user database => returns an EOFException.
          Change the AD plugin to throw a UserMayOrMayNotExistException.
          Test #1 -> pass key for user defined in AD => Jenkins reports the user as authenticated.
          Test #2 -> pass key for user defined in Jenkins Database => Jenkins reports the user as authenticated.
          Test #3 -> pass random private key => Jenkins reports auth failed.

          I think the issue here is that for Scenario #1, the SecurityRealm.None implementation throws a UsernameNotFoundException for loadByUsername(id). This is no handled differently. I suspect the answer is that it should throw s UserMayOrMayNotExistException instead.

          This would be the same problem with the AD plugin...it throws a UsernameNotFoundException if the user doesn't exist in AD, that exception percolates up and causes the EOF. Instead, the plugin should throw UserMayOrMayNotExistException, so Jenkins falls back.

          John Engelman added a comment - Ok, so I pulled the latest code and did some testing and this is what I've found. It is related to the change in User.java - https://github.com/jenkinsci/jenkins/blob/0e339d7a454df119995b896eea14f09a099f99b5/core/src/main/java/hudson/model/User.java#L264 That line re-throws the UsernameNotFoundException. Scenario #1 Security is not enabled. User passes a key to jenkins-cli -i <key-file> => returns an EOFException. Commented out throw UsernameNotFoundException in User.java. Test #1 -> pass key for user defined when security was enabled => Jenkins reports the user as authenticated Test #2 -> pass random private key => Jenkins reports Authentication failed. Scenario #2 AD security is enabled. User passes a key for a user defined in Jenkin's user database => returns an EOFException. Change the AD plugin to throw a UserMayOrMayNotExistException. Test #1 -> pass key for user defined in AD => Jenkins reports the user as authenticated. Test #2 -> pass key for user defined in Jenkins Database => Jenkins reports the user as authenticated. Test #3 -> pass random private key => Jenkins reports auth failed. I think the issue here is that for Scenario #1, the SecurityRealm.None implementation throws a UsernameNotFoundException for loadByUsername(id). This is no handled differently. I suspect the answer is that it should throw s UserMayOrMayNotExistException instead. This would be the same problem with the AD plugin...it throws a UsernameNotFoundException if the user doesn't exist in AD, that exception percolates up and causes the EOF. Instead, the plugin should throw UserMayOrMayNotExistException, so Jenkins falls back.

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

              Created:
              Updated:
              Resolved: