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.

Can you give me some example Jenkins CLI commands that you expect to work but don't? Like how you authenticate and perhaps a few examples of: 1) before command, 2) some command, 3) expected result. If I can replicate that locally it would give me a goal to work toward. And if someone proposes a change it would give me a test case to validate the change.

Similar to the above with the -i flag

java -jar jenkins-cli.jar -s http://localhost:8080 -i /etc/jenkins/admin/id_rsa who-am-i

Where the id_rsa file is a public key for a local (not GHE) admin user.

The -i flag like Jake shows is what we used prior to Jenkins v2.54, which changed a few things. I think that command will still work if you explicitly use the deprecated -remoting auth method, but the newer syntax is slightly different. Also, Jenkins no longer enables the internal Apache SSH server by default, so if you want to test that, you have to manually enable it, and then use the newer ssh syntax:

java -jar jenkins-cli.jar -s http://localhost:8080 -i /etc/jenkins/admin/id_rsa -ssh -user elasticdog who-am-i

 ...so the username is no longer inferred (you must be explicit) and you also have to say you're using the ssh client authentication method. That should show the same behavior as long as you're defined an SSH public key on the user's configuration (similar to what you do to set an API token).

Thanks for the feedback. I'll see if I can resolve it.

FWIW here's using -username and -pasword options:

$ java -jar jenkins-cli.jar -s http://localhost:8080/ -noKeyAuth who-am-i --username samrocketman --password [REDACTED personal access token]
Authenticated as: samrocketman
Authorities:
  authenticated
  jenkinsci
  jenkinsci*Everyone
  sandscape
  kata-seeds
  kata-seeds*Groovy
  Gitorious-backup
  Gitorious-backup*Owners
  gimp-ci
  gimp-ci*developers

I understand the fix. Patch incoming.

Code changed in jenkins
User: Sam Gleske
Path:
src/main/java/org/jenkinsci/plugins/GithubSecurityRealm.java
http://jenkins-ci.org/commit/github-oauth-plugin/4690bfb6ce3989c940f5dd5f93dfc1ef315ea5de
Log:
JENKINS-43822 Fix Jenkins CLI transport auth

This fixes using authentication in the following ways using HTTP
transport auth and SSH authentication.

Please review my PR.

https://github.com/jenkinsci/github-oauth-plugin/pull/83

I tested it locally and it resolved the issue for both cases presented.

Code changed in jenkins
User: Sam Gleske
Path:
src/main/java/org/jenkinsci/plugins/GithubSecurityRealm.java
http://jenkins-ci.org/commit/github-oauth-plugin/8d7c27e2f4808d54aaaa4f8f5f3b732bb634ffba
Log:
JENKINS-43822 Fix Jenkins CLI transport auth

This fixes using authentication in the following ways using HTTP
transport auth and SSH authentication.

Code changed in jenkins
User: Sam Gleske
Path:
src/main/java/org/jenkinsci/plugins/GithubSecurityRealm.java
http://jenkins-ci.org/commit/github-oauth-plugin/72075ba852186552e2779e59fa65e34d5a93edd4
Log:
Merge pull request #83 from jenkinsci/fix-transport-auth

JENKINS-43822 Fix Jenkins CLI transport auth

Compare: https://github.com/jenkinsci/github-oauth-plugin/compare/05313d07327f...72075ba85218

0.27 released https://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/github-oauth/0.27/github-oauth-0.27.hpi