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:

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 git@github.com -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.

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

I have tried all this, but I am failing on the redirect step. Putting the localhost URL in curl (even --insecure gives me:
curl: (35) error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number\

I should note it fails in browsers for a similar reason.

I'm not running anything special just macOS 10.4.3 and Chrome 80.

I think opening a browser in windows 10 WSL environment doesn't work.

I encountered message like 'opening browser... ' two times.

First was when I tried to do gh pr create before setting up auth config.

After solving the problem with a help of this comment from above, I managed to set auth and am able to create pr.

But after creating pr, when I type in gh pr view, Opening https://github.com/ACCOUNT/REPO/pull/NO in your browser. but nothing really happens.

All of my actions were done under windows 10, built-in ubuntu(WSL) environment.

This may be better described as a subtask of #273, but allowing for helper style authentication or transport is probably going to be a requirement for full enterprise support.

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.

@DannyBen We hear you. I think alternative methods of authentication should definitely be available.

I wrote here the reason why Personal Access Tokens are not a possibility right now (at least, not if you want to use gh pr status), but once that is resolved, we could perhaps optionally ask for a PAT during the authentication phase so you can skip opening the browser.

Until then, the best workaround is authenticating on a machine that has a graphical browser and copying ~/.config/gh/config.yml to another machine.

I opened a PR to add details of the workaround to the error output so people don't have to read this issue #553.

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)

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 Awesome work!

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

@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

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?

Is this device-mode OAuth?