😎

GCM(gitのhttpsの認証の仕組み)の話。きっかけはWSL2は「Azure DevOps」にはGitBashのGCM間借りは無理で調査

に公開
Git
Azure
WSL 2
tech

はじめに

https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0#patトークンの入力なしで、git-push可能にするため、windows側の認証機能を間借りする方法

に記載した「Git for Windows」のgit-credential-wincred.exeを間借りする方法で、
WSL2のgitもPATトークンの入力なしで使える話は、

リモートのリポジトリが「gitHub」だったときは、これでOK

リモートのリポジトリが「Azure DevOps」の場合では、これではうまくいかなかった

2026/01/06追記
★★★★★★★★★
下記のGitBucketの環境でも、
Git for WindowsのGCMをWSL2のUbuntuのgitで間借りする方法では、うまくいくことが確認できました
★★★★★★★★★
とあるGitBucketのサイトのログインは、idとパスワードであった
WSL2のubuntuのgitで、上記の、
GitBucketのリポジトリをclone時は、httpsで(httpではない！！)
git clone https://xxxxxxxxxxxxxxxxxxxxxxx.zzzz.git
をしたときに、idとパスワードが聞かれて
GitBucketのサイトのログイン時の、idとパスワードと同じ
idとパスワード ( アクセストークンではない！！ )
を入力すれば、git cloneが成功するのであるが、
毎回、聞かれる状況であった
それを、Git for WindowsのGCMを間借りしてWSL2のubuntuのgitに指定すれば、
その後の、一回目のgit clone時は、idとパスワードを聞かれたが、
2回目以降での、git clone時は、聞かれなくなった

ということを確認しました。
★★★★★★★★★
ただし、AzureDevOpsの場合では、
Git for WindowsのGCMをWSL2のUbuntuのgitで間借りする方法では無理なので
当記事のやり方でする必要があります。
★★★★★★★★★

「Azure DevOps」は、Linux純正のgit-credential-managerを指定すると解決できた。

なぜかは不明です。Git for Windowsのそれを間借りする方法では、「Azure DevOps」ではうまくいかず、Linux純正のそれだと、うまくいく。　【　理由は知らん　】

Linux純正のgit-credential-managerは、aptパッケージマネージャでは、インストールできない

gitHubのサイトからおとしてきて、自分で配置する必要がある。

2025/06/24現在
https://github.com/git-ecosystem/git-credential-manager/releases

のサイトより

上の図のとおり、
gcm-linux_amd64.2.6.1.tar.gz
を右クリして、リンクのアドレスをコピーすると

https://github.com/git-ecosystem/git-credential-manager/releases/download/v2.6.1/gcm-linux_amd64.2.6.1.tar.gz

のURLの文字列が得られる

これより先は、業務用に貸与されたPCで作業した内容なので、
作業時のコンソールログは、貼り付けられない
（　この記事は、個人PCで記載　）

見ながら、個人PCで記事書いてる。
一般的なノウハウの話なので問題ないでしょう。 ( 秘匿性のある機密情報ではないため )

cd /tmp
で、/tmpに移動し

先ほど、コピーしたURLを利用して

wget https://github.com/git-ecosystem/git-credential-manager/releases/download/v2.6.1/gcm-linux_amd64.2.6.1.tar.gz

をする
gcm-linux_amd64.2.6.1.tar.gz
がダウンロードされるため、解凍する。

tar -xvzf gcm-linux_amd64.2.6.1.tar.gz

するとログに、
NOTICE
git-credential-manager
libSkiaSharp.so
libHarfBuzzSharp.so
の4ファイルを解凍したと表示され、/tmp上にこれらのファイルが展開される

NOTICEはテキストファイルで、
cat NOTICE
で注意事項など表示される。（英語)

git-credential-manager
に実行権限を与える
libSkiaSharp.so
libHarfBuzzSharp.so
は、そのままでよい

chmod +x ./git-credential-manager

その後、
git-credential-manager
libSkiaSharp.so
libHarfBuzzSharp.so
を
/usr/local/bin
に移動する。

sudo mv ./git-credential-manager /usr/local/bin/git-credential-manager
sudo mv ./libSkiaSharp.so /usr/local/bin/libSkiaSharp.so
sudo mv ./libHarfBuzzSharp.so /usr/local/bin/libHarfBuzzSharp.so

そしたら、
WSL2のgitコマンドが利用するcredential.helper
を上記のLinux純正のgit-credential-manager
にする。

git config --global credential.helper /usr/local/bin/git-credential-manager

git config --global credential.helper
とだけ、打ち込んだときに、
/usr/local/bin/git-credential-manager

が返ってくれば、設定ができている

ls -l /usr/local/bin/git-credential-manager
を打ち込んで、gitコマンドを打ち込む作業ユーザで実行権限があることを確認しておこう
このあたりができてないと、うまくいかないと思いますよ

Azure DevOpsの場合は、下記をやる必要がある。【　理由は知らん　】

git config --global credential.https://dev.azure.com.useHttpPath true

git config --global credential.https://dev.azure.com.useHttpPath
とだけ打ち込んで
true
が返ってきたら、設定ができている

Azure DevOpsの場合は、下記をやる必要がある。(その２)【　理由は知らん　】

git config --global credential.credentialStore cache

git config --global credential.credentialStore
とだけ打ち込んで
cache
が返ってきたら、設定ができている

ここまで、設定したらPATトークンなしでも、
git cloneに成功した。
途中でブラウザ起動し、英語で、「このままブラウザ閉じたら続行できる」意味内容の
メッセージが出てくる
gitのコマンドはターミナル上で停止しているが、
そのブラウザのタブを閉じたら、
gitコマンド側が続きを継続するような流れになったりする。

おそらく、
git config --global credential.credentialStore cache
は、そこらへんがうまく動くようにするための設定ではないかと思う。が、詳細は知らん

なお、もし、
WSL2のCLIからのブラウザ起動がうまくできない問題があるため
この一旦、ブラウザを起動して閉じたら、gitのコマンドが継続する流れの動きが
うまく動かないときは。（結果として、gitコマンドが動作しない、現象があるときは）

https://zenn.dev/tazzae999jp/articles/0934afe501db0c#「wslu-%3A-wsl用のユーティリティコレクション」が無いとcliからwebブラウザの起動ができない

のやり方で
「wslu : WSL用のユーティリティコレクション」
をインストールすることで解決できるのではないかと思う。

以上

補足: 各プラットフォームで「そのOSネイティブの GCM」を入れておけば Azure DevOps / GitHub など全部 HTTPS + ブラウザ連携でいける話

1. ざっくり結論

  • Git Credential Manager（以下 GCM）は 1つの共通プロジェクト で、
    • Windows 向け（Git for Windows に同梱されるもの / 単体インストーラ）
    • macOS 向け（.pkg / Homebrew cask）
    • Linux 向け（.deb / .rpm / tarball）
      という ビルド違い が配布されているだけ。
  • それぞれの OS で その OS 向けに用意された GCM を素直に入れておけば、公式にサポートされている下記ホスティングは、すべて HTTPS + ブラウザ認証だけで扱える（PAT を手で発行・保存する必要がない）：
    • Azure DevOps / Azure DevOps Server
    • GitHub
    • Bitbucket
    • GitLab

2. 自分の環境で実際に起きたことの整理

2-1. WSL2（Ubuntu）側

  • 最初の構成
    • WSL2 の Git から、credential.helper に Windows 側 Git for Windows に付属しているクレデンシャルヘルパー をパス指定して呼び出す、という「変則構成」だった。
    • この状態だと、
      • GitHub への HTTPS アクセス: 成功（ブラウザ連携で認証）
      • Azure DevOps への HTTPS アクセス: 認証エラーで失敗
        という挙動になっていた（この記事で書いている通りの現象）。
  • 記事で行った対処
    • Microsoft が配布している Linux 向けの git-credential-manager を /tmp に展開し、実行権限を付けたうえで /usr/local/bin/git-credential-manager などに配置。
    • git config --global credential.helper /usr/local/bin/git-credential-manager のように WSL2 内の Linux ネイティブ GCM を helper に指定。
    • その結果、
      • GitHub
      • Azure DevOps
        の両方を、PAT を手で発行せずに HTTPS + ブラウザ認証で使える ところまで確認済み。
  • ここから言えること
    • 「WSL2 から Windows 側 GCM を直接たたく」構成は、
      • 公式ドキュメント上、推奨例としても出てこない
      • Azure DevOps でだけ不具合が出た
        ので、正式サポート外の非推奨構成 と見なしておくのが安全。
    • WSL2 では、Linux 向けに配布されている GCM（もしくは記事で紹介している Linux 純正ヘルパー）を直接使う、という素直な構成にしておくのが確実。

2-2. macOS（M1 Mac）側

  • 実際に行った手順（macOS / Apple Silicon）
    1. もともと Xcode Command Line Tools 経由で credential.helper=osxkeychain が有効になっていた。
      git config --show-origin credential.helper
# => file:/Library/Developer/CommandLineTools/usr/share/git-core/gitconfig osxkeychain
    2. Homebrew で macOS 用 GCM をインストール：
      brew install --cask git-credential-manager
    3. インストール後、GCM 側の post-install によって自動で credential.helper が差し替えられた：
      git credential-manager --version
# => 2.6.1 ... （バージョン表示）

git config --show-origin credential.helper
# => file:/Users/xxx/.gitconfig /usr/local/share/gcm-core/git-credential-manager
    4. その状態で、
      git clone https://github.com/xxx/xxxx.git https-clone-test-dir
      を実行すると、
      • ブラウザが立ち上がって GitHub ログイン
      • 認証完了後、クローン成功
      • 以後は PAT を手動発行していないのに HTTPS clone/pull/push がそのまま通る
        ことを確認済み。
  • ポイント
    • macOS では、Homebrew から入れた GCM が自動的に Git を再設定してくれるので、追加の git config は不要（後述の GitHub Docs の記述と一致）。
    • 認証フローは WSL2 の Linux GCM と同じく 「ブラウザで OAuth + 2FA → GCM がトークンを安全に保存」 という構造で、ユーザは PAT を手で意識しなくてよい。

2-3. Windows（Git Bash）側

  • Git Bash = Git for Windows なので、
    • 近年の Git for Windows（2.29 以降）には、クロスプラットフォーム版 GCM（v2 系）が同梱されている。
    • インストーラで GCM オプションを有効にしておけば、credential.helper は自動的に GCM を指すように設定される。
  • その結果、Git Bash では 「Git for Windows に同梱されている GCM」 が使われる構成になり、
    • Azure DevOps / Azure DevOps Server
    • GitHub
    • Bitbucket
    • GitLab
      など、GCM が公式にサポートしているサービスは、すべて HTTPS ＋ ブラウザ認証で扱える。

3. 「同じプロジェクトか？」という整理

  • 質問1:

    brew コマンドで Mac にインストールした GCM は、
    WSL2 の記事で入れている「Linux 純正のクレデンシャルヘルパー」と元は同じなのか？

    → プロジェクトとしては同じ「Git Credential Manager」ファミリーだが、配布形態・ビルドは OS ごとに別、という整理がいちばん正確。

    • Mac: Homebrew cask / .pkg で配布される macOS ビルドの GCM
    • Linux: tarball / .deb / .rpm で配布される Linux ビルドの GCM
    • Windows: Git for Windows に同梱、あるいは .exe で配布される Windows ビルドの GCM
      という違いはあるが、裏側のソースコードベースは共通（Git Credential Manager プロジェクト） になっている。

  • 質問2:

    今回 Mac で GCM を入れたことで、WSL2 の Ubuntu も「同じ系統の GCM を使う」話になったのか？

    → 現時点での整理は次の通り：

    • WSL2
      • 記事で入れたのは「Linux 用の GCM」（あるいはその前身の Linux 用クレデンシャルヘルパー）で、今のクロスプラットフォーム GCM と同系統のもの。
      • 公式 GitHub Docs も現在は「Linux でも GCM をインストールして使う」ことを推奨している（後述）。
    • macOS
      • Homebrew から入れた GCM は、まさに同じ Git Credential Manager プロジェクトの macOS ビルド。
    • Windows（Git Bash）
      • Git for Windows に同梱されているのが、同じ Git Credential Manager プロジェクトの Windows ビルド。
    • つまり、3つとも「Git Credential Manager」という同一プロジェクトの別ビルドでそろっている、と考えてよい。

  • 質問3（Git Bash の GCM は何に対応しているか？）
    → 最新の GCM の公式説明にある通り、Windows 版を含む GCM 全体として 下記のホスティングサービスをサポートしている：

    GCM supports (in alphabetical order) Azure DevOps, Azure DevOps Server (formerly Team Foundation Server), Bitbucket, GitHub, and GitLab.
    （出典: SourceForge の Git Credential Manager プロジェクト説明）

    したがって、Git Bash（＝ Git for Windows + GCM）でも、これらはすべてサポート対象と考えてよい。

4. 公式ドキュメントの URL と直接記述の抜粋

4-1. Git Credential Manager 本体（クロスプラットフォーム GCM の説明）

  • URL（プロジェクト概要 / SourceForge の説明）

  • 抜粋（クロスプラットフォームであることと対応ホスト）

    Git Credential Manager (GCM) is a secure Git credential helper built on .NET that runs on Windows, macOS, and Linux.

    GCM supports (in alphabetical order) Azure DevOps, Azure DevOps Server (formerly Team Foundation Server), Bitbucket, GitHub, and GitLab.

    GCM replaces both the .NET Framework-based Git Credential Manager for Windows and the Java-based Git Credential Manager for Mac and Linux.

  • URL（旧 GCM for Windows 側の告知）

  • 抜粋（旧「Git Credential Manager for Windows」の非推奨告知）

    Git Credential Manager for Windows is no longer being maintained. The cross-platform Git Credential Manager Core (GCM Core) is the official replacement.

4-2. GitHub Docs: Git に GitHub の認証情報をキャッシュする（GCM 全般）

  • URL（日本語版）

  • 抜粋（GCM の役割と 2FA / PAT 管理）

    Git Credential Manager (GCM) は、資格情報を安全に保存し、HTTPS 経由で GitHub に接続するもう 1 つの方法です。

    GCM を使うと、2FA (2 要素認証) を含む認証をユーザーの代わりに GCM が管理するため、手動で personal access token を作成して格納する必要はありません。

  • 抜粋（macOS での Homebrew + 自動設定）

    Homebrew を使用して GCM をインストールします。

    brew install --cask git-credential-manager

    macOS の場合は、GCM によって Git が自動的に構成されるため、git config を実行する必要はありません。

  • 抜粋（Windows での Git for Windows への同梱と警告）

    GCM を含む Git for Windows をインストールします。

    以前のバージョンの Git for Windows には、Windows 用の Git Credential Manager が付属していました。

    この古い製品はサポートが終了しており、OAuth を使用して GitHub に接続することはできません。

4-3. GitHub Docs: 英語版の Mac / Windows / Linux 向け GCM 解説（参考）

4-4. Azure DevOps（Azure Repos）での GCM サポート

  • URL（日本語版）

  • 抜粋（Azure Repos と GitHub でのサポート明記）

    Git Credential Manager を使用すると、Azure Repos Git リポジトリでの認証が簡略化されます。

    Git Credential Manager では、GitHub リポジトリでの 2 要素認証 もサポートされています。

  • 抜粋（Mac / Linux でのインストール方法の位置づけ）

    インストール手順は、GCM の GitHub リポジトリに含まれています。 Mac では、Homebrewを使用することをお勧めします。 Linux では、.deb または tarballからインストールできます。

5. まとめ（この記事の主張と公式情報の整合）

  • この記事の主張
    • 「WSL2 の Git で Azure DevOps に PAT なしでアクセスするには、Windows 側 GCM を無理やりたたくのではなく、Linux 用の GCM（または Linux 純正ヘルパー）を使うべき」
    • 「Mac でも Windows（Git Bash）でも、それぞれの OS 向けに用意された GCM を素直に入れておけば、GitHub も Azure DevOps も同じように HTTPS + ブラウザ連携で使える」
  • 公式情報との一致ポイント
    • GCM がクロスプラットフォームであり、Azure DevOps / GitHub / Bitbucket / GitLab を公式にサポートしていること（SourceForge / GCM の説明）。
    • GitHub Docs で、Mac / Windows / Linux のいずれでも GCM を使って HTTPS 認証をブラウザ + 2FA で完結できる と明記されていること。
    • Azure DevOps の公式ドキュメントで、Azure Repos に対して Git Credential Manager を使った認証 が推奨されていること。

上記の通り、

  • WSL2: Linux 用 GCM（あるいは記事で使っている Linux 純正ヘルパー）
  • macOS: Homebrew で入れた macOS 用 GCM
  • Windows / Git Bash: Git for Windows に同梱されている Windows 用 GCM

という「各 OS ネイティブの GCM」をそろえておけば、
Azure DevOps / GitHub / Bitbucket / GitLab などを、全部 PAT 手入力なしで HTTPS + ブラウザ認証で扱える、という結論は、上記公式ドキュメントと矛盾しない形で説明できる。

Discussion