Status: Resolved (View Workflow)
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)
- is blocking
JENKINS-20064 Cannot use CLI or URL with API token with Active Directory as the access control security realm
- is related to
JENKINS-44020 non-github accounts can't be used via jenkins-cli or REST APIs
- relates to
JENKINS-41745 Remoting-free CLI
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
Yes, I'm hitting this issue today with the latest version (1.570). Downgrading to 1.555 fixed the problem for now.
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?
Nevermind...This doesn't appear related. The CLI fails regardless if the AD plugin is installed or not.
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.
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.
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?
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:
 root @ xxxxx /home/jenkins > ls |grep jenkins-cli
 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
 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
 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
 root @ XXXXXXXX /home/jenkins >
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.
$ 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-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
$ 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 -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 -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.
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.
Exception in thread "main" java.io.EOFException
SERVER ERROR LOG:
06-Oct-2014 10:08:50 hudson.TcpSlaveAgentListener$ConnectionHandler run
INFO: Accepted connection #1 from /126.96.36.199:34528
Exception in thread "Thread-346" org.acegisecurity.userdetails.UsernameNotFoundException: User AutoJobBuilder not found in directory.
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.
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.
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:
Code changed in jenkins
User: Kohsuke Kawaguchi
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.
Integrated in jenkins_main_trunk #4005
[FIXED JENKINS-22346] (Revision 80e9f3f50c3425c9b9b2bfdb58b03a1f1bd10aa3)
Result = SUCCESS
kohsuke : 80e9f3f50c3425c9b9b2bfdb58b03a1f1bd10aa3
kohsuke You still need to document this on https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties
kohsuke Added documentation to the wiki. Please review the explanation.
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
Noting #1593, #1579, move
Code changed in jenkins
Merge branch 'master' into
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 #1593, #1579, move
Remove two fixes that were backported to RC
JENKINS-27183Avoid deadlock when using build-monitor-plugin
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.
Is anyone experiencing this issue despite setting the hudson.model.User.allowNonExistentUserToLogin system property?
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.
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.
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