I've been hit by this as well and believe this is a regression with v0.26 due to the authentication fix for #27045 (the actual code change is here: https://github.com/jenkinsci/github-oauth-plugin/pull/77). That commit was bad timing with the upstream jenkins-cli change from Jenkins v2.54 that deprecates the CLI's remoting protocol, so the `–username` and `–password` flags are no longer valid options.

With v0.26 of this plugin running on Jenkins v2.56, I haven't been able to get jenkins-cli authentication working properly via any of the client authentication modes, it always reports back as the "anonymous" user, so I can't actually perform any administrative tasks (which breaks our automated configuration management of Jenkins as well).

For now, manually downgrading the plugin to v0.25 using the hpi file has restored functionality, but obviously that's not a good long-term solution. If you need any further details about our setup, please let me know as I'd love to see this get an official fix.

I've been investigating the same observed behavior since Sunday.  It looks like in the override of CliAuthenticator at GithubSecurityRealm:522 is defaulting the Jenkins user for incoming CLI calls to `Jenkins.ANONYMOUS` when the username isn't explicitly passed in. I'd offer up a Pull, but I can't quite glean the motivation behind the new authenticator.

Since this is breaking known installations (and automations such as the Chef Jenkins cookbook which use the CLI  ), may I suggest we bump the priority to "major"?

For what it's worth, I made an attempt to work around the issue in https://github.com/jenkinsci/github-oauth-plugin/pull/82 .

Cheers.

And, I'm closing that Pull.  Since we don't subclass a default CLI Authenticator, we can't very well delegate.

Sorry, folks.

That documentation is out of date. The GitHub OAuth Plugin hasn't ever supported authentication via SSH or Jenkins CLI to my knowledge when I started maintaining it. I implemented --username and --password for Jenkins CLI by referring to Jenkins core source code. So if there's a better way please feel free to open a PR.

I personally avoid Jenkins CLI entirely and configure via the Script Console. Jenkins CLI has historically had many issues so I usually just disable it entirely. That's not to say the problem shouldn't be fixed.

SSH Authentication isn't possible because without a GitHub API token then user authorities (Jenkins groups) can't be determined from GitHub organizations and teams.

Hey, Sam.

Unfortunately, disabling the CLI isn't an option for our installations just now.  We configure most things through the Script Console as well, but we automate this via the Chef Jenkins Cookbook, which leverages the CLI to interact with the running installation.

Previously, when using the GitHub OAuth authentication scheme, CLI authentication was untouched.  So we've used the technique of creating a local Jenkins administration account, and setting up a key for the CLI to use for authentication during Chef runs (–username and --password aren't required for that use case).  That worked pretty well up to release 0.25 of the plugin.

I think the addition of authenticating the CLI via API key is a great addition, but it'd be nice if it delegated to the default CLI authorization model if what was passed wasn't an API key (a --username and --password for a local admin are probably another use case here).

Anyhow, upshot for now is that folks using the Chef Jenkins community cookbook are in some sadness if they want to upgrade to 0.26 of your fine plugin.  (Andhey— thanks for picking up maintenance of it!  I, for one, appreciate the great job you're doing.)

We too use a local user (set up via Ansible) to perform administrative tasks via the `jenkins-cli` and had previously relied on SSH auth, but more recently (since Jenkins v2.54) using the http client authentication mode with an API token. Before v0.26, this worked just fine and the admin user could utilize jenkins-cli while our normal users would auth via GitHub OAuth as expected. Everything in our Jenkins ecosystem is completely automated via Ansible, jenkins-cli, and Jenkins Job Builder...but that does not work with the recent changes since local users cannot authenticate at all.