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

          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

          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.

          Also broken in LTS Version 1.565.1.

          I get the following LDAP error when trying to use CLI commands:

          Exception in thread "Thread-XX" org.acegisecurity.userdetails.UsernameNotFoundException: User XXXXX not found in directory.
          	at org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:126)
          	at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:787)
          	at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:738)
          	at jenkins.security.ImpersonatingUserDetailsService.loadUserByUsername(ImpersonatingUserDetailsService.java:32)
          	at hudson.model.User.impersonate(User.java:266)
          	at org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:44)
          	at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:109)
          
          

          And of course related with this:

          Exception in thread "main" java.io.EOFException
          	at java.io.DataInputStream.readBoolean(DataInputStream.java:244)
          	at hudson.cli.Connection.readBoolean(Connection.java:95)
          	at hudson.cli.CLI.authenticate(CLI.java:634)
          	at hudson.cli.CLI._main(CLI.java:474)
          	at hudson.cli.CLI.main(CLI.java:384)
          

          Any suggestions for temporary workarounds?

          Daniel Christophis added a comment - Also broken in LTS Version 1.565.1. I get the following LDAP error when trying to use CLI commands: Exception in thread " Thread -XX" org.acegisecurity.userdetails.UsernameNotFoundException: User XXXXX not found in directory. at org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:126) at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:787) at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:738) at jenkins.security.ImpersonatingUserDetailsService.loadUserByUsername(ImpersonatingUserDetailsService.java:32) at hudson.model.User.impersonate(User.java:266) at org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:44) at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:109) And of course related with this: Exception in thread "main" java.io.EOFException at java.io.DataInputStream.readBoolean(DataInputStream.java:244) at hudson.cli.Connection.readBoolean(Connection.java:95) at hudson.cli.CLI.authenticate(CLI.java:634) at hudson.cli.CLI._main(CLI.java:474) at hudson.cli.CLI.main(CLI.java:384) Any suggestions for temporary workarounds?

          Samu Wikstedt added a comment -

          Agreed that ssh-key based authentication for jenkins-cli is broken somewhere between LTS versions 1.554.2 and 1.565.2

          See the small test below:

          [42] root @ xxxxx /home/jenkins > ls |grep jenkins-cli
          jenkins-cli.jar_1.532.2
          jenkins-cli.jar_1.554.2
          jenkins-cli.jar_1.565.2

          [43] root @ xxxxxx /home/jenkins > sudo -u jenkins java -jar jenkins-cli.jar_1.532.2 -s http://xxxx.xxxx.xxxx:8080 -i /var/lib/jenkins/.ssh/id_rsa.pub version
          1.565.2

          [44] root @ xxxxxx /home/jenkins > sudo -u jenkins java -jar jenkins-cli.jar_1.554.2 -s http://xxx.xxx.xxxx:8080 -i /var/lib/jenkins/.ssh/id_rsa.pub version
          1.565.2

          [45] root @ XXXXXXX /home/jenkins > sudo -u jenkins java -jar jenkins-cli.jar_1.565.2 -s http://xxx.xxx.xxxx:8080 -i /var/lib/jenkins/.ssh/id_rsa.pub version
          Exception in thread "main" java.io.IOException: Invalid PEM structure, '-----BEGIN...' missing
          at com.trilead.ssh2.crypto.PEMDecoder.parsePEM(PEMDecoder.java:138)
          at com.trilead.ssh2.crypto.PEMDecoder.decode(PEMDecoder.java:313)
          at hudson.cli.PrivateKeyProvider.loadKey(PrivateKeyProvider.java:143)
          at hudson.cli.PrivateKeyProvider.loadKey(PrivateKeyProvider.java:126)
          at hudson.cli.PrivateKeyProvider.readFrom(PrivateKeyProvider.java:107)
          at hudson.cli.CLI._main(CLI.java:428)
          at hudson.cli.CLI.main(CLI.java:382)
          [46] root @ XXXXXXXX /home/jenkins >

          Samu Wikstedt added a comment - Agreed that ssh-key based authentication for jenkins-cli is broken somewhere between LTS versions 1.554.2 and 1.565.2 See the small test below: [42] root @ xxxxx /home/jenkins > ls |grep jenkins-cli jenkins-cli.jar_1.532.2 jenkins-cli.jar_1.554.2 jenkins-cli.jar_1.565.2 [43] root @ xxxxxx /home/jenkins > sudo -u jenkins java -jar jenkins-cli.jar_1.532.2 -s http://xxxx.xxxx.xxxx:8080 -i /var/lib/jenkins/.ssh/id_rsa.pub version 1.565.2 [44] root @ xxxxxx /home/jenkins > sudo -u jenkins java -jar jenkins-cli.jar_1.554.2 -s http://xxx.xxx.xxxx:8080 -i /var/lib/jenkins/.ssh/id_rsa.pub version 1.565.2 [45] root @ XXXXXXX /home/jenkins > sudo -u jenkins java -jar jenkins-cli.jar_1.565.2 -s http://xxx.xxx.xxxx:8080 -i /var/lib/jenkins/.ssh/id_rsa.pub version Exception in thread "main" java.io.IOException: Invalid PEM structure, '-----BEGIN...' missing at com.trilead.ssh2.crypto.PEMDecoder.parsePEM(PEMDecoder.java:138) at com.trilead.ssh2.crypto.PEMDecoder.decode(PEMDecoder.java:313) at hudson.cli.PrivateKeyProvider.loadKey(PrivateKeyProvider.java:143) at hudson.cli.PrivateKeyProvider.loadKey(PrivateKeyProvider.java:126) at hudson.cli.PrivateKeyProvider.readFrom(PrivateKeyProvider.java:107) at hudson.cli.CLI._main(CLI.java:428) at hudson.cli.CLI.main(CLI.java:382) [46] root @ XXXXXXXX /home/jenkins >

          Mickael Ange added a comment - - edited

          Hi,

          FYI: I have just installed the latest stable Jenkins version (1.565.3 LTS) and I can list plugins using CLI without the above exception.

          Hudson version from CLI
          $ java -jar ./cli-1.424.6-jar-with-dependencies.jar -s http://192.168.1.245:8080 version
          1.565.3
          

          I have activated security, created a user with admin role and added public ssh keys for my user for 2 different machines (Jenkins host and a workstation) both work.
          The format of my public SSH key added to my Jenkins user account is:

          SSH Public Keys
          ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD3sZLaPWJNgMlrPlebOOQ<public key truncated>
          51Nz+IPoDKQ7M8LfT7jquIVTyTM2ncz3oa1HPtbXxtznUe5 mickael@jenkins
          ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDvW0XDs8BH+GjY/77gXQ6O5jhGNB9<public key truncated>Bxc+wWMT+HlrgVB+FxyANa/PvMCNQ5Q82Mz0zrCPCVldK1LrHZJOsxL6zrYs5vG/oRpiybkyqw6Zf0y4IyShlqUCUqrJmy+61oWUrR0PX2xJ8BJuQ/kheEozGQE9K2tZ2nPAFj mickael@desktop
          
          Plugins list from CLI
          $ java -jar ./cli-1.424.6-jar-with-dependencies.jar -s http://192.168.1.245:8080 list-plugins
          subversion                Subversion Plug-in                   1.54 (2.4.3)
          matrix-project            Matrix Project Plugin                1.2 (1.3)
          external-monitor-job      External Monitor Job Type Plugin     1.2
          cvs                       CVS Plug-in                          2.11 (2.12)
          ssh-slaves                SSH Slaves plugin                    1.5 (1.7.1)
          matrix-auth               Matrix Authorization Strategy Plugin 1.1 (1.2)
          ssh-credentials           SSH Credentials Plugin               1.6 (1.9)
          ant                       Ant Plugin                           1.2
          translation               Translation Assistance plugin        1.10 (1.11)
          credentials               Credentials Plugin                   1.9.4 (1.16.1)
          pam-auth                  PAM Authentication plugin            1.1
          ldap                      LDAP Plugin                          1.6 (1.10.2)
          javadoc                   Javadoc Plugin                       1.1 (1.2)
          windows-slaves            Windows Slaves Plugin                1.0
          maven-plugin              Maven Integration plugin             2.3 (2.6)
          mailer                    Mailer Plugin                        1.8 (1.11)
          antisamy-markup-formatter OWASP Markup Formatter Plugin        1.1 (1.2)
          
          Java on the desktop
          $ java -version
          java version "1.7.0_25"
          Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
          Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
          
          Java on Jenkins host
          $ java -version
          java version "1.7.0_67"
          Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
          Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
          

          Hoping that could help.
          Cheers

          Mickael Ange added a comment - - edited Hi, FYI: I have just installed the latest stable Jenkins version (1.565.3 LTS) and I can list plugins using CLI without the above exception. Hudson version from CLI $ java -jar ./cli-1.424.6-jar-with-dependencies.jar -s http: //192.168.1.245:8080 version 1.565.3 I have activated security, created a user with admin role and added public ssh keys for my user for 2 different machines (Jenkins host and a workstation) both work. The format of my public SSH key added to my Jenkins user account is: SSH Public Keys ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD3sZLaPWJNgMlrPlebOOQ< public key truncated> 51Nz+IPoDKQ7M8LfT7jquIVTyTM2ncz3oa1HPtbXxtznUe5 mickael@jenkins ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDvW0XDs8BH+GjY/77gXQ6O5jhGNB9< public key truncated>Bxc+wWMT+HlrgVB+FxyANa/PvMCNQ5Q82Mz0zrCPCVldK1LrHZJOsxL6zrYs5vG/oRpiybkyqw6Zf0y4IyShlqUCUqrJmy+61oWUrR0PX2xJ8BJuQ/kheEozGQE9K2tZ2nPAFj mickael@desktop Plugins list from CLI $ java -jar ./cli-1.424.6-jar-with-dependencies.jar -s http: //192.168.1.245:8080 list-plugins subversion Subversion Plug-in 1.54 (2.4.3) matrix-project Matrix Project Plugin 1.2 (1.3) external-monitor-job External Monitor Job Type Plugin 1.2 cvs CVS Plug-in 2.11 (2.12) ssh-slaves SSH Slaves plugin 1.5 (1.7.1) matrix-auth Matrix Authorization Strategy Plugin 1.1 (1.2) ssh-credentials SSH Credentials Plugin 1.6 (1.9) ant Ant Plugin 1.2 translation Translation Assistance plugin 1.10 (1.11) credentials Credentials Plugin 1.9.4 (1.16.1) pam-auth PAM Authentication plugin 1.1 ldap LDAP Plugin 1.6 (1.10.2) javadoc Javadoc Plugin 1.1 (1.2) windows-slaves Windows Slaves Plugin 1.0 maven-plugin Maven Integration plugin 2.3 (2.6) mailer Mailer Plugin 1.8 (1.11) antisamy-markup-formatter OWASP Markup Formatter Plugin 1.1 (1.2) Java on the desktop $ java -version java version "1.7.0_25" Java(TM) SE Runtime Environment (build 1.7.0_25-b15) Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode) Java on Jenkins host $ java -version java version "1.7.0_67" Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) Hoping that could help. Cheers

          I had exactly the same issue.However, i have narrowed this functionality working for us in 1.554_3 ( http://mirrors.jenkins-ci.org/war-stable/1.554.3/) and newer version is failing.

          We use LDAP for security. All the users are validated by AD, and the roles are retrieved from LDAP. We can login with LDAP user/pass successfully. If i have a keyfile attached to the AD user, the CLI functionality works fine too.
          However, we also have a user called "AutoJobBuilder" which does not exists in LDAP, and i have entered that as user in the jenkins [ Configure Global Security -> Authorization -> Project-based Matrix Authorization Strategy ]
          [ Security Realm -> LDAP ]

          Last week we upgraded jenkins to latest version, and we started facing this issue. As i started my investigation i find that till version 1.554_3 it works fine, and then it stops working.

          As i understand, the issue seems to be a change in functionality. pre 1.554_3, the "static" user is not checked in AD. but post 1.554_3, its checked in AD for existence, but does not exists and it fails.

          REQUEST :
          + scripts/generate_jenkins_job.sh
          Exception in thread "main" java.io.EOFException
          at java.io.DataInputStream.readBoolean(DataInputStream.java:244)
          at hudson.cli.Connection.readBoolean(Connection.java:93)
          at hudson.cli.CLI.authenticate(CLI.java:560)
          at hudson.cli.CLI._main(CLI.java:471)
          at hudson.cli.CLI.main(CLI.java:382)

          SERVER ERROR LOG:
          06-Oct-2014 10:08:50 hudson.TcpSlaveAgentListener$ConnectionHandler run
          INFO: Accepted connection #1 from /161.2.42.207:34528
          Exception in thread "Thread-346" org.acegisecurity.userdetails.UsernameNotFoundException: User AutoJobBuilder not found in directory.
          at org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:126)
          at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:627)
          at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:589)
          at jenkins.security.ImpersonatingUserDetailsService.loadUserByUsername(ImpersonatingUserDetailsService.java:32)
          at hudson.model.User.impersonate(User.java:282)
          at org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:44)
          at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:110)
          06-Oct-2014 10:08:52 hudson.model.Run execute

          Aneez Abubacker added a comment - I had exactly the same issue.However, i have narrowed this functionality working for us in 1.554_3 ( http://mirrors.jenkins-ci.org/war-stable/1.554.3/ ) and newer version is failing. We use LDAP for security. All the users are validated by AD, and the roles are retrieved from LDAP. We can login with LDAP user/pass successfully. If i have a keyfile attached to the AD user, the CLI functionality works fine too. However, we also have a user called "AutoJobBuilder" which does not exists in LDAP, and i have entered that as user in the jenkins [ Configure Global Security -> Authorization -> Project-based Matrix Authorization Strategy ] [ Security Realm -> LDAP ] Last week we upgraded jenkins to latest version, and we started facing this issue. As i started my investigation i find that till version 1.554_3 it works fine, and then it stops working. As i understand, the issue seems to be a change in functionality. pre 1.554_3, the "static" user is not checked in AD. but post 1.554_3, its checked in AD for existence, but does not exists and it fails. REQUEST : + scripts/generate_jenkins_job.sh Exception in thread "main" java.io.EOFException at java.io.DataInputStream.readBoolean(DataInputStream.java:244) at hudson.cli.Connection.readBoolean(Connection.java:93) at hudson.cli.CLI.authenticate(CLI.java:560) at hudson.cli.CLI._main(CLI.java:471) at hudson.cli.CLI.main(CLI.java:382) SERVER ERROR LOG: 06-Oct-2014 10:08:50 hudson.TcpSlaveAgentListener$ConnectionHandler run INFO: Accepted connection #1 from /161.2.42.207:34528 Exception in thread "Thread-346" org.acegisecurity.userdetails.UsernameNotFoundException: User AutoJobBuilder not found in directory. at org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:126) at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:627) at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:589) at jenkins.security.ImpersonatingUserDetailsService.loadUserByUsername(ImpersonatingUserDetailsService.java:32) at hudson.model.User.impersonate(User.java:282) at org.jenkinsci.main.modules.cli.auth.ssh.SshCliAuthenticator.authenticate(SshCliAuthenticator.java:44) at hudson.cli.CliManagerImpl$2.run(CliManagerImpl.java:110) 06-Oct-2014 10:08:52 hudson.model.Run execute

          Also - i have just checked this with the latest LDAP plugin ( 1.11) and that fails.

          Aneez Abubacker added a comment - Also - i have just checked this with the latest LDAP plugin ( 1.11) and that fails.

          Jesse Glick added a comment -

          I think there are a couple of issues here.

          First of all, the exception from DataInputStream.readBoolean is cryptic and surely a mistake. If authentication is denied, the CLI should print a polite message to that effect.

          The main issue is that former versions of Jenkins permitted login via CLI for a user defined in Jenkins configuration with an SSH public key but not present in the actual SecurityRealm, and this is no longer permitted.

          In general, Jenkins lacks a feature for creating a phony user identity (principal) with limited authority that may be used from scripts and automations. If an operation requires any special permission at all, you must authenticate as a real user.

          Jesse Glick added a comment - I think there are a couple of issues here. First of all, the exception from DataInputStream.readBoolean is cryptic and surely a mistake. If authentication is denied, the CLI should print a polite message to that effect. The main issue is that former versions of Jenkins permitted login via CLI for a user defined in Jenkins configuration with an SSH public key but not present in the actual SecurityRealm , and this is no longer permitted. In general, Jenkins lacks a feature for creating a phony user identity (principal) with limited authority that may be used from scripts and automations. If an operation requires any special permission at all, you must authenticate as a real user.

          Indra Gunawan added a comment -

          I ran into this problem on our test Jenkins environment running LTS version 1.565.2. On that Jenkins, any user can do anything so the security is not enabled. It looks like this is no longer supported?

          Even after I enable security and use LDAP but make any logged-user to be able to do anything that is also not working. (I upgraded LDAP from 1.6 to 1.8)

          Oct 6, 2014 3:59:54 PM org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 handleBindException
          WARNING: Failed to bind to LDAP: userDnuid=ingunawa,ou=active,ou=employees,ou=people,o=<mycompany>.com username=ingunawa
          javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]

          Indra Gunawan added a comment - I ran into this problem on our test Jenkins environment running LTS version 1.565.2. On that Jenkins, any user can do anything so the security is not enabled. It looks like this is no longer supported? Even after I enable security and use LDAP but make any logged-user to be able to do anything that is also not working. (I upgraded LDAP from 1.6 to 1.8) Oct 6, 2014 3:59:54 PM org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 handleBindException WARNING: Failed to bind to LDAP: userDnuid=ingunawa,ou=active,ou=employees,ou=people,o=<mycompany>.com username=ingunawa javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]

          Thanks for the explanation Jesse. I've updated our Jenkins cookbook with better documentation of the issue along with a slight workaround that fixes some cases:
          https://github.com/opscode-cookbooks/jenkins/pull/289

          Seth Chisamore added a comment - Thanks for the explanation Jesse. I've updated our Jenkins cookbook with better documentation of the issue along with a slight workaround that fixes some cases: https://github.com/opscode-cookbooks/jenkins/pull/289

          Eugenio Marzo added a comment -

          Hi,
          same problem on Jenkins ver. 1.580.2 with the LDAP plugin 1.11.

          Eugenio Marzo added a comment - Hi, same problem on Jenkins ver. 1.580.2 with the LDAP plugin 1.11.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          core/src/main/java/hudson/model/User.java
          http://jenkins-ci.org/commit/jenkins/80e9f3f50c3425c9b9b2bfdb58b03a1f1bd10aa3
          Log:
          [FIXED JENKINS-22346]

          The original motivation for the fix (to prevent users from logging in
          once he's removed from the backend identity database) is legitimate,
          but it affected too many users.

          So as an escape hatch / non-promoted feature switch, I'm adding this
          option to bring back the old behaviour.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/src/main/java/hudson/model/User.java http://jenkins-ci.org/commit/jenkins/80e9f3f50c3425c9b9b2bfdb58b03a1f1bd10aa3 Log: [FIXED JENKINS-22346] The original motivation for the fix (to prevent users from logging in once he's removed from the backend identity database) is legitimate, but it affected too many users. So as an escape hatch / non-promoted feature switch, I'm adding this option to bring back the old behaviour.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #4005
          [FIXED JENKINS-22346] (Revision 80e9f3f50c3425c9b9b2bfdb58b03a1f1bd10aa3)

          Result = SUCCESS
          kohsuke : 80e9f3f50c3425c9b9b2bfdb58b03a1f1bd10aa3
          Files :

          • core/src/main/java/hudson/model/User.java
          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #4005 [FIXED JENKINS-22346] (Revision 80e9f3f50c3425c9b9b2bfdb58b03a1f1bd10aa3) Result = SUCCESS kohsuke : 80e9f3f50c3425c9b9b2bfdb58b03a1f1bd10aa3 Files : core/src/main/java/hudson/model/User.java changelog.html

          Daniel Beck added a comment -

          Daniel Beck added a comment - kohsuke You still need to document this on https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties

          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: