Repository navigation
Yubikey and/or other hardware authenticators #2176
Description
Activity
I did do a quick search for Yubikey and didn't see anything referencing it, so if I missed that this is a dupe, please accept my sincere apologies on the matter.
Hi, thank you for the recommendation!
When the CLI tool first authenticates to GitHub, we open the web browser for you where you go through the typical GitHub authentication flow. If you've set up a Yubikey with your GitHub account, you will be prompted to touch the key during that flow.
After that, an OAuth token is generated for CLI and saved in your
~/.config/gh/hosts.ymlfile. From that point onward, no explicit authentication is needed since cached credentials are used. Of course, storing this token in plain text isn't ideal, so we're aiming to support storing it in your system's Keychain in the future.Where in this flow did you imagine a Yubikey step to be added for extra security? Once per first authentication (GitHub web already supports this), or every time someone uses CLI?
I was thinking per-use in replacement for the cached credentials, at least as an option for those who have such an authenticator on their account.
Reacted by Mislav Marohnić, Antoine Bertin, Mattias Hermansson, André Mello, Charles Tison, Oliver Mannion, Ralph Meijer, Matthias Pigulla, Odoo - Paolo Gatti (pgi), Iain Smart and 2 moreIf I understand correctly that would mean you could have short lived credentials, and also the token returned by
gh auth tokenwould only be valid for hours?After that, you'd need to have the security key plugged in and/or additionally touch it.
So, nothing that could be exfiltrated from a developer machine that would be of use for more than a rather short period.
In the wake of the recent Shai-Hulud events this sounds like a promising solution.
Reacted by Christian M. Pedersen and Liam GalvinI have been looking into this as well because of the recent Axios and LiteLLM attacks. I was surprised to find how easy it is to exfiltrate the full OAuth token from Keychain on my Mac using the shell command
security find-generic-password -s "gh:github.com" -w. I was hoping that there'd be a way to use my YubiKey to protect against this, but it seems like the gh cli currently has no way to protect against these types of exfiltration attacks?@mislav I am not a security/encryption expert, but poking around with Claude Code and the gh CLI source I wonder if the gh CLI could add FIDO2 challenge-response authentication:
- gh auth login --fido2 generates a FIDO2 credential on the YubiKey — the private key never leaves the hardware
- GitHub stores the corresponding public key
- On each API call (or session), GitHub sends a challenge, gh signs it using the YubiKey
- No token is stored locally — there is nothing to exfiltrate
Even if an attacker has full access to the filesystem, they cannot authenticate without the physical YubiKey. Same security model as SSH ed25519-sk keys, extended to the GitHub API. This could be combined with SSH ControlMaster-style session caching (one YubiKey touch per N hours) so you don't have to touch the YubiKey for every API request.
Reacted by Antoine Bertin, Eric Jalbert, Matthias Pigulla, Glenn Ericksen and Peeter PiksarvGiven that the
ghCLI may be invoked multiple times e. g. from shell scripts, there is no such thing as a persistent "session", and having to touch the key for every single invocation or API call seems impractical.However, it would be a huge improvement already if the CLI could create and store in the filesystem a rather short-lived token, which is valid for hours only. Then, when it detectes that such a token has expired, it could be replaced by touching the Yubikey.
Suggestion: This might be a little difficult to do effectively cross-platform, but you should support the use of Yubikeys (and/or other types of hardware authenticators; even Windows Hello, for that matter) for authenticating to Github when using the CLI tool. I can't think of much that I consider of higher security importance than development accounts, and the slight nuisance of having to touch the key for security is a worthwhile trade-off to make sure that the token that CLI uses isn't stolen and misused.