日本語 ▾ トピック ▾ 最新バージョン ▾ gitcredentials 最終更新: 2.50.0

名前

gitcredentials - Gitにユーザー名とパスワードを提供する

概要

git config credential.https://example.com.username myusername
git config credential.helper "$helper $options"

説明

Gitは、操作を実行するためにユーザーから認証情報が必要となる場合があります。たとえば、HTTP経由でリモートリポジトリにアクセスするために、ユーザー名とパスワードを要求する必要があるかもしれません。一部のリモートでは、パスワードとして個人アクセストークンまたはOAuthアクセストークンを受け入れます。このマニュアルでは、Gitがこれらの認証情報を要求するメカニズム、およびこれらの認証情報を繰り返し入力するのを避けるためのいくつかの機能について説明します。

認証情報の要求

認証情報ヘルパーが定義されていない場合、Gitはユーザーにユーザー名とパスワードを要求するために以下の戦略を試します。

  1. GIT_ASKPASS 環境変数が設定されている場合、変数で指定されたプログラムが呼び出されます。適切なプロンプトがコマンドラインでプログラムに提供され、ユーザーの入力はその標準出力から読み取られます。

  2. それ以外の場合、core.askPass 設定変数が設定されている場合、その値が上記のように使用されます。

  3. それ以外の場合、SSH_ASKPASS 環境変数が設定されている場合、その値が上記のように使用されます。

  4. それ以外の場合、ユーザーはターミナルでプロンプトされます。

繰り返し入力の回避

同じ認証情報を何度も入力するのは面倒な場合があります。Gitは、この煩わしさを軽減するために2つの方法を提供します。

  1. 特定の認証コンテキストに対するユーザー名の静的設定。

  2. パスワードをキャッシュまたは保存する、あるいはシステムパスワードウォレットまたはキーチェーンと連携するための認証情報ヘルパー。

最初の方法はシンプルで、パスワードを安全に保存する場所がない場合に適しています。通常、これをconfigに追加することで設定されます。

[credential "https://example.com"]
	username = me

一方、認証情報ヘルパーは、Gitがユーザー名とパスワードの両方を要求できる外部プログラムです。通常、OSまたは他のプログラムが提供する安全なストレージとインターフェースします。あるいは、認証情報を生成するヘルパーは、特定のサーバーの認証情報をAPI経由で生成するかもしれません。

ヘルパーを使用するには、まず使用するヘルパーを選択する必要があります（リストは以下を参照）。

サードパーティ製のヘルパーがインストールされている場合もあります。git help -a の出力で credential-* を検索し、個々のヘルパーのドキュメントを参照してください。ヘルパーを選択したら、その名前を credential.helper 変数に入れることで、Gitにそれを使用するように指示できます。

  1. ヘルパーを見つける。

    $ git help -a | grep credential-
credential-foo

  2. その説明を読む。

    $ git help credential-foo

  3. Gitにそれを使用するように指示する。

    $ git config --global credential.helper foo

利用可能なヘルパー

Gitは現在、以下のヘルパーを含んでいます。

cache

認証情報を短時間メモリにキャッシュします。詳細は git-credential-cache[1] を参照してください。

store

認証情報をディスクに無期限に保存します。詳細は git-credential-store[1] を参照してください。

セキュアな永続ストレージを持つ人気のあるヘルパーには以下が含まれます。

  • git-credential-libsecret (Linux)

  • git-credential-osxkeychain (macOS)

  • git-credential-wincred (Windows)

  • Git Credential Manager (クロスプラットフォーム、Git for Windowsに同梱)

コミュニティは、Git認証情報ヘルパーの包括的なリストを https://git.dokyumento.jp/doc/credential-helpers で管理しています。

OAuth

パスワードや個人アクセストークンの入力に代わる方法として、OAuth認証情報ヘルパーを使用する方法があります。最初の認証では、ホストにブラウザウィンドウが開きます。その後の認証はバックグラウンドで行われます。多くの人気のあるGitホストがOAuthをサポートしています。

OAuthをサポートする人気のあるヘルパーには以下が含まれます。

認証情報のコンテキスト

Gitは、各認証情報がURLによって定義されたコンテキストを持つと見なします。このコンテキストは、コンテキスト固有の設定を検索するために使用され、ヘルパーに渡されます。ヘルパーはこれをセキュアなストレージへのインデックスとして使用する場合があります。

たとえば、https://example.com/foo.git にアクセスしているとします。Gitがこのコンテキストに一致するセクションがあるかどうかをconfigファイルで探すとき、コンテキストがconfigファイルのパターンよりも特定のサブセットである場合に、両方を一致と見なします。たとえば、configファイルに以下がある場合、

[credential "https://example.com"]
	username = foo

すると一致します。プロトコルは両方とも同じで、ホストも両方とも同じであり、「パターン」URLはパスコンポーネントをまったく気にしません。しかし、このコンテキストは以下とは一致しません。

[credential "https://kernel.org"]
	username = foo

ホスト名が異なるためです。また、foo.example.com とも一致しません。Gitはホスト名を正確に比較し、2つのホストが同じドメインの一部であるかどうかを考慮しません。同様に、http://example.com のconfigエントリは一致しません。Gitはプロトコルを正確に比較します。ただし、http.<URL>.* オプションと同様に、ドメイン名でワイルドカードやその他のパターンマッチング手法を使用できます。

「パターン」URLにパスコンポーネントが含まれる場合、これも正確に一致する必要があります。コンテキスト https://example.com/bar/baz.git は、https://example.com/bar/baz.git のconfigエントリに一致します（https://example.com のconfigエントリにも一致することに加えて）が、https://example.com/bar のconfigエントリには一致しません。

設定オプション

認証情報コンテキストのオプションは、credential.* (すべての認証情報に適用) または credential.<URL>.* で設定できます。ここで <URL> は上記で説明したコンテキストに一致します。

以下のオプションはどちらの場所でも利用できます。

helper

外部認証情報ヘルパーの名前、および関連するオプション。ヘルパー名が絶対パスでない場合、文字列 git credential- が前置されます。結果の文字列はシェルによって実行されます (したがって、たとえばこれを foo --option=bar に設定すると、シェル経由で git credential-foo --option=bar が実行されます)。使用例については、特定のヘルパーのマニュアルを参照してください。

credential.helper 設定変数のインスタンスが複数ある場合、各ヘルパーは順番に試行され、ユーザー名、パスワード、または何も提供しない場合があります。Gitがユーザー名と期限切れでないパスワードの両方を取得したら、それ以上ヘルパーは試行されません。

credential.helper が空文字列に設定されている場合、これはヘルパーリストを空にリセットします (したがって、下位優先度の設定ファイルで設定されたヘルパーを、空文字列ヘルパーを設定し、その後に希望するヘルパーのセットを続けることで上書きできます)。

username

URLで提供されない場合のデフォルトのユーザー名。

useHttpPath

デフォルトでは、Gitはhttp URLの「パス」コンポーネントを外部ヘルパーによるマッチングに値すると見なしません。これは、https://example.com/foo.git に保存された認証情報が https://example.com/bar.git にも使用されることを意味します。これらのケースを区別したい場合は、このオプションを true に設定します。

カスタムヘルパー

認証情報を保持する任意のシステムと連携するために、独自のカスタムヘルパーを作成できます。

認証情報ヘルパーは、Gitによって実行され、認証情報を長期ストレージ（「長期」とは単に単一のGitプロセスよりも長い期間を意味します。例えば、認証情報は数分間メモリに保存されたり、ディスクに無期限に保存されたりします）から取得したり、そこに保存したりするプログラムです。

各ヘルパーは、設定変数 credential.helper (およびその他、git-config[1] を参照) の単一の文字列で指定されます。この文字列は、以下のルールを使用してGitによって実行されるコマンドに変換されます。

  1. ヘルパーストリングが「!」で始まる場合、それはシェルスニペットと見なされ、「!」の後のすべてがコマンドになります。

  2. それ以外の場合、ヘルパーストリングが絶対パスで始まる場合、そのままのヘルパーストリングがコマンドになります。

  3. それ以外の場合、文字列「git credential-」がヘルパーストリングの前に付加され、結果がコマンドになります。

結果のコマンドには「操作」引数（詳細は下記参照）が追加され、結果はシェルによって実行されます。

以下にいくつかの仕様例を示します。

# run "git credential-foo"
[credential]
	helper = foo

# same as above, but pass an argument to the helper
[credential]
	helper = "foo --bar=baz"

# the arguments are parsed by the shell, so use shell
# quoting if necessary
[credential]
	helper = "foo --bar='whitespace arg'"

# store helper (discouraged) with custom location for the db file;
# use `--file ~/.git-secret.txt`, rather than `--file=~/.git-secret.txt`,
# to allow the shell to expand tilde to the home directory.
[credential]
	helper = "store --file ~/.git-secret.txt"

# you can also use an absolute path, which will not use the git wrapper
[credential]
	helper = "/path/to/my/helper --with-arguments"

# or you can specify your own shell snippet
[credential "https://example.com"]
	username = your_user
	helper = "!f() { test \"$1\" = get && echo \"password=$(cat $HOME/.secret)\"; }; f"

一般的に、上記ルール (3) はユーザーが指定するのに最も簡単です。認証情報ヘルパーの作成者は、プログラム名を「git-credential-$NAME」とし、インストール時に $PATH または $GIT_EXEC_PATH に配置することで、ユーザーが git config credential.helper $NAME でそれを有効にできるように努めるべきです。

ヘルパーが実行されるとき、コマンドラインには以下のいずれかの「操作」引数が追加されます。

get

一致する認証情報があれば返します。

store

ヘルパーに適用可能であれば、認証情報を保存します。

erase

ヘルパーのストレージから、一致する認証情報があれば削除します。

認証情報の詳細はヘルパーの標準入力ストリームで提供されます。正確な形式は、git credential プラミングコマンドの入力/出力形式と同じです（詳細な仕様については、git-credential[1] のセクション INPUT/OUTPUT FORMAT を参照してください）。

get 操作の場合、ヘルパーは同じ形式で属性のリストを標準出力に出力する必要があります（一般的な属性については git-credential[1] を参照してください）。ヘルパーは、提供すべき有用な情報がなければ、サブセット、あるいはまったく値を出力しないことも自由です。提供された属性は、Gitの認証情報サブシステムがすでに知っている属性を上書きします。認識されない属性は黙って破棄されます。

すべての属性を上書きすることは可能ですが、適切に動作するヘルパーは、ユーザー名とパスワード以外の属性についてはこれを控えるべきです。

ヘルパーが quit 属性を true または 1 の値で出力した場合、それ以上のヘルパーは参照されず、ユーザーへのプロンプトも行われません (認証情報が提供されていない場合、操作は失敗します)。

同様に、ユーザー名とパスワードの両方が提供された後は、それ以上ヘルパーは参照されません。

store または erase 操作の場合、ヘルパーの出力は無視されます。

ヘルパーが要求された操作の実行に失敗したり、潜在的な問題をユーザーに通知する必要がある場合、標準エラー出力に書き込むことができます。

要求された操作をサポートしない場合（例：読み取り専用ストレージまたはジェネレーター）、要求を黙って無視する必要があります。

ヘルパーが他の操作を受け取った場合、要求を黙って無視する必要があります。これにより、将来の操作が追加される余地が残されます（古いヘルパーは新しい要求を無視するだけです）。

GIT

git[1]スイートの一部

scroll-to-top