SSHとトークンを使用した一般的なGit認証エラーの解決
リモートURLをSSHキー、HTTPSトークン、および資格情報ヘルパーに一致させることで、一般的なGit認証エラーを修正します。
SSHとトークンを使用した一般的なGit認証エラーの解決
ほとんどのGit認証問題は、リモートURL、Gitが使用しようとする資格情報、およびGitホスティングアカウントの権限の不一致に起因します。エラーテキストは劇的に見えるかもしれませんが、Gitがどのパスを取っているかを理解すれば、修正は通常機械的です。
まずリモートURLを確認します：
git remote -v
https://github.com/org/repo.git が表示された場合、GitはHTTPSを使用しており、ユーザー名とトークン、またはそれを提供できる資格情報ヘルパーが必要です。[email protected]:org/repo.git が表示された場合、GitはSSHを使用しており、ホストに登録された公開鍵と一致する秘密鍵が必要です。
トラブルシューティング中にこれらを混在させないでください。HTTPSまたはSSHを選択し、リモートURLを一致させてから、そのパスを直接テストします。
エラーを文字通りに読む
fatal: Authentication failed for 'https://...' は通常、Gitがサーバーに到達したが有効なHTTPS資格情報を提示しなかったことを意味します。古い資格情報がキャッシュされているか、トークンが期限切れか、トークンがそのリポジトリにアクセスできない可能性があります。
remote: Permission to org/repo denied または 403 Forbidden は通常、あなたの身元は認識されたが、操作に対する権限がないことを意味します。例えば、間違ったアカウントのトークン、書き込みアクセスのないトークン、または別のユーザーに関連付けられたSSHキーを使用している可能性があります。
Permission denied (publickey) は、SSHがサーバーが受け入れるキーを提供しなかったことを意味します。
HTTPSでの繰り返しのユーザー名/パスワードプロンプトは、通常Gitが拒否を受け取り続け、再度尋ねていることを意味します。Git操作にトークンが必要なホストでは、アカウントパスワードを繰り返し入力しても役に立ちません。
個人アクセストークンを使用したHTTPSの修正
HTTPSリモートの場合、Gitホストアカウント設定で個人アクセストークンを作成します。正確なメニュー名はGitHub、GitLab、Bitbucket、およびセルフホストプラットフォームで異なりますが、形状は同じです：トークンを作成し、リポジトリアクセスを付与し、組織のポリシーに一致する有効期限を設定し、すぐにコピーします。
Gitがプロンプトを表示したら、通常のユーザー名を使用し、トークンをパスワードとして貼り付けます：
Username: your-username
Password: <paste-token-here>
動作する最も狭い権限を使用します。プッシュするプライベートリポジトリの場合、読み取りおよび書き込みリポジトリアクセスが必要です。公開リポジトリをクローンする場合、トークンはまったく必要ないかもしれません。細かいトークンと組織のSSOルールは別の層を追加する可能性があります：トークンは存在しても、会社のリポジトリにアクセスする前に承認やSSO認可が必要な場合があります。
Gitが新しいトークンのプロンプトを表示しない場合、おそらく古いキャッシュされた資格情報を使用しています。ホストの保存されたエントリをクリアしてから、もう一度試してください。
macOSでは、キーチェーンアクセスでGitホストに関連するエントリ（github.com や git:https://github.com など）を確認します。
Windowsでは、資格情報マネージャーを開き、ホストの関連する汎用資格情報を削除します。
Linuxでは、設定されたヘルパーを確認します：
git config --global --get credential.helper
git config --show-origin --get-all credential.helper
cache ヘルパーは資格情報を一時的にメモリに保存します。store ヘルパーは、より安全なストレージ層を設定しない限り、資格情報をプレーンテキストでディスクに書き込むため、注意して使用してください。Gitの資格情報ヘルパーシステムは、ヘルパーに資格情報を要求し、成功した資格情報を保存させるように設計されています。セキュリティは選択したヘルパーに依存します。
便利なHTTPSリセットシーケンスは次のとおりです：
git remote -v
git config --show-origin --get-all credential.helper
# OSの資格情報ストアから古い資格情報を削除
git ls-remote origin
git ls-remote origin は、ワーキングツリーを変更せずにリモートに接続するため、クリーンなテストです。
キーを使用したSSHの修正
SSHリモートの場合、まずキーが既にあるかどうかを確認します：
ls -al ~/.ssh
一般的なキー名には id_ed25519、id_rsa、およびホスト固有の名前（github_work_ed25519 など）があります。.pub ファイルはGitホストにアップロードする公開鍵です。.pub のないファイルは秘密鍵であり、共有してはいけません。
新しいキーが必要な場合、Ed25519は現代のシステムで良いデフォルトです：
ssh-keygen -t ed25519 -C "[email protected]"
環境に特定の自動化理由がない限り、パスフレーズを使用します。次に、公開鍵をGitホストアカウントまたはデプロイキー設定に追加します：
cat ~/.ssh/id_ed25519.pub
接続を直接テストします：
ssh -T [email protected]
GitLabやBitbucketの場合は、ホスト名を置き換えます。成功したテストは通常、挨拶またはシェルアクセスが提供されないというメッセージを表示します。それで問題ありません。Git-over-SSH認証は引き続き機能します。
SSHがまだ失敗する場合、SSHクライアントが何をしているかを確認します：
ssh -vT [email protected]
どのキーが提供されているかを示す行を探します。キーが提供されていない場合、エージェントにロードします：
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
同じホストに複数のアカウントがある場合、~/.ssh/config を使用して、Gitがどのキーがどのリモートに属するかを認識できるようにします：
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/github_work_ed25519
IdentitiesOnly yes
次に、リポジトリをそのエイリアスにポイントします：
git remote set-url origin git@github-work:org/repo.git
これにより、SSHが個人キーを仕事のリポジトリに提供する一般的な問題を回避できます。
プロトコルのクリーンな切り替え
チームがSSHに標準化している場合、HTTPSリモートを次のように変更します：
git remote set-url origin [email protected]:ORG/REPO.git
会社がSSHをブロックしているか、HTTPS検査が必要な場合、逆に切り替えます：
git remote set-url origin https://github.com/ORG/REPO.git
URLを変更した後、読み取り操作でテストします：
git fetch origin
次に、失敗したアクションをテストします：
git push origin HEAD
フェッチは成功するがプッシュが失敗する場合、認証はおそらく有効で、認可が問題です。ブランチ保護、リポジトリロール、トークンスコープ、および組織のSSOルールを確認します。
CIおよびサーバー環境
ビルドエージェントやサーバーでは、可能な限り人間の個人トークンを使用しないでください。デプロイキー、マシンユーザー、またはCIシステムの組み込み資格情報ストアを優先します。シークレットをコマンド履歴やログから保護します。制御された使い捨て環境でない限り、次のようにトークンをリモートURLに貼り付けないでください：
https://[email protected]/org/repo.git
そのスタイルは、ログ、プロセスリスト、シェル履歴、および設定ファイルを通じて漏洩する可能性があります。
Jenkins、GitHub Actionsランナー、GitLabランナー、および類似のシステムでは、資格情報をプラットフォームのシークレットメカニズムに保存し、必要なジョブにのみ注入します。
クイックチェックリスト
行き詰まったときに順番に実行します：
git remote -v
git ls-remote origin
URLがHTTPSの場合、古いキャッシュされた資格情報をクリアし、適切なリポジトリ権限を持つ現在のトークンを使用します。
URLがSSHの場合、次を実行します：
ssh -T git@your-hostname
ssh -vT git@your-hostname
期待されるキーが提供され、その公開部分が正しいアカウントに登録されていることを確認します。
認証が成功してもプッシュが失敗する場合、認可ルールを探します：保護されたブランチ、不足している書き込みロール、期限切れのSSO認可、読み取り専用のデプロイキー、または書き込み権限のないトークン。
信頼できる修正は、ランダムなパスワードを試すことではありません。リモートプロトコルを資格情報のタイプに一致させ、古いキャッシュされた資格情報を削除し、接続を直接テストし、次にリポジトリの権限を確認します。