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)

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

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

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.

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.

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?

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 >

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.

$ 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.
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

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:
https://github.com/opscode-cookbooks/jenkins/pull/289

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.

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

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
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

I am on 1.617 and I still get this error.

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?

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.

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.