【Git】
リモート接続でのセキュリティ
（SSHとHTTPS）

by
  • SSHとHTTPSはどちらも通信路の暗号化強度は同等ですが、認証の仕組みが異なります。
  • HTTPSはPersonal Access Tokenという文字列をネットワーク経由で送って認証し、SSHは秘密鍵をローカルに保ったまま署名だけを返して認証します。
  • 秘密鍵がネットワークに流れないSSHはトークン漏洩のリスクが低い設計ですが、鍵をパスフレーズなしで保管すれば端末侵害時にそのまま使われます。
  • 「どの方式か」より「認証情報がどこにあり、誰が触れられるか」がセキュリティの実質的な差を生みます。

関連記事

1. SSHとHTTPSでの認証の違い

GitHubやGitLabにリモート接続するとき、URLの形式でSSHかHTTPSかが決まります。

SSHとHTTPSの認証の違い HTTPS SSH T Personal Access Token 文字列をネットワーク経由で送信 ① ユーザー名 + PAT を送信 ② サーバーが照合して認証 ⚠ トークン漏洩リスクあり 鍵ペア認証 秘密鍵はローカルから出ない ① サーバーがチャレンジを発行 ② 秘密鍵で署名して返す ✓ 秘密鍵はネットワーク非流通 通信路の暗号化強度はどちらも同等（TLS 1.3 ≒ SSH暗号化）
  • SSHなら git@github.com:user/repo.git、
  • HTTPSなら https://github.com/user/repo.git です。

どちらを選ぶかは、認証の仕組みとセキュリティの設計に関わる話です。

1.1. HTTPSはパスワードかトークンで認証

HTTPSは、接続のたびにユーザー名とパスワード、またはPersonal Access Tokenを使って認証します。

Personal Access Token（以下PAT）はGitHubのアカウント設定から発行する文字列で、パスワードの代替として機能します1。
認証情報をキャッシュすれば毎回入力せずに済みますが、キャッシュされた認証情報はファイルやOS側の認証マネージャーに保存されます。

1.2. SSHは秘密鍵で認証

SSHは、公開鍵と秘密鍵のペアを使います。

公開鍵をGitHubに登録し、秘密鍵はローカルに保管します。
接続時にサーバーがチャレンジを発行し、ローカルの秘密鍵でそれに署名して返すことで認証が完了します2。
パスワードはネットワーク上を流れません。

この違いが、セキュリティを評価するときの軸を決めます。

2. 観点別に比べる

観点HTTPSSSH
通信路の暗号化TLS 1.3SSH独自（同等）
認証素材PAT（文字列）鍵ペア（公開鍵暗号）
認証情報の流通PATがネットワークを通る秘密鍵はローカルのみ
ファイアウォールポート443で通りやすいポート22が遮断される場合あり
初期設定の手間少ない鍵生成と登録が必要
複数端末の管理PATで統一しやすい端末ごとの鍵管理が必要

認証情報の管理を丁寧にできるなら、SSHの鍵ベース認証はPATより漏洩時のリスクが低い設計です。
ただし、端末の保護が難しい環境や、CIでの利用が主なら、有効期限付きPATを使うHTTPSも合理的な選択になります。

2.1. 通信路の暗号化はどちらも同等

「SSHのほうが安全」という話を聞いたとき、それが通信路の安全性を指しているなら、少し注意が必要です。

HTTPSはTLSで通信を暗号化します。
現在主流のTLS 1.3は前方秘匿性を持つ鍵交換を強制し、盗聴や改ざんに対して強固です3。
SSHも独自の暗号化機構を持ちますが、通信路の保護という点ではTLS 1.3と同程度の強度があります。

つまり、どちらも中間者攻撃に対して安全に設計されており、通信路レベルで一方が著しく弱いということはありません。

2.2. 認証の強さと奪われるリスク

ただし、通信路ではなく「認証」に目を向けると、差が出てきます。

HTTPSで使うPATは、GitHubのアカウントに紐付く文字列です。
漏れたとき、そのトークンを手に入れた人間は即座に認証できます。
パスワードマネージャーやCredential Managerに保存されているなら、端末を奪われた場合のリスクも考える必要があります。

SSHの秘密鍵は、長さと構造の面でPATより推測が困難です。
ed25519を使えば256ビットの楕円曲線暗号になります4。

秘密鍵はネットワークに送られず、サーバー側には公開鍵しか存在しないため、GitHubのサーバーが侵害されても秘密鍵は流出しません5。

ただし、秘密鍵ファイルがローカルに平文で置かれていれば、端末が侵害されたときにそのまま使われます。
鍵の強度と、鍵の保管場所の安全性は別の話です。

2.3. ポートの違い

SSHはデフォルトでポート22を使います。

企業ネットワークや公共Wi-FiではSSHが遮断されている場合があります。
GitHubはSSHをポート443経由で通すオプションを提供していますが、~/.ssh/config に設定を追加する必要があり、環境によっては追加の確認が必要です6。

一方、HTTPSはポート443を使うため、ほぼすべてのファイアウォールを通過します。
CIツールや制限されたネットワーク環境では、HTTPSのほうが摩擦が少ないことがあります。

2.4. 鍵ペアの分離とトークンの有効期限

複数の端末でSSHを使う場合、端末ごとに鍵ペアを生成してGitHubに登録するか、既存の鍵をコピーするか選択が必要です。
鍵ごとにアクセスを管理できることは利点ですが、管理コストでもあります。

HTTPSはPATをどこでも使えるため端末間の設定は楽です。
その分、トークンの有効期限管理と失効の運用が求められます。

2.5. 二段階認証とパスフレーズ

HTTPSにPATを使う場合、GitHubのアカウントに2FAを設定することでフィッシングやパスワード漏洩への防御を強化できます。
SSH鍵は2FAとは別の認証経路にあるため、SSH鍵の管理そのものが認証の責任を持ちます。
鍵のパスフレーズ設定と、ssh-agentを通じたアクセス制御が推奨されるのはそのためです7。

3. 鍵の保管とアクセス制御が本題

「どの方式か」だけでなく「その鍵や認証情報がどこにあり、誰がどう触れられるか」も、セキュリティを左右します。

鍵の保管とアクセス制御 危険な状態 平文の秘密鍵 ~/.ssh/ に無防備に配置 ・パスフレーズなし ・端末の保護も薄い → 端末侵害で即座に悪用される 安全な状態 アクセス制御あり 認証情報マネージャー経由 ・パスフレーズ設定 ・ssh-agent でアクセス管理 → 利用のたびに意図を確認 「どの方式か」より「誰がどう触れられるか」 鍵の強度と保管場所の安全性は別の話

秘密鍵をパスフレーズなしで ~/.ssh/ に置き、端末の保護も薄い状態なら、方式の強さは空洞です。

たとえば、1Passwordのような認証情報マネージャーを経由してSSH鍵にアクセスする構成は、この発想を具体化したものです8。

鍵を平文でディスクに置かない、
鍵への到達に明確な関門を設ける、
利用のたびに生体認証で意図を確認する。

この積み重ねは、方式の比較だけでは得られない防御になります。

  1. GitHubは2021年8月13日にHTTPS経由のGit操作でのパスワード認証を廃止しました。以降、PATまたはSSH鍵が必須となっています。 – Git password authentication is shutting down – GitHub Changelog
  2. このチャレンジレスポンス方式では、サーバーはランダムな値を送り、クライアントがそれを秘密鍵で署名して返します。サーバーは登録済みの公開鍵で署名を検証するため、秘密鍵そのものがネットワークを通過する必要がありません。 – SSH Agent Explained – smallstep
  3. TLS 1.3はIETFによって2018年8月にRFC 8446として標準化されました。前方秘匿性とは、長期的な秘密鍵が将来漏洩しても過去のセッションが復号されない性質です。TLS 1.3はすべての接続でこれを強制します。 – RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3
  4. ed25519はEdwards-curve Digital Signature Algorithm（EdDSA）の一種で、Curve25519上で動作します。RSA 2048と同等以上の安全性を持ちながら鍵が短く、処理も高速です。GitHubはed25519またはRSA 4096の使用を推奨しています。 – SSH vs. HTTPS for Git – phoenixNAP
  5. GitHubは登録された公開鍵だけを保持します。公開鍵は数学的に秘密鍵を導出できない一方向性の鍵です。このため、GitHubのデータベースが侵害されてもユーザーの秘密鍵は影響を受けません。PATの場合、トークンのハッシュはサーバー側に保存されており、漏洩リスクの性質が異なります。 – SSH Protocol in Git and How it is different from HTTPS Protocol – ToolsQA
  6. GitHubの ssh.github.com というホスト名がポート443でSSH接続を受け付けます。~/.ssh/config に Host github.com、Hostname ssh.github.com、Port 443、User git を追記することで透過的に切り替えられます。 – Using SSH over the HTTPS port – GitHub Docs
  7. ssh-agentはSSH秘密鍵をメモリ上に保持し、接続のたびにパスフレーズを入力する手間を省くプログラムです。鍵をディスクに平文で置かずに済み、署名処理をエージェント内で完結させるためほかのプロセスが秘密鍵を直接読めません。 – SSH Agent Explained – smallstep
  8. 1Password SSH Agentは、秘密鍵を1Passwordの外に出さずにSSH認証を行います。接続リクエストのたびにTouch IDやWindows Helloなどで承認を求めるため、ほかのプロセスが秘密鍵を取り出せません。 – 1Password SSH agent – 1Password Developer