GitのHTTPS接続とSSH接続、「なんとなくSSHの方が安全」って本当に正しい？

March 11, 2026March 29, 2026

「SSHの方が安全でしょ」は本当か

Git リポジトリへの接続方式を選ぶとき、「なんとなく SSH の方が安全そう」と感じていませんか？

X（旧 Twitter）でもこんな議論が話題になっていました。「HTTPS 接続より SSH の方がよっぽど安全」という意見に対し、「OpenSSH に対する過大評価、GnuTLS に対する過小評価では？」という指摘が飛び交い、8万インプレッションを超えました。

実際のところ、HTTPS と SSH、どちらが安全なのか。そして「なんとなく SSH」という選択は正しいのか。この記事では両者の仕組みと実際のリスクを整理し、状況に応じた選び方を解説します。

そもそもHTTPSとSSH、何が違うのか

まず両者の基本的な違いを整理します。

通信の仕組みの違い

HTTPS は TLS（Transport Layer Security）で通信を暗号化します。ブラウザでウェブサイトを閲覧するときと同じプロトコルで、ポート 443 を使います。

SSH（Secure Shell）は専用のプロトコルで通信を暗号化します。ポート 22 を使い、もともとはリモートサーバーへのログインに使われてきた技術です。

項目	HTTPS	SSH
プロトコル	TLS（Transport Layer Security）	SSH（Secure Shell）
ポート	443	22
認証方式	ユーザー名 + PAT（Personal Access Token）	公開鍵・秘密鍵ペア
設定の手軽さ	すぐ使える	鍵の生成・登録が必要
ファイアウォール	通りやすい（443番は基本開放）	22番が塞がれていることがある

認証方式の違い

HTTPS では、GitHub の場合はパスワードの代わりに PAT（Personal Access Token） を使います。このトークンをクレデンシャルマネージャーに保存しておくことで、毎回入力せずに済みます。

# HTTPS でクローン
git clone https://github.com/username/repo.git
# → ユーザー名と PAT を求められる（初回のみ）

SSH では、あらかじめ生成した 公開鍵を GitHub に登録しておき、手元の秘密鍵で認証します。パスワードもトークンも不要です。

# SSH でクローン
git clone git@github.com:username/repo.git
# → 秘密鍵で自動認証（パスフレーズ設定時のみ入力）

HTTPSが「危ない」と言われる理由と実態

「HTTPS は危ない」という意見の背景には、TLS 実装の差があります。Linux 環境では TLS の実装として OpenSSL と GnuTLS が代表的ですが、過去に GnuTLS でいくつかの脆弱性が発見されたことがあり、「OpenSSL より GnuTLS は信頼性が低い」という印象を持っている人がいます。

しかし、この議論には注意が必要です。

GnuTLS も現在は活発にメンテナンスされており、重大な既知脆弱性はほぼ修正済み
macOS では Secure Transport、Windows では SChannel が使われており、GnuTLS の話はLinux限定
そもそも TLS 自体の強度は非常に高く、通信経路上での盗聴リスクは現実的にはほぼゼロ
実際のリスクは TLS の実装差よりも、トークンの管理方法にある

つまり「HTTPS は GnuTLS が弱いから危ない」というのは、現状では過剰な懸念と言えます。

SSHが「安全」と言われる理由と落とし穴

ed25519の強度

SSH 鍵の種類には RSA、ECDSA、ed25519 などがあります。現在推奨されているのは ed25519 で、楕円曲線暗号をベースにした短くて強い鍵です。

# ed25519 鍵の生成（推奨）
ssh-keygen -t ed25519 -C "your_email@example.com"

# 古い RSA 鍵（非推奨）
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

ed25519 は現時点では量子コンピュータを除いた通常の攻撃に対して非常に強固であり、鍵そのものが突破される可能性は現実的にはほぼありません。

「鍵を抜かれたら終わり」問題

SSH の強度は鍵そのものよりも、秘密鍵をどこに・どう保管するかに依存します。

X の議論でも指摘されていたように、SSH の本質的なリスクは「鍵を抜かれたら終わり」という点です。~/.ssh/id_ed25519 という秘密鍵ファイルが漏洩すれば、それを持つ人間は誰でもあなたとして認証できてしまいます。

マルウェアに感染して ~/.ssh/ ディレクトリごと盗まれる
パスフレーズなしの秘密鍵ファイルを誤ってリポジトリにコミットする
共用 PC に秘密鍵を置いたまま別のユーザーに使われる

これらのリスクは「鍵の暗号強度」とは無関係な、運用上のリスクです。SSH が安全かどうかは、鍵の管理方法に大きく左右されます。

1Passwordなどのパスワードマネージャーで鍵を守る

X の議論で「1Password 経由で生体認証させて SSH 鍵へのアクセスをさせている」という実践例が紹介されていました。これは SSH の運用リスクを大幅に下げる優れた方法です。

1Password の SSH エージェント機能を使うと、秘密鍵ファイルをディスク上に置かずに済みます。秘密鍵は 1Password の保管庫に暗号化して保存され、SSH 操作のたびに Touch ID や Face ID による生体認証が求められます。

1Password SSH エージェントの設定手順（macOS）

1Password アプリで「開発者ツール」→「SSH エージェントを使用」を有効化
1Password に SSH 鍵を新規作成または既存の鍵をインポート
~/.ssh/config に以下を追記

# ~/.ssh/config
Host *
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

これで git push などの SSH 操作時に Touch ID が求められるようになり、秘密鍵ファイルが漏洩してもそれだけでは認証できない状態になります。

1Password を使わない場合でも、秘密鍵には必ずパスフレーズを設定しておきましょう。

# パスフレーズ付きで鍵を生成
ssh-keygen -t ed25519 -C "your_email@example.com"
# → Enter passphrase: の入力を求められる（空欄にしない！）

# ssh-agent を使ってパスフレーズの毎回入力を省略
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

結局どっちを選ぶべきか：状況別の使い分け

「HTTPS と SSH、どちらが安全か」という問いに対する正直な答えは、正しく設定・運用すればどちらも十分に安全です。重要なのは接続方式よりも、認証情報（トークンや秘密鍵）をどう管理するかです。

とはいえ、状況によって向き不向きがあります。

状況	おすすめ	理由
とにかくすぐ使いたい	HTTPS	鍵の設定不要、すぐ始められる
社内・企業ネットワーク	HTTPS	22番ポートが塞がれていることが多い
複数リポジトリを頻繁に操作	SSH	トークン管理が不要、操作が快適
CI/CD・自動化スクリプト	SSH（デプロイキー）	リポジトリ単位で権限を絞れる
セキュリティを最大化したい	SSH + 1Password	生体認証で秘密鍵を保護できる