Minor Following the recent major rewrite, the CLI no longer identifies the user by their SSH private key.
Previously, a cli.jar request did not need the username or password to be specified, just that the user had added their public key to their jenkins user config.
This new behaviour is the case whether the user specifies the -i option or not. Looking at the source code, hudson.cli.CLI does check that it can access the user's key(s), but then ignores them in the default (http) configuration.
If this is the new intended behaviour it may be worth specifying it in the documentation or release notes/ blog article as I suspect many other peoples' automations will fail as they upgrade to 2.46. The -i option should also be thrown as invalid in http mode.
The "fix" for clients is to specify the `-ssh` and `-user <xyz>` flags on the command line rather than leaving them out. I believe you also now have to manually enable the in-built ssh server in the jenkins config as it's disabled by default.
Slightly confusingly, you do still have to specify the `-s <protocol:host:port>` flag pointing to the http base url & port, even though you're using ssh mode.
[JENKINS-43933] ssh identity is now ignored by cli http mode
danielbeck that's correct, I'm reporting that the behaviour has changed but is not mentioned in the docs or announcement - leading to connections suddenly failing after the upgrade with an authentication-failed message. It took a long time (and looking in the source code) to figure out what was suddenly going wrong so I think it ought to be added to the docs.
I'm also reporting that the username may not even be used (certainly in the old authentication process the username wasn't used - the user was identified from their key). If that's still the case, it should not be a required parameter.
Thirdly I believe the -i switch should not be accepted alongside the -ssh switch, they are incompatible and the -i is ignored if -ssh is specified. Accepting the -i parameter implies its parameter is consumed/ taken into account when I don't believe it is.
Finally, the -s <protocol:host:port> parameter should not be required - or if it is, the protocol should not be included. The connection is being made over ssh thanks to the -ssh switch, not https, so it is counter-intuitive to expect an http(s) protocol to be specified.
Apologies for the number of "I believe"s in the above. A month on from the initial report I'm struggling to remember all the details - I should have made the initial ticket clearer.
James Fellows
added a comment - - edited danielbeck that's correct, I'm reporting that the behaviour has changed but is not mentioned in the docs or announcement - leading to connections suddenly failing after the upgrade with an authentication-failed message. It took a long time (and looking in the source code) to figure out what was suddenly going wrong so I think it ought to be added to the docs.
I'm also reporting that the username may not even be used (certainly in the old authentication process the username wasn't used - the user was identified from their key). If that's still the case, it should not be a required parameter.
Thirdly I believe the -i switch should not be accepted alongside the -ssh switch, they are incompatible and the -i is ignored if -ssh is specified. Accepting the -i parameter implies its parameter is consumed/ taken into account when I don't believe it is.
Finally, the -s <protocol:host:port> parameter should not be required - or if it is, the protocol should not be included. The connection is being made over ssh thanks to the -ssh switch, not https, so it is counter-intuitive to expect an http(s) protocol to be specified.
Apologies for the number of "I believe"s in the above. A month on from the initial report I'm struggling to remember all the details - I should have made the initial ticket clearer. I'm reporting that the behaviour has changed but is not mentioned in the docs or announcement - leading to connections suddenly failing after the upgrade with an authentication-failed message. … I think it ought to be added to the docs.
That's an issue with the docs. But from reading https://jenkins.io/doc/book/managing/cli/ it seems correctly documented. Changing the mode includes changing how auth works. In any case, if the above documentation is wrong, this is a problem with that, rather than Jenkins. If so, please file an issue in the WEBSITE JIRA project about that.
I believe the -i switch should not be accepted alongside the -ssh switch
Please confirm and file separately if this is the case.
the -s <protocol:host:port> parameter should not be required
The client does send an HTTP request querying Jenkins for information (specifically, the X-SSH-Endpoint header, as admins control where to go for SSH – no sane way for users to know e.g. which port it runs on).
James Fellows
added a comment - Suggest you can close this issue danielbeck if it is not relevant to this JIRA project.
James Fellows
added a comment - Suggest you can close this issue danielbeck if it is not relevant to this JIRA project. 
j4m3s To clarify, the bug you're reporting is that Jenkins requires you to specify the user name when before, it didn't?