GitのHTTPS認証に個人アクセストークンを求めるのは間違っているだろうか (Git Credential Manager のすゝめ)
TL;DR
- git-credential-manager (GCM)を使い、ブラウザ経由で 2 要素認証を突破しましょう。
- GCM では、アクセストークンを発行・管理する手間を省けるOAuth 2.0が可能になります。
- Windows の場合は、Git for Windowsインストール時に GCM も設定可能ですが、
他のプラットフォームでも自分でインストールすれば動作するようです。
アクセストークンの発行や管理を慎重に行ってますか?
最近、OSS への悪意あるコードの混入やアクセストークンの流出(Heroku)など、インシデントの頻度が上がっていますね。
GitHub に於いては、 2 要素認証(2FA)を義務化する動き[1]も活発です。
そんな中、ネットワーク要件等の都合で、SSH ではなく HTTPS が推奨されている場合もあるのではないでしょうか? 実際、GitHub はより簡単な HTTPS を推奨しています[2][3]。
ですが、この HTTPS 接続の場合、パスワード認証が廃止され始めています。
例えば GitHub や GitLab は、以前から 2 要素認証が有効だとパスワード認証不可で、
更に GitHub は 2021/08/13 以降[4]、Bitbucket は 2022/03/01 以降[5]で、廃止されました。
従って、現状でパスワード認証可能なのは2 要素認証が有効でない GitLab アカウントのみとなりました。
ですが、git clone等で以下の画面が出てきて初めて、以前使っていたパスワード認証が使えなくなった事に気づき、焦った方もいるのではないでしょうか?
$ git clone https://github.com/sample-user/private-repository.git
Cloning into 'private-repository'...
error: unable to read askpass response from 'C:/Program Files/Git/mingw64/bin/git-askpass.exe'
Username for 'https://github.com': sample-user
remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
fatal: Authentication failed for 'https://github.com/sample-user/private-repository.git/'
Bitbucket の場合
$ git clone https://sample-user@bitbucket.org/sample-user/private-repository.git
Cloning into 'private-repository'...
fatal: Invalid credentials
Password for 'https://sample-user@bitbucket.org':
remote: Bitbucket Cloud recently stopped supporting account passwords for Git authentication.
remote: See our community post for more details: https://atlassian.community/t5/x/x/ba-p/1948231
remote: App passwords are recommended for most use cases and can be created in your Personal settings:
remote: https://bitbucket.org/account/settings/app-passwords/
fatal: Authentication failed for 'https://bitbucket.org/sample-user/private-repository.git/'
そして慌てて「GitHub HTTPS clone できない」や「GitLab 2 要素認証 clone できない」等で検索し、検索結果に出て来た怪しい記事を鵜呑みにし、深く考えずにチェックを入れ、個人用のアクセストークンを発行していないでしょうか?
きちんと有効期限やスコープの 2 点を精査していますか?
-
スコープ
公式ドキュメントでは特に言及されていませんが、
後述の GCM では'write_repository'と'read_repository'のみなので、
全てのスコープは与えるのは止めた方が良いでしょう。
API 用途ならまだしも、git pullやgit pushには不要だと思います。 -
有効期限
入力が面倒と言って、無期限で発行してしまっていませんか?とは言え、後述の GCM では期限を設定できないようです……
OAuth2 の仕様だと少なくとも rotate はするようですが、GitHub に至ってはリフレッシュできているのかすら確認できていません。
アクセストークンは、流出に関して話題になっており、扱いに気を付ける必要が増しています。
最近だと、Heroku で OAuth アクセストークンが流出した事故[8]もあります。
しかしだからと言って、毎回発行するのも大変ですし、平文で管理しては意味がありません。
では、GitHub 公式の見解はどうでしょうか?
エラーメッセージでも表示される GitHub のドキュメントでは、
個人のアクセストークン(PAT: Personal Access Token)を発行する事が推奨されています[4:1]。
従って、少なくともアクセストークンの使用は避けられなさそうです。
では、どのようにアクセストークンを発行・管理するのが望ましいでしょうか?
アクセストークンの管理方法
主に以下があります。
| helper 名 | 関連リポジトリ | 保存先 |
|---|---|---|
store |
Git for Windows / Git(built-in) | テキストファイル |
cache |
Git for Windows / Git(built-in) | ソケットファイル |
wincred/osxkeychain
|
Git for Windows / Git(built-in) | 認証情報マネージャー / キーチェーン |
manager |
Git Credential Manager for Windows | 認証情報マネージャー |
manager-coremanager
|
Git Credential Manager (GCM) | 認証情報マネージャー 等 |
🤔helper 名とは?
以下の設定で使う事になる名前です。
git config --global credential.helper ${helper 名}
🤔 資格情報マネージャー(Credential Manager) とは?
Windows の場合、以下の様なものがあります。
ここに各種の認証情報を保管できるようですが、暗号化の有無などは把握できておりません。
資格情報マネージャー[11]
因みに macOS に於ける似たものとして "キーチェーンアクセス" というものがあるらしいです。
まず、Git をインストールすると、built-in で入っているのが、store,cacheで、
Windows / Mac だとwincred/osxkeychainも利用可能です[12]。
更に、manager-coremanagerというものも最近推奨され始めています。
では上から順に見てみましょう。
-
store
テキストファイルに平文で保存します。
デフォルトの保存先は、~/.git-credentialsです。 -
cachecache ヘルパーは独自形式でメモリーに情報を保持します
（他のプロセスはこの情報にアクセスできません）[12:1]。このように紹介されており、前述の
storeより安全らしいです。 -
wincred/osxkeychain
前述の 2 つと同じで、Git インストール時にデフォルトで有効です。
対話形式で入力したアクセストークンが、システムの認証情報マネージャーへ保存され、
以降はそれを永続的に使います。コマンドで削除する場合
Windows であれば「認証情報マネージャー」の情報を直接操作可能ですが、
wincredの helper を使えば、コマンドで済ます事も可能です。認証情報マネージャーから認証情報を削除するコマンドgit credential-cache erase <<EOS protocol=https host=${対象のGitホスティングサービスのホスト名} EOS -
manager古い記事だとこれの事しか書いてないですが、
既にmanager-coremanagerに統合され、リポジトリはアーカイブ済みです。
Mac や Linux 用のものも同様です。 -
magaer-core
後述する最新の GitHub ドキュメントで推奨されています。
正式名は "Git Credential Manager (GCM)" です。初めてアクセスする Git ホスティングサービス(GitHub 等)に対して、
git pull/git push等を行うと、
以下の様な UI が表示され、これに従ってブラウザ経由で認証できます。
GCM によって表示される認証用の UI[13:1]尚、一度 GCM によるアクセスを認可したサービスでは、
今後アクセストークンを要求される事はありません。
アクセストークン管理の選択肢を簡単に確認してきましたが。いかがでしたでしょうか?
アクセストークン発行も容易になる点で、OAuth アプリケーションの GCM が有力です。
ではここで、最近推奨され始めているGCMに焦点を移してみましょう。
Git Credential Manager (GCM)
2 年前にもアナウンス[14]されており、使用例の記事[15] [16]もありましたが、
2022/04/07 に GitHub から再び公式アナウンスされ、広く推奨され始めたばかりです。
この発表に於けるポイントとしては、以下です。
- 以前までの GCM for Windows and GCM for Mac and Linux を統合
- Avalonia UIにより、.NET でも macOS や Linux に対応
- WSL の場合は、実行パスを Windows 側の物を設定すれば、設定の共有可能
- 全てのプラットフォームに提供する思想に基づくので、
microsoft や github ではなく GCM のプロジェクトとして独立 - Web UI の指示に従って認可すると、
裏でアクセストークンが発行され、更にローカルへ良い感じで保存してくれる - GitLab も対応
- オンプレミス環境の場合は別途設定が必要[17]だが、改善予定あり
- 認証情報に関して、様々な保存方法を設定可能
- デフォルトの認証情報マネージャー、GPG 暗号化ファイル、キャッシュ等
🤔 仕組みは?
では、使い方について確認してみましょう。
主に以下です。
GCM のインストール
基本は公式リポジトリ[18]の指示に従います。
以下には、あくまで 2022/07/01 現在の方法を一部紹介します。
Windows
Git for Windowsをインストールする場合は、以下の画像の様にデフォルトで設定できます。
Git for Windows インストール時にcredential helperを選ぶ画面
尚、別でインストールしたい場合は、
公式ページからダウンロードしてインストールしてください。
その他
詳細に、アンインストール方法も書いてあるので、
公式リポジトリ[18:1]を参照してください。
Git ホスティングサービスの新規登録
あとはgit pull/git pushを実行する度に以下の UI が表示されて使えるようになります。
これに従って、Web ブラウザでログインして認可すれば、
以降は GCM がアクセストークンの更新・管理を行ってくれます。
GCM によって表示される認証用の UI[13:2]
🤔OAuth とは?
ここで説明するには難しいので、調べてください。
因みに、OAuth と OAuth2.0、更に OpenID Connect というのがあるらしいです。
一般的に、利用者が自ら無効化しない限りリフレッシュトークンは有効らしいです。
Google の場合はログインしてないと切れるらしいですね。
(中級者向け) WSL から Windows と資格情報の共有
WSL 内に直接 GCM をインストールすると、Windows の資格情報にアクセスできません。
従って資格情報を共有したい場合は、
WSL 内の設定として Windows 側の GCM の実行パスを設定しましょう。[21]
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager-core.exe"
# If you intend to use Azure DevOps you must also set the following Git configuration inside of your WSL installation.
git config --global credential.https://dev.azure.com.useHttpPath true
(上級者向け) 様々な管理方法のオプション
GCM makes use of the Windows Credential Manager on Windows and the login keychain on macOS.
In addition to these existing mechanisms, we also support several alternatives across supported platforms, giving you the choice of how and where you wish to store your generated credentials (such as GPG-encrypted credential files). [13:3]
公式アナウンスで紹介されている通り、
前項まで使う事はできますが、更に上級者向けの設定を紹介します。
アクセストークンの管理方法で触れたように様々な helper が存在しますが、
manager-coremanagerはこれらを組み合わせる事も可能です。
一覧は以下ですが、詳細は公式のドキュメント[22]先から確認してください。
設定名(credentialStore) |
名称 | Windows | Mac | Linux |
|---|---|---|---|---|
wincredman |
Windows Credential Manager | ✅ | ||
dpapi |
DPAPI protected files | ✅ | ||
keychain |
macOS Keychain | ✅ | ||
secretservice |
freedesktop.org Secret Service API | ✅ | ||
gpg |
GPG/pass compatible files |
✅ | ✅ | |
cache |
Git's built-in credential cache | ✅ | ✅ | |
plaintext |
Plaintext files | ✅ | ✅ | ✅ |
以下の形式で設定しますが、最新の方法は公式ドキュメントから確認してください。
export GCM_CREDENTIAL_STORE=xxx
# or
git config --global credential.credentialStore xxx
(上級者向け) キャッシュでアクセストークンを PC に残さない
GCM can now also use Git’s git-credential-cache helper that is commonly built and available in many Git distributions. This is a great option for cloud shells or ephemeral environments when you don’t want to persist credentials permanently to disk but still want to avoid a prompt for every git fetch or git push. [13:4]
GCM で発行・管理しても、アクセストークンを認証情報マネージャーで保管してるだけで、
実質 1 要素認証のままじゃない? と思うかもしれません。
そこでキャッシュをお勧めします。
これなら無効化しなくても、発行元ぐらいしかトークンを知らないので漏れる心配はありません。
また、キャッシュが切れる度に GCM を介してブラウザ経由の 2 要素認証が求められるようになります。
因みにこれは、内蔵の Git のcredential-cacheを使用して実現しています。
願望
本当は、
「GCM 導入によって 2 要素認証を経由してアクセスできるので、セキュリティ的に改善する」
と言おうと思ってましたが、無理でした。
OAuth2.0 のリフレッシュトークンでアクセストークンを入れ替えていてもタイムアウトしないので、一度認証するとそれ以降は永久に認証不要なんですよね。
従って、毎回ログインしてから短い有効期限のアクセストークンを発行して使えば、正直 GCM よりもセキュリティ的には良さそうでした。
但し、発行や管理の手間を省く点では GCM が便利そうです。
どうしてもアクセストークンを使い回したくない場合は、
定期的に自分で GCM のアクセストークンを無効化して再発行させるしかなさそうです。
🤔Q&A
より詳細に知りたい方向けに、想定されるものを簡単に纏めました。
再掲事項も含みます。
🤔Q-01. 個人アクセストークン(PAT)と GCM 用の OAuth アクセストークンって本当に違うもの?
GitLab に関しては恐らくそうです。
但し、GitHub では、GCM が OAuth Application と言い張っている一方で、
次項で述べる様に、仕様がそうなっていないようなので、分からないです。
🤔Q-02. GCM のアクセストークンは OAuth として発行されている?
保存された認証情報を見る限り、GitLab や Bitbucket の場合は恐らくそうですが、GitHub では怪しかったです。
まず GitLab は、実際に保存されたアクセストークンを確認すると以下の様に 2 種類保存されています。
認証情報マネージャーに保存された、GitLab の認証情報
また、Bitbucket もきちんと別で保持しているようでしたので、恐らく GitLab と同じ仕様と思われます。
認証情報マネージャーに保存された、Bitbucket の認証情報
一方で、GitHub ではリフレッシュトークンと思しきものは確認されませんでした。
違反[24]してるんですかね?
認証情報マネージャーに保存された、GitHub の認証情報
🤔Q-03. GCM よりも、2 要素認証でログインしてから必ず有効期限付きで PAT 発行した方が安全では?
はい、恐らくその通りです。
OAuth2 の場合は、頻繁にアクセストークンは変わる筈なので、
アクセストークン漏洩は恐らく軽症で済みますが、リフレッシュトークン漏洩は想定されていないと思います。
また、PAT は有効期限を詳細に決められるので、その点で PAT の方が優れていると思われます。
勿論、アクセストークン自体は、
Windows なら認証情報マネージャー(wincred) (mac なら、osxkeychain?)
に保存しておけば、安心でしょう。
🤔Q-04. PC に保存したアクセストークンは覗ける?
Windows の場合、資格情報マネージャーから表示できるらしいですが、自分の環境では無理でした。
一方で、Git コマンドによるアクセス時に、アクセストークンは復号?されるようでした。
例えば、以下の入力例のように入力すると、出力例のように続きが出力され、アクセストークンがパスワードとして平文で丸裸になります。
パケットキャプチャまではできていないので、通信時に平文で送信しているかまでは把握できていないですが……
$ git credential fill <<EOS
protocol=https
host=github.com
EOS
$ git credential fill <<EOS
protocol=https
host=github.com
EOS
protocol=https
host=github.com
username=sample-user
password=${sample-userのアクセストークン}
🤔Q-05. 初回アクセス時は必ず 2 要素認証でログインしたいんだが?
案としては、以下があります。
- 自分で GCM の認証を無効化(Revoke)
- キャッシュにより、PC に残さない
但し、1 は手間ですし、
2 に関しては Git for Windows が対応していないので Windows のみ無理です。
🤔Q-06. "credential-cacheon Windows"は可能か?
Full disclosure: Technically, since Git v2.34.0,
git-credential-cache.execan be built and run on Windows. Unix Sockets support has been introduce into Windows. The problem is that you need Windows 10 build 17061 or later, and Git for Windows still supports even Vista (although it has been announced that Git for Windows will drop supporting Vista really soon now). [25]
Git for Windows 自体は、v2.34.0 から Unix Sockets に対応しましたが、
後方互換の為に、NO_UNIX_SOCKETS = YesPleaseとして無効化されています。
Vista のサポートは 2023 年より前に打ち切るとは伺えましたが、古いビルドバージョンのサポートは残っているので、公式に対応してくれる見通しは未だ無いです。
(ドキュメントから Windows は消して、エラーメッセージも出力する事になりました[23:1]😩)
従って、どうしても使いたい場合は、Git や GCM をビルドして使いましょう。
🤔Q-07. Linux 環境で GCM の UI が表示されないが?
「Avalonia により.NET でも Linux 対応」とあるにも拘わらず、UI が出て来なくて焦る場合もあると思います。
これは、LANGをen_US.UTF-8以外に設定していると発生する、Avalonia 由来の仕様です。
🤔Q-08. GCM はどのように OAuth2 アプリケーションとして UI を表示して動作している?
以下の様に、ホスト名で判別しています。
因みに、OAuthClientIdやOAuthClientSecretもソースコードに埋め込まれており、
他の設定値もここに記載されています。
🤔Q-09. オンプレミス環境の GitLab 対応はどうする?
基本的には、公式の GitLab に関する補足ドキュメント[17:1]に従います。
一部抜粋して和訳したものを以下に記します。
別インスタンスでの使い方
別インスタンスで使う為に、例えば
https://gitlab.example.comでは以下の設定が必要です。
- Create an OAuth application. これは、ユーザーやグループ、インスタンスのレベルで行えます。
まず、名前やリダイレクト先をhttp://127.0.0.1/で指定してください。
そして、'Confidential' オプションは選択せず、'Expire access tokens' オプションは選択してください。
最後に、'write_repository' や 'read_repository' のスコープを設定してください。- application ID をコピーして、
git config --global credential.https://gitlab.example.com.GitLabDevClientId <APPLICATION_ID>で設定してください。- application secret をコピーして、
git config --global credential.https://gitlab.example.com.GitLabDevClientSecret <APPLICATION_SECRET>で設定してください。 1.git config --global credential.https://gitlab.example.com.gitLabAuthModes browserのように'browser'を含めて authentication modes を設定してください。- 念の為に、
git config --global credential.https://gitlab.example.com.provider gitlabを設定してください。これは、ドメインを GitLab インスタンスとして認識させるのに必要かもしれません。git config --global --get-urlmatch credential https://gitlab.example.comで、設定が期待通りかどうか確認してください。
ターミナル上で行う操作のみを纏めると以下の通りです。
git config --global credential.https://gitlab.example.com.GitLabDevClientId ${登録したGCMのAPPLICATION_ID}
git config --global credential.https://gitlab.example.com.GitLabDevClientSecret ${登録したGCMのAPPLICATION_SECRET}
git config --global credential.https://gitlab.example.com.provider gitlab
git config --global --get-urlmatch credential https://gitlab.example.com
🤔Q-10. HTTPS 非対応のオンプレミス環境 GitLab でも使える?
無理です。エラーメッセージがそう言ってました。
諦めて自己署名証明書を用意しましょう。
$ GIT_TRACE=1 git clone http://gitlab.example.com/sample-user/private-repository.git
22:28:30.042786 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
22:28:30.043790 git.c:459 trace: built-in: git clone http://gitlab.example.com/sample-user/private-repository.git
Cloning into 'private-repository'...
22:28:30.053785 run-command.c:654 trace: run_command: git remote-http origin http://gitlab.example.com/sample-user/private-repository.git
22:28:30.060786 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
22:28:30.061786 git.c:748 trace: exec: git-remote-http origin http://gitlab.example.com/sample-user/private-repository.git
22:28:30.061786 run-command.c:654 trace: run_command: git-remote-http origin http://gitlab.example.com/sample-user/private-repository.git
22:28:30.069786 exec-cmd.c:237 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
22:28:30.253464 run-command.c:654 trace: run_command: 'C:/Program\ Files/Git/mingw64/bin/git-credential-manager-core.exe get'
fatal: Unencrypted HTTP is not supported for GitLab. Ensure the repository remote URL is using HTTPS.
22:28:30.515517 run-command.c:654 trace: run_command: 'C:/Program Files/Git/mingw64/bin/git-askpass.exe' 'Username for '\''http://gitlab.example.com'\'': '
error: unable to read askpass response from 'C:/Program Files/Git/mingw64/bin/git-askpass.exe'
22:28:39.575230 run-command.c:654 trace: run_command: bash -c 'cat >/dev/tty && read -r line </dev/tty && echo "$line"'
Username for 'http://gitlab.example.com':
🤔Q-11. pass コマンドが連携できるなら、1Password を保存先として連携できる?
補足
このすば三期おめでとうございます！🎉
ところで、ダンまちとこのすばとリゼロ、自分は混同しがちなんですが皆さんはいかがでしょう?
共通項として何があるでしょうか? (意外と少ない?🤔)
- アホな水色の女神
- 三下ァ!(CV: 岡本信彦)
- アニメが 2016 年頃から(ダンまちだけ微妙に早いですね)
ソシャゲとかでも互いにコラボするので、自分は余計混乱するんですよね。
-
https://docs.github.com/en/get-started/quickstart/set-up-git#connecting-over-https-recommended ↩︎
-
git - Why does GitHub recommend HTTPS over SSH? - Stack Overflow ↩︎
-
Token authentication requirements for Git operations | The GitHub Blog ↩︎ ↩︎
-
Announcement: Bitbucket Cloud account password usa... - Atlassian Community ↩︎
-
https://docs.gitlab.com/ee/user/admin_area/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens ↩︎
-
https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git#git-credential-manager ↩︎
-
Git Credential Manager: authentication for everyone | The GitHub Blog ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
-
Git Credential Manager Core: Building a universal authentication experience | The GitHub Blog ↩︎
-
git で 2 要素認証を突破するための Git Credential Manager Core の紹介 - Qiita ↩︎
-
https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/gitlab.md ↩︎ ↩︎
-
https://github.com/GitCredentialManager/git-credential-manager ↩︎ ↩︎
-
https://github.com/doorkeeper-gem/doorkeeper/wiki/Customizing-Token-Expiration#refresh-token ↩︎
-
https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/wsl.md ↩︎
-
https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md ↩︎
-
https://github.com/GitCredentialManager/git-credential-manager/pull/729 ↩︎ ↩︎
-
https://github.com/GitCredentialManager/git-credential-manager/issues/723#issuecomment-1146817218 ↩︎
Discussion