Git 読了 6 分

Mac に GitHub CLI を初めて入れた話 — `gh auth login` で SSH 鍵問題が一発解決

SSH じゃないもう一本の道

過去に SSH 認証で詰まったときの記事も書いていますが、今回はそれと別ルート（HTTPS + OAuth）の話です。

ふだん本業で git は普通に使っているのですが、よく考えてみると、自分のターミナルから GitHub に対して認証を通したのは、これがほとんど初めてでした。
今回、個人で持っているリポジトリに手元から push する必要が出て、「トークン使わない場合、私のターミナルからGitHub にどうやってログインするんだっけ」となりました。

結論から言うと、brew install gh と gh auth login の 2 コマンドで終わりました。それまで小一時間、~/.ssh/ の中身を眺めて唸っていたことを思うと、もっと早く乗り換えればよかった、というのが今の感想です。

つまずいた状況

私の ~/.ssh/ ディレクトリには、思っていたよりたくさんの鍵が残っていました。

並べてみると、過去にフリーランスで仕事をしていた頃の鍵、本業に入る前に試験用に作った鍵、何のために作ったか思い出せない鍵、と「過去の自分」が積もっていました。
GitHub に対して ssh -T git@github.com を叩いても、Permission denied。~/.ssh/config には複数のホストエイリアスがあるはずで、それらを 1 つずつ解読していけば、たぶん 30 分くらいで正しい組み合わせは見つかります。けれど、時刻はもう夜で、これからやりたいのは「リポジトリに 1 回 push する」だけでした。

「30 分かけて過去の自分の鍵を理解する」と「5 分で新しい認証経路を作る」のどちらを選ぶか、というささやかな分岐点に立たされたわけです。

gh CLI を選んだ理由

GitHub CLI（コマンド名 gh）は、GitHub が公式に出しているコマンドラインツールです。push のような Git 操作だけでなく、PR の作成・マージ、Issue の管理、リポジトリの作成までターミナルから完結できます。

私が一番惹かれたのは、認証がブラウザベースで完結する 点でした。
SSH 鍵を生成して、GitHub に登録して、~/.ssh/config を整えて、エージェントに足して、と段階を踏むよりも、ブラウザでログインして数字を 1 回入れるだけのほうが、間違いなく速い。

過去の鍵を整理する作業は、いずれやったほうがいいことですが、今夜やるべきことではない、と判断しました。

実際の手順

1. Homebrew でインストール

brew install gh

私の場合は 1 分弱で終わりました。インストール時に古い glob パッケージの deprecation 警告が出ましたが、開発用ツールなので無視して大丈夫だと思います。

2. gh auth login を実行

gh auth login

ここから対話が始まります。聞かれることは多くなく、全部矢印キーで選んでいけます。

  • What account do you want to log into? → GitHub.com
  • What is your preferred protocol for Git operations? → HTTPS
  • Authenticate Git with your GitHub credentials? → Y
  • How would you like to authenticate GitHub CLI? → Login with a web browser

最後の選択をすると、ターミナルに 8 桁の英数字混じりのコードが表示されます。これをコピーして、Enter キーを押すと、ブラウザが自動で開きます。

3. ブラウザで Authorize

開いたページの入力欄にコードを貼り付けると、GitHub の「Authorize GitHub CLI」画面が出ます。
ここで権限のリストを確認します。私の場合は、

  • Gists: Read and write
  • Organizations and teams: Read-only
  • Repositories: Public and private
  • Workflow: Update GitHub Action Workflow files

の 4 つでした。CLI として一通りの操作をしたいなら必要な範囲です。
Organization access のセクションに、自分が所属している Organization も表示されるので、必要なものにチェックを入れて Authorize ボタンを押せば完了。

4. ターミナルに戻る

ブラウザの「Authorize」ボタンを押した時点で完了したつもりでいたのですが、ここで一回つまずきました。ターミナル側でも認証完了処理が走り終わる必要があります。

ターミナルに戻って、

✓ Authentication complete.
- gh config set -h github.com git_protocol https
✓ Configured git protocol
✓ Logged in as <自分のユーザー名>

このメッセージが出ているはずです。ここまで来て、ようやく認証情報がローカルに保存されます。私はブラウザ側で OK を押した時点で完了したつもりになっていて、別のターミナルから gh auth status を叩いたら「未ログイン」と返ってきて、5 分ほど混乱しました。

ブラウザの認証は「2 段階目」で、ターミナルの最終処理が「3 段階目」だと思っておくと、混乱しません。

認証後

gh auth status で Logged in to github.com account <自分> と出れば、認証は通っています。
ここから先は、git push を叩くたびに HTTPS 認証ダイアログが出ることもなく、gh pr create で PR をターミナルから作ることもできて、急に世界がフラットになります。

ちなみに gh は git の credential helper として自分自身を登録するので、git push も gh 経由の認証で通るみたいです。SSH 鍵を整理しなくても、HTTPS 経由で完全に運用できる、というのは思ったより快適でした。

学んだこと

1. 「過去の自分の鍵」を整理する作業は、別の日にやる

SSH 鍵の整理は本来やったほうがいい作業です。けれど、それは「今やりたい push」とは別の問題です。混ぜない方が、両方早く終わります。

2. 認証は「ブラウザ OAuth」を最初の選択肢にする

2026 年に新しく開発環境を整えるなら、ブラウザベースの OAuth 認証を最初に試すのが手早いです。SSH 鍵は強力ですが、運用コストが高い場面が増えてきました。

3. 「3 段階」の認証フローを忘れない

ターミナルで gh auth login を叩く / ブラウザで Authorize する / ターミナルで完了処理を待つ。この 3 段階のうち、最後の 1 段階を忘れがちでした。

結びに

5 年やってきて、自分でも「これは初めてだ」と思える小さな初めて、はまだ残っています。
過去の自分が積もったマシンの上で、新しい認証を 1 つ通すだけの作業でしたが、それは確かに私の手元の景色を 1 段階クリアにしてくれました。

brew install gh と gh auth login。困っている人がもしいたら、SSH config を眺める前に、まずこの 2 行を試してみてほしいです。

 

関連する notes