Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43933

ssh identity is now ignored by cli http mode

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: cli
    • Labels:
    • Environment:
      Jenkins v2.46.2
    • Similar Issues:

      Description

      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.

        Attachments

          Activity

          j4m3s James Fellows created issue -
          Hide
          danielbeck Daniel Beck added a comment -

          James Fellows To clarify, the bug you're reporting is that Jenkins requires you to specify the user name when before, it didn't?

          Show
          danielbeck Daniel Beck added a comment - James Fellows To clarify, the bug you're reporting is that Jenkins requires you to specify the user name when before, it didn't?
          Hide
          j4m3s James Fellows added a comment - - edited

          Daniel Beck 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.

          Show
          j4m3s James Fellows added a comment - - edited Daniel Beck 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.
          Hide
          danielbeck Daniel Beck added a comment -

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

          Show
          danielbeck Daniel Beck added a comment - 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).
          Hide
          j4m3s James Fellows added a comment -

          Suggest you can close this issue Daniel Beck if it is not relevant to this JIRA project.

          Show
          j4m3s James Fellows added a comment - Suggest you can close this issue Daniel Beck if it is not relevant to this JIRA project.

            People

            • Assignee:
              Unassigned
              Reporter:
              j4m3s James Fellows
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: