|
||||||||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
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.