Git/GitHub

GitHub 認証(SSH と HTTPS)

16

GitHub 認証(SSH と HTTPS) — Git Tips

GitHub への clone / push は、ブラウザのログインとは別に Git 専用の認証が必要です。GitHub は HTTPS 経由の Git 操作で ログインパスワードを受け付けません。代わりに PAT または SSH 鍵 を使います。選び方、設定手順、失敗時の見分け方です。

コンテナ内で繰り返し練習するなら setup フォルダも使えます。この手順だけでもホストで認証を通せます。

参考(GitHub 公式)


目次

  1. なぜパスワード認証が使えないのか
  2. SSH と HTTPS、どちらを選ぶか
  3. HTTPS + パーソナルアクセストークン(PAT)
  4. SSH 鍵での認証
  5. リモート URL を HTTPS ⇔ SSH に切り替える
  6. セキュリティ上の注意
  7. 詰まりやすい点

なぜパスワード認証が使えないのか

以前は https://github.com/... 形式のリモートに対して git push すると、GitHub のログイン用ユーザー名とパスワードで認証できました。しかし、パスワードは総当たり攻撃や漏えいのリスクが高いため、GitHub は 2021 年 8 月に Git 操作(HTTPS)でのパスワード認証を廃止しました。現在 HTTPS でパスワードを入力すると、次のようなメッセージで拒否されます。

remote: Support for password authentication was removed on August 13, 2021.remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.fatal: Authentication failed for 'https://github.com/<user>/<repo>.git/'

代わりに使えるのは次の 2 方式です。

  • HTTPS + パーソナルアクセストークン(PAT) — パスワード欄に PAT という文字列を入力する
  • SSH 鍵 — 公開鍵鍵暗号方式で、パスワードや PAT を都度入力しない

どちらを選んでも、Web ブラウザでの GitHub ログイン自体には影響しません。この認証はあくまで Git コマンドラインからのアクセスに対するものです。


SSH と HTTPS、どちらを選ぶか

観点 SSH HTTPS + PAT
初回セットアップ 鍵を作って GitHub に公開鍵を登録(やや手間) トークンを発行するだけ(比較的簡単)
日常操作 一度設定すればパスフレーズ入力以外は不要 Credential Manager 等にキャッシュされれば同様に快適
ネットワーク制限 ポート 22 が塞がれた環境では使えないことがある(社内 VPN・一部ネットワーク) ポート 443(HTTPS)なので通ることが多い
トークンの期限管理 鍵の失効を自分で管理(無期限運用も可能) PAT に有効期限を設定でき、期限切れで自動的に無効化される(安全側)
複数マシンでの使い分け マシンごとに鍵を作って個別登録しやすい マシンごとに別の PAT を発行できる
組織(Organization)のポリシー SSO 必須の Org では鍵の認可が必要な場合がある Org によって PAT の利用自体が制限される場合がある

迷ったら SSH を選んで問題ありません。ポート 22 の通信が制限されるネットワーク(一部の社内・学校環境)にいる場合は HTTPS + PAT が通りやすいです。両方を設定しておき、必要に応じてリモート URL を切り替える運用もできます。


HTTPS + パーソナルアクセストークン(PAT)

1. トークンを作成する

  1. ブラウザで GitHub にログインし、右上のアイコン → Settings を開く
  2. 左メニュー最下部の Developer settings を開く
  3. Personal access tokens の中から Fine-grained tokens または Tokens (classic) を選び、Generate new token
種類 特徴
Fine-grained personal access tokens リポジトリ単位・権限単位で細かく絞れる。GitHub が推奨する新しい方式
Personal access tokens (classic) 昔からある方式。スコープ(repo など)単位でまとめて許可する

Classic を選ぶ場合、プライベートリポジトリへの push / pull には repo スコープが必要です。パブリックリポジトリだけなら public_repo で足ります。

用途 必要なスコープ(classic)
プライベートリポジトリの読み書き repo
パブリックリポジトリの読み書き public_repo
Organization のメンバー一覧取得など(任意) read:org

Fine-grained を選ぶ場合は、対象リポジトリ(All repositories または特定リポジトリ)と、Contents の Read and write などの権限を個別に選びます。必要最小限の権限に絞るのが基本方針です。

トークンの 有効期限(Expiration) を設定し(無期限も選べますが、期限を切るほうが安全です)、Generate token を押します。生成直後の画面にしか全文が表示されない ため、その場でコピーしておきます。

2. Git 操作でトークンを使う

git clonegit push を HTTPS リモートに対して実行すると、ユーザー名とパスワードを聞かれることがあります。

git clone https://github.com/<ユーザ>/<リポジト>.git
Username for 'https://github.com': <あなたのGitHubユーザー名>Password for 'https://<ユーザー>@github.com': <ここに PAT を貼り付ける>

Password の欄に貼り付けるのは PAT であり、GitHub アカウントのログインパスワードではありません。 これが HTTPS 認証で最も混同しやすい点です。

3. Windows での資格情報の扱い(Git Credential Manager)

Git for Windows には Git Credential Manager(GCM) が同梱されており、初回認証時にブラウザが開いて GitHub のログイン画面 → 許可、という流れで済む場合があります。GCM が有効かどうかは次で確認できます。

git config --global credential.helper
manager

managermanager-core のような値が出ていれば GCM が使われています。特に何も設定していない場合、Git for Windows のインストーラーが既定で有効化していることが多いです。

一時的に平文でキャッシュする(学習用途向け、共有 PC では非推奨)場合は次を使います。

git config --global credential.helper store

store~/.git-credentials平文でトークンを保存するため、個人専用のマシン以外では避けてください。メモリ上に短時間だけキャッシュしたい場合は次のようにタイムアウトを指定します。

git config --global credential.helper 'cache --timeout=3600'

ただし cache ヘルパーは Unix ソケットに依存するため、Git for Windows(ネイティブ)では動作しないことがあります(credential-cache unavailable; no unix socket support)。Windows では既定の GCM(manager)や wincred を使ってください。

PAT を絶対に commit しない

PAT は文字列としてどこかのファイルにハードコードしないでください。.env に書く場合も、その .env.gitignore で無視されているか必ず確認します。誤って commit・push してしまった場合は、**GitHub の Settings > Developer settings でそのトークンを即座に Revoke(無効化)**し、新しいトークンを発行し直します。過去のコミットに含まれてしまった値は履歴から消えるまで有効なままなので、無効化を最優先にします。


SSH 鍵での認証

1. 鍵ペアを作成する

Ed25519 形式を推奨します(-C はコメント用のラベルで、識別しやすいメールアドレスなどを入れます)。

ssh-keygen -t ed25519 -C "you@example.com"

保存先を聞かれたら、既定のパス(例: ~/.ssh/id_ed25519)でよければ何も入力せず Enter します。続けてパスフレーズを聞かれます。付けると秘密鍵ファイルが暗号化され、万一ファイルが流出しても使われにくくなるため、通常は設定することを推奨します。省略する場合は空のまま Enter します。

Windows の PowerShell でも同じコマンドがそのまま使えます(Git for Windows に ssh-keygen が同梱されています)。

ssh-keygen -t ed25519 -C "you@example.com"

権限(Linux / macOS / WSL の場合)を確認しておきます。

chmod 700 ~/.sshchmod 600 ~/.ssh/id_ed25519chmod 644 ~/.ssh/id_ed25519.pub

Windows(ネイティブの PowerShell 上)では Unix パーミッションの概念がそのまま適用されないため、chmod は通常不要です。ただし WSL やコンテナ内で鍵を扱う場合は上記のパーミッションが必要です。

2. 公開鍵を GitHub に登録する

公開鍵ファイル(.pub が付くほう)の内容を表示してコピーします。

cat ~/.ssh/id_ed25519.pub
Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub

ssh-ed25519 AAAA... から始まる 1 行をすべてコピーし、GitHub の SSH and GPG keys ページを開きます。

  1. New SSH key を押す
  2. Title に分かりやすい名前を付ける(例: MyLaptop-2026
  3. Key にコピーした公開鍵を貼り付ける
  4. Add SSH key で保存する

3. 接続確認

ssh -T git@github.com

初回は次のようにホスト鍵の確認を求められるので yes と入力します。

The authenticity of host 'github.com (...)' can't be established....Are you sure you want to continue connecting (yes/no/[fingerprint])?

登録した公開鍵に対応する秘密鍵が正しく使われると、次のように成功メッセージが出ます。シェルには入れませんが、これは正常な仕様です(GitHub は SSH ログインシェルを提供していないため)。

Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

4. ssh-agent に鍵を登録する(複数鍵・パスフレーズ入力の省力化)

パスフレーズを付けた場合、ssh-agent に鍵を登録しておくと、ターミナルを開き直すたびの再入力を減らせます。

Windows(PowerShell):

Set-Service / Start-Service管理者として実行した PowerShell が必要です。通常権限だとアクセス拒否になります。

Get-Service ssh-agent | Set-Service -StartupType AutomaticStart-Service ssh-agentssh-add $env:USERPROFILE\.ssh\id_ed25519

ssh-agent サービスが存在しない場合は、設定 > アプリ > オプション機能 から「OpenSSH クライアント」を追加します。

Git Bash(Windows 上)/ macOS / Linux:

eval "$(ssh-agent -s)"ssh-add ~/.ssh/id_ed25519

登録済みの鍵一覧は次で確認できます。

ssh-add -l

リモート URL を HTTPS ⇔ SSH に切り替える

すでに clone したリポジトリでも、あとから認証方式を変えたい場合はリモート URL を書き換えるだけで済みます。まず現在の設定を確認します。

git remote -v
origin  https://github.com/<ユーザー>/<リポジトリ>.git (fetch)origin  https://github.com/<ユーザー>/<リポジトリ>.git (push)

HTTPS → SSH に変更:

git remote set-url origin git@github.com:<ユーザ>/<リポジト>.git

SSH → HTTPS に変更:

git remote set-url origin https://github.com/<ユーザ>/<リポジト>.git

変更後は再度 git remote -v で確認し、git fetch などの軽い操作で認証が通るかを試すと安全です。

git remote -vgit fetch origin

セキュリティ上の注意

資産 扱い
SSH の秘密鍵id_ed25519 など拡張子なしのファイル) 誰にも共有しない。公開鍵(.pub)だけを GitHub に登録する
パーソナルアクセストークン(PAT) パスワードと同様に扱う。Slack・チャット・コード・スクリーンショットに貼らない
漏えいした場合 SSH 鍵は GitHub の登録から削除し新しい鍵に切り替える。PAT は即座に Revoke して再発行する
.gitignore との関係 .env や鍵ファイルを誤って commit しないよう、事前に無視パターンへ入れておく

公開鍵と秘密鍵の違いを混同しないことが最初の防御線です。ファイル名に .pub が付いているものだけが「公開」してよい情報であり、拡張子の付かないファイル(秘密鍵本体)は絶対に他人に渡しません。


詰まりやすい点

Authentication failed(HTTPS)

remote: Invalid username or password.fatal: Authentication failed for 'https://github.com/<user>/<repo>.git/'

Password 欄に PAT を入れているかを確認します。GitHub のログインパスワードを入力していると必ず失敗します。PAT の先頭・末尾に余分な空白が入っていないかもコピー時によく起こるミスです。

Permission denied (publickey)(SSH)

git@github.com: Permission denied (publickey).fatal: Could not read from remote repository.

原因の切り分けには詳細ログが有効です。

ssh -vT git@github.com

出力中で どの鍵を試したかOffering public key: ... の行)を確認し、次を順にチェックします。

  • その鍵の公開鍵を GitHub の SSH and GPG keys に登録したか
  • 複数の鍵がある環境で、意図しない別の鍵が先に使われていないか(~/.ssh/configIdentityFile を明示すると解決しやすい)
  • 鍵ファイルの権限が緩すぎないか(Linux / WSL 環境で chmod 600 になっているか)

~/.ssh/config で GitHub 用の鍵を明示する例です。

Host github.com  HostName github.com  User git  IdentityFile ~/.ssh/id_ed25519  IdentitiesOnly yes

PAT の期限が切れた

remote: Support for password authentication was removed...

または単に認証ダイアログが再度出る場合、以前使っていた PAT が失効している可能性があります。GitHub の Personal access tokens ページで有効期限を確認し、切れていれば新規に発行して、Git 操作でトークンを使う の手順で再度認証を通します。Windows で Credential Manager にキャッシュされた古い資格情報が残っている場合は、資格情報マネージャー(コントロールパネル) から git:https://github.com のエントリを削除すると、次回の Git 操作で再入力を求められます。

パスワード欄に何を入れればいいか分からない

HTTPS のユーザー名・パスワードのダイアログが出た場合、ユーザー名は GitHub のユーザー名、パスワードは PAT です。SSH の場合はこのダイアログ自体が出ません(git@github.com:... 形式の URL を使っていれば、鍵ベースの認証に切り替わります)。ダイアログが出る/出ないを見るだけでも、現在 HTTPS と SSH のどちらのリモートを使っているかの判断材料になります。

Organization のリポジトリだけ認証やアクセスが通らない

個人アカウントでは通る認証が、Organization 配下のリポジトリでだけ失敗する場合、その Organization 側のポリシーが影響していることがあります。

症状 考えられる原因
PAT でアクセスできない Organization が PAT の利用自体を制限している、または未承認
SSO 認証を求められる Organization が SAML SSO を必須にしており、PAT や SSH 鍵を SSO に authorize する必要がある
SSH 鍵は登録済みなのに Permission denied Organization 側でその鍵がまだ SSO 認可されていない

このケースは個人の設定ミスではなく Organization 管理者側のポリシーに依存するため、詰まった場合は Organization の管理者や社内の手順に確認します。GitHub の PAT 一覧ページ(Personal access tokens)に、SSO 認可待ちのトークンには "Authorize" ボタンが表示されることがあるので、まずそこを確認すると早いです。

鍵ファイルの権限エラー

Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open.

秘密鍵ファイルの権限が緩すぎる(他ユーザーが読める状態)という警告です。Linux / WSL / Git Bash では次で修正します。

chmod 600 ~/.ssh/id_ed25519

Windows ネイティブの環境でこの警告が出る場合、OpenSSH for Windows のバージョンによって ACL ベースの権限チェックが行われることがあります。ファイルのプロパティ → セキュリティで、自分のアカウント以外のアクセス権を外すか、WSL 側で鍵を管理する運用に切り替えると安定します。

シェア