Gitでauthentication failedになる原因と対処法｜認証エラーの解決手順

2026年5月15日

Gitでauthentication failedになる原因と対処法｜認証エラーの解決手順

Git の authentication failed は、パスワードそのものが間違っている場合だけでなく、認証方式の選び方が今のサービス仕様と合っていないときによく出ます。

特に GitHub では HTTPS の Git 操作でパスワード認証が廃止されており、GitLab でも 2FA 有効時は personal access token が必要です。まずは「何を認証情報として送っているか」を切り分けるのが最短です。

すぐ確認したい点は remote の URL が https か ssh か
HTTPS なら、いま入力しているのがパスワードではなく トークン か
以前の認証情報が OS の資格情報ストアや Git Credential Manager に残っていないか
トークンの権限不足、期限切れ、リポジトリ権限不足がないか
Bitbucket Cloud は 2025年9月9日以降、App password の新規作成ができず、API token への移行が進んでいるか

ここがポイント: authentication failed の大半は、Git の打ち方ではなく、認証方式と保存済み認証情報の不整合で起きます。

まず最初に確認すること

最初の 2 分で、次の 3 点を見ます。ここがずれると、何度やり直しても同じエラーになります。

1. リモート URL の方式を確認する

git remote -v

出力例:

origin  https://github.com/example-org/sample.git (fetch)
origin  https://github.com/example-org/sample.git (push)

https:// なら、ユーザー名とトークン系の認証が必要です。git@github.com: のような URL なら SSH 鍵を使います。

2. どのサービスに接続しているかを確認する

同じ Git でも、GitHub、GitLab、Bitbucket Cloud で必要な認証情報が違います。

GitHub: HTTPS の Git 操作ではパスワード認証は使えず、personal access token か Git Credential Manager、GitHub CLI、SSH を使う
GitLab: HTTPS では personal access token などを使う。2FA 有効時はパスワードでは通らない
Bitbucket Cloud: HTTPS では API token か SSH を使うのが現行の中心

3. 以前の認証情報が残っていないかを疑う

入力し直したつもりでも、実際には古い資格情報が自動送信されていることがあります。

よくある場所は次のとおりです。

Windows: Credential Manager
macOS: Keychain Access
Linux: GCM、libsecret、cache などの credential helper

よくある原因と対処法

ここからは、原因ごとに対処を分けます。実務では 1 つずつ潰すほうが早いです。

HTTPS でパスワードを入れている

最も多い原因です。

GitHub では、コマンドラインの HTTPS Git 操作でアカウントのパスワードは使えません。GitLab でも、設定によっては personal access token が必要です。

対処:

GitHub: personal access token を作成して、パスワード欄にはそのトークンを入れる
GitLab: personal access token を作成し、必要な scope を付ける
Bitbucket Cloud: API token を使う

HTTPS で clone する最小例:

git clone https://github.com/USERNAME/REPO.git

この後に聞かれる:

Username: アカウント名
Password: アカウントパスワードではなくトークン

トークンの権限が足りない

トークンを作っても、権限が足りないと push で失敗します。clone は通るのに push だけ落ちる、という形で出やすい原因です。

切り分けの目安:

git fetch は成功するが git push だけ失敗する
読み取り権限だけの token を使っている
対象リポジトリや workspace まで scope を絞りすぎている

確認ポイント:

GitHub: fine-grained token の対象リポジトリと権限
GitLab: read_repository / write_repository など必要 scope
Bitbucket Cloud: read:repository:bitbucket と write:repository:bitbucket など必要 scope

トークンが期限切れ・失効している

最近まで動いていたのに急に失敗したなら、これを疑います。

特に GitLab は有効期限つき token 運用が前提になりやすく、Bitbucket Cloud も有効期限つき API token を作る流れです。GitHub の token も手動 revoke や組織ポリシーで無効になることがあります。

対処:

新しい token を発行する
古い token を credential helper や OS の資格情報ストアから削除する
再度 git pull や git push を実行し、更新後の token を保存する

保存済みの古い資格情報が自動で使われている

このケースでは、正しい token を用意しても直りません。Git が古い資格情報を先に送るからです。

Git の helper 設定確認:

git config --global --get credential.helper

代表的な対処:

Windows: Credential Manager で GitHub / GitLab / Bitbucket の既存エントリを削除
macOS: Keychain Access で対象ホストの古い認証情報を削除
Linux: 利用中の helper を確認し、必要なら再認証する

GitHub は HTTPS 利用時に Git Credential Manager や GitHub CLI の利用を案内しています。ブラウザ認証に切り替えると、手入力ミスやトークンの平文管理を減らしやすいです。

リモート URL が想定と違う

見落としやすい原因です。GitHub 用の token を作ったのに、実際の origin は GitLab を向いていた、という例は珍しくありません。

確認:

git remote -v

URL が違っていたら修正します。

HTTPS に直す例:

git remote set-url origin https://github.com/USERNAME/REPO.git

SSH に切り替える例:

git remote set-url origin git@github.com:USERNAME/REPO.git

アカウント自体には入れても、そのリポジトリ権限がない

ブラウザでサービスにログインできることと、Git でそのリポジトリへ push できることは別です。

確認したい点:

private リポジトリへの招待が有効になっているか
組織の SSO や 2FA を完了しているか
fork 元と fork 先を取り違えていないか
deploy token や project token が、対象リポジトリ専用かどうか

特に組織配下では、トークン自体は正しくても、組織側の認可が済んでいないために失敗することがあります。

最短で直すための手順

迷ったら、次の順番で進めると戻りが少なくなります。

手順1: URL 方式を確認する

git remote -v

https://... なら HTTPS 認証の問題として切り分ける
git@... なら SSH 鍵の問題として切り分ける

手順2: HTTPS ならパスワード運用をやめる

GitHub では HTTPS の Git 操作でパスワード認証は使えません。GitLab や Bitbucket Cloud でも、token ベースで考えるほうが安全です。

実務上の選択肢:

手元作業中心: Git Credential Manager や GitHub CLI を使う
CI や自動処理: スコープを絞った token を使う
毎回入力したくない: SSH へ切り替える

手順3: 古い資格情報を消す

保存済み認証情報が残っていると、修正が反映されません。

あわせて Git の helper も見ます。

git config --show-origin --get-all credential.helper

この出力で、どの helper が効いているかを確認します。

手順4: 新しい認証方式で再試行する

たとえば GitHub の HTTPS なら、次のどちらかに寄せると安定します。

GitHub CLI を使う

gh auth login

途中で HTTPS を選び、Git 認証も有効にします。

Git Credential Manager を使う

ブラウザログイン型で認証を保存できます。トークン文字列を直接 URL に埋め込まなくて済むのが利点です。

手順5: それでも直らなければ SSH に切り替える

HTTPS 認証まわりで詰まるなら、SSH のほうが管理しやすいことがあります。

リモート URL を SSH に変更:

git remote set-url origin git@github.com:USERNAME/REPO.git

接続確認:

ssh -T git@github.com

GitHub では、認証に成功するとユーザー名を含むメッセージが返ります。ここで通れば、少なくとも SSH 鍵登録までは完了しています。

環境別の実践例

環境ごとに、つまずき方が少し違います。

Windows

Windows では、古い資格情報が Credential Manager に残るのが典型です。

確認したいこと:

Git for Windows が古すぎないか
Git Credential Manager を使っているか
Credential Manager 内の古い github.com や gitlab.com の項目が残っていないか

症状としては、毎回正しい token を入れているつもりでも、実際には古い資格情報で即失敗します。

macOS

macOS では Keychain に残った認証情報が原因になりやすいです。

対処:

Keychain Access で対象ホストの古い項目を削除
もう一度 Git 操作をして、新しい token で保存し直す

Linux

Linux は利用中の credential helper が環境ごとに違います。

よくある確認:

git config --global --get credential.helper
git config --system --get credential.helper

cache を使っているだけなら、一定時間後に消えます。長期運用の token 管理には向きません。Git の公式ドキュメントでも、personal access token の永続管理には persistent storage や OAuth helper の利用が案内されています。

NG例と改善例

よくある失敗を、短く並べておきます。

NG例1: GitHub でアカウントパスワードを入れる

NG:

Username: 自分の GitHub ユーザー名
Password: GitHub にログインする普段のパスワード

改善:

Password 欄には personal access token を入れる
もしくは gh auth login や GCM を使う

NG例2: token を URL に固定で埋め込む

NG:

git remote set-url origin https://USERNAME:TOKEN@github.com/USERNAME/REPO.git

この方法はシェル履歴や設定ファイルに token が残りやすく、共有端末では危険です。

改善:

対話プロンプトで入力する
GCM や GitHub CLI を使う
CI では secret 管理に保存する

NG例3: clone はできたのに push 失敗を「Git の不具合」と考える

実際には、読み取りだけの権限で clone は通り、書き込み不足で push だけ落ちることがよくあります。

改善:

token の scope を見直す
リポジトリへの書き込み権限自体があるか確認する

サンプル: 典型的な確認フロー

例1: GitHub の HTTPS push が失敗する

入力:

git remote -v
git push origin main

確認ポイント:

origin が https://github.com/... になっているか
password ではなく PAT を使っているか
古い GitHub 資格情報が OS に残っていないか

対処後の再試行:

gh auth login
git push origin main

例2: GitLab で 2FA 有効後に急に失敗する

状況:

ブラウザログインはできる
git pull / git push だけ失敗する

対処:

personal access token を発行
write_repository が必要なら scope を付ける
旧パスワードを保存している credential helper を更新する

例3: Bitbucket Cloud の古い App password 運用が混ざっている

2026年4月22日時点では、Bitbucket Cloud は API token への移行が進んでいます。App password の既存運用が残っている環境では、更新時に混乱しやすいです。

見直す点:

新規作成しようとして App password 画面を探していないか
Git 用の API token に必要 scope を付けたか
ユーザー名や固定ユーザー名 x-bitbucket-api-token-auth の使い方を取り違えていないか

HTTPS と SSH はどちらを使うべきか

用途で分けるのが現実的です。

HTTPS が向く場面

会社のネットワークやプロキシ配下で使う
ブラウザ認証や GCM を使って管理したい
端末ごとに OS の資格情報ストアへ安全に保存したい

SSH が向く場面

開発端末から繰り返し push / pull する
毎回 token を扱いたくない
複数リポジトリを安定して使いたい

個人の開発端末なら SSH、業務端末で組織ポリシーに合わせるなら HTTPS + 公式 helper が扱いやすいことが多いです。

それでも解決しないときの確認リスト

最後に、見落としやすい順でまとめます。

git remote -v でホスト名と URL 方式を確認したか
入力しているのはパスワードではなく token か
token に期限切れや revoke がないか
token の scope は clone 用か push 用か、必要権限を満たしているか
古い資格情報を Keychain / Credential Manager / helper から消したか
リポジトリ自体への権限があるか
組織の SSO、2FA、承認フローを完了しているか
SSH 利用時は公開鍵をアカウントに登録し、ssh -T で疎通確認したか

authentication failed は抽象的な文言ですが、調べるポイントはかなり絞れます。まず https か ssh かを見て、その次に「いま送っている認証情報が何か」を確認してください。そこが合っていれば、残る論点は保存済み資格情報か権限設定です。

参照リンク

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！