Additional or alternative authentication method

A browser is not always available for authentication.

I am working on a vagrant linux guest, which cannot open browser in the Windows host.

I would love to see a gh login command (or similar) to store credentials as appropriate by the system without opening a browser.

At the very least - if this is not changed, or until it is - I would love to see the URL it wants to open so I can open it manually.

Thanks for the feedback! Our current suggested work-around is to authenticate in a GUI environment and then copy gh's config file to the headless environment.

Looking at the code, it seems like it is supposed to print out the URL if opening the browser fails:

cli/auth/oauth.go

Line 58 in c03b0d1

    
           fmt.Fprintf(os.Stderr, "Please open the following URL manually:\n%s\n", startURL)

did this not happen for you? if so, we should capture that as a bug.

Looking at the code, it seems like it is supposed to print out the URL if opening the browser fails:

Did not happen for me. After pressing Enter to open the browser, it just hangs there waiting for my inevitable Ctrl+C.

oof, thanks for the clarification. I'll mark this as a bug, then.

Marking as a p3 since there is a workaround (manually copying gh's config). We should at a minimum ensure that the URL is being printed.

Making life easy for folks who already have an oauth token.

$HOME/.config/gh/config.yml

github.com:
  - user: USERNAME
    oauth_token: TOKEN

Could you print URL should be opened? To open it manually.

For me, the URL is shown and I can open it manually.
But then manually calling the callback results in a "the access token could not be read from HTTP response" error

$ ssh [email protected] -T                                                                              
Hi eplodn! You've successfully authenticated, but GitHub does not provide shell access.

I don't understand. If GitHub can successfully authenticate me by my private key (which is inherently more secure than passwords or tokens in files), why does it need any further authentication?

A more detailed step-by-step workaround for authenticating on headless environments without a browser:

when you get the "Please open the following URL manually:" prompt, open that URL on a different system that does have a browser (e.g. the one you're reading this on right now), and authorize in the UI
the UI will then attempt to redirect to a localhost URL, which will fail because the temporary gh auth server is running on your headless system, not the one with the browser
copy the URL that it failed to open from your browser address bar (it will look something like http://localhost:35399/callback?browser_session_id=...)
in another terminal session on your headless system, use cURL or another http client to send the request, e.g. curl 'http://localhost:35399/callback?browser_session_id=...' (single-quotes around the address to avoid shell interpreting special chars like &).
the original terminal where you were trying to run gh should now display "Authentication complete. Press Enter to continue..."
you now have valid credentials stored on the headless system in ~/.config/gh/config.yml and can run gh without re-authenticating. fun times

A more detailed step-by-step workaround for authenticating on headless environments

Thanks, this is appreciated, but.... this lack of simple authentication in the CLI is a great deterrent.
There are at least 10 one/two-liners for doing things the CLI does, without all this complication.

I have been working my GitHub account day and night though my own CLI scripts and tools, having nothing but a GITHUB_ACCESS_TOKEN in my environment. Headless should be a first class citizen for CLI, not an afterthought.

Although I see this "bug" progressing in the project columns - which is appreciated - I think the authentication method should be changed (or expanded), and not fixed to just show the URL for headless.

@vilmibm

What about something like the one used in the kubernetes cli? https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins. It makes it simple to use custom auth logic based on running shell commands. I don't like storing my credentials in plain text, so I am using pass for everything. Using such a method allows the user to use everything from webhooks, to pass, to plain env vars.

Here is a simple proof-of-concept (that I am currently using): https://github.com/cli/cli/compare/master...odinuge:exec-auth?expand=1

Any thoughts?

cc @vilmibm

The last paragraph would seem to me to fall into unreasonable asks, but I don't work for GitHub so I'll leave them to make that determination.

The first paragraph hints at needing a default timeout and possible detection of non-interactive session.

The middle paragraph needs secrets to work, which is what tokens and using an environment variable will solve for us. It's a one-time effort to retrieve / create the token, and then all your environments can use a secrets manager to ensure that the oauth token is protected.

Part of the problem is that much of this isn't protecting GitHub, it's protecting your team members and you.

Issue #1074 can help this.

In late July, GitHub is releasing support for the OAuth Device Authorization Flow in public beta. This allows any CLI client or developer tool to authenticate using a secondary system with a browser. We developed this because sometimes tools running virtual machines or containers can't accept callbacks on localhost ports even if they have an acceptable browser with javascript enabled. And it would be neat if someone wanted to build a GitHub app for a smart television!

The CLI team is evaluating the device flow as a potential solution for this issue, as part the broader authentication-related work in #957.

While it might be part of a solution for people who have an interactive session. I think after #1245 drops, it should be possible to then use that token for non-interactive sessions like those in CI. It could actually be really cool documentation for how to use the gh tool, to look at tests and see, oh look they supply a token via ENV (of course the token would be in secrets)

@tdumitrescu

Based on @tdumitrescu's instructions, I created the following bash script to streamline the whole process of authenticating on headless environments without a browser, all within a single terminal session.

#!/bin/bash

if [[ "$1" == "-f" ]]; then
  echo "Deleting existing credentials"
  rm -f $HOME/.config/gh/*
fi

if [[ -f $HOME/.config/gh/config.yml ]]; then
  echo "Already authenticated."
  exit 0
fi

set -euo pipefail

echo -e "Browse to the following URL and authenticate:\n"
echo -e "\n" \
  | gh repo view dummy/dummy 2>&1 >/dev/null \
  | grep 'https://' &

sleep 0.1s
echo -e "\nYou will then be redirected to an invalid URL, which you should cut and paste here:"
read -r URL
curl -s "$URL" \
  | grep -o "Successfully authenticated GitHub CLI" || echo "Authentication failed"

Note that you can pass a -f flag to the script to force recreating credentials file, otherwise if the file already exists, it will skip the whole process.

Enjoy! =)

@mathieusama

@mathieusama Awesome work!

But I hope we won't need this anymore with gh auth login.

@mathieusama

@mathieusama That's really nifty; thank you for sharing!

I also hope that this won't be necessary in gh v0.12.0+ (coming next week!)

Really looking forward to that v0.12.0 release! (especially for the gh repo create -y flag to prevent prompting user!)

The v0.12 release with improved authentication is out! https://github.com/cli/cli/releases/tag/v0.12.0

Try gh auth login on a headless host. When no graphical browser is detected, the flow prints out a URL that you can now open in a graphical browser on any other machine to complete the flow.

Additionally, you may pass in a token to skip browser authentication via gh auth login --with-token < mytoken-file.txt

Print details of authentication workaround to terminal

If you want to see the URL gh auth login uses, use BROWSER=nonexistent gh auth login, and it ultimately prints https://github.com/login/device

Is this device-mode OAuth?

feat: add debug logging for model converse requests (cli#297)

Navigation Menu

Repository navigation

Additional or alternative authentication method #297

24 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Additional or alternative authentication method #297

Description

Activity

vilmibm commented on Feb 3, 2020

DannyBen commented on Feb 3, 2020

vilmibm commented on Feb 3, 2020

vilmibm commented on Feb 3, 2020

genotrance commented on Feb 12, 2020

dapi commented on Feb 12, 2020

jonasrauber commented on Feb 12, 2020

eplodn commented on Feb 13, 2020

tdumitrescu commented on Feb 13, 2020

DannyBen commented on Feb 13, 2020

odinuge commented on Feb 14, 2020

24 remaining items

Lewiscowles1986 commented on Jun 1, 2020

felipecrs commented on Jun 2, 2020

gwestersf commented on Jun 17, 2020

Lewiscowles1986 commented on Jun 19, 2020

nanaluz commented on Jul 12, 2020

mathieusama commented on Sep 4, 2020

felipecrs commented on Sep 4, 2020

mislav commented on Sep 4, 2020

mathieusama commented on Sep 4, 2020

mislav commented on Sep 8, 2020

jamesbraza commented on Aug 2, 2024

Lewiscowles1986 commented on Aug 3, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions