GitHub の SSH 設定入門：鍵の作成・登録から接続確認、つながらないときまで（HTTPS とどっち？）

GitHub に SSH でつなぐには、自分のパソコンで SSH キー（秘密鍵と公開鍵の 2 つで 1 組の鍵）を作り、公開鍵のほうを GitHub のアカウントに追加します。つながったあとは、接続のたびにユーザー名と personal access token（HTTPS でパスワードの代わりに入れる文字列）を入れなくて済みます。この記事は、GitHub を使い始めた初心者向けに、SSH と HTTPS の違い、Mac と Windows それぞれの手順、つながらないときの確かめ方を、2026年10月時点の GitHub の公式文書（英語版）をもとにまとめたものです。

GitHub そのものがまだ初めての方は、【プログラミング完全入門】必ず使う最低限必要なツール紹介！の「GitHubとは？」を先に読んでおくと、話がつながりやすくなります。

この記事でわかること

SSH と HTTPS の違い（設定の手間・つなぐたびに入れるもの・ファイアウォールとの相性）と、公式が「推奨」を付けている所
鍵を作って ssh-agent に登録するまでの手順（Mac と Windows）と、公開鍵を GitHub に追加する方法
ssh -T [email protected] でつながったかを確かめる方法
Permission denied (publickey) が出たときの確かめ方と、22 番ポートが使えないときの 443 番の使い方
HTTPS でつないでいるリポジトリを SSH に切り替える git remote set-url

SSH と HTTPS の違いは？どっちでつなぐ？
SSH キーを作って ssh-agent に登録するには？（Mac・Windows）
公開鍵を GitHub のアカウントに追加するには？
SSH でつながったか確かめるには？
1. 初めてつなぐときの警告と、指紋の確かめ方
2. つながったときの表示
つながらないときは？（Permission denied (publickey)）
HTTPS のリポジトリを SSH に切り替えるには？
よくある質問
まとめ
参考資料

SSH と HTTPS の違いは？どっちでつなぐ？

GitHub のリポジトリに push できる URL は、HTTPS と SSH の 2 種類だけです。HTTPS の URL は https://github.com/user/repo.git、SSH の URL は [email protected]:user/repo.git の形をしています。

リモート URL は、Git が「コードが保存されている場所」を指すときの呼び方です。Git はリモート URL に名前を付けて覚えていて、既定の名前はふつう origin です。コマンドラインからは HTTPS と SSH のどちらでもつなげますが、認証のしかたが違います。どちらになるかは、リポジトリを clone（手元に写すこと）するときに、どちらの URL を選んだかで決まります。

公式の説明にある違い

GitHub の公式文書（リモートリポジトリについて、GitHub への認証について、Git が毎回資格情報を聞く理由を説明したページ）に書かれている違いを、表にまとめます。

観点	HTTPS	SSH
設定の手間	SSH より簡単	自分のコンピューターで SSH キーの組を作り、公開鍵を GitHub のアカウントに追加する
ファイアウォール・プロキシ	内側でも使え、厳しいものでもふつうは通る	接続を拒まれることがある
つなぐたびに入れるもの	GitHub の資格情報（ユーザー名と、パスワードの欄に入れる personal access token）。GitHub CLI や Git Credential Manager で覚えさせられる	ユーザー名と personal access token は要らない。鍵のパスフレーズを聞かれるが、鍵を ssh-agent に保存していれば聞かれない
使えるリポジトリ	公開・非公開にかかわらずすべて	すべて

HTTPS でパスワードを聞かれたら、GitHub のパスワードではなく personal access token を入れます。GitHub.com で Git の操作にアカウントのパスワードを受け付けなくなったのは、2021年8月13日 09:00（PST）からです（GitHub の変更履歴）。

HTTPS で clone しているときに、資格情報を覚えさせる方法として、GitHub CLI か Git Credential Manager（GCM）を使うよう公式は勧めています（"we recommend"。公式のページ）。Windows では、Git for Windows に GCM が入っています。これは HTTPS を使う場合の道具の話で、SSH と HTTPS のどちらを選ぶかの話ではありません。

公式は SSH と HTTPS のどちらを「推奨」している？

Git から GitHub につなぐときは、HTTPS か SSH のどちらかで認証する、と公式は書いています（どちらでもつなげます）。そのうえで、この記事で見た公式のページでは、「推奨（recommended）」が付いているのは HTTPS の側でした（2026年10月時点）。

「推奨」が付いているのは、次の 3 か所です。

「Git のセットアップ」のページ: HTTPS と SSH を並べて説明していて、見出しが「HTTPS で接続 (推奨)」と「SSH で接続」です（英語版は "Connecting over HTTPS (recommended)"）。

「リモートリポジトリを管理する」のページ: リモートの名前の変更と削除の例の前置きに、"These examples assume you're cloning using HTTPS, which is recommended." とあります。「これらの例は、HTTPS で複製（clone）することを前提にしています（推奨）」という意味です。
GitHub のブログ（2020年12月15日）: パスワード認証をやめる話の中で、"you must begin using a personal access token over HTTPS (recommended) or SSH key by August 13, 2021, to avoid disruption." と書きました。「2021年8月13日までに、HTTPS で personal access token を使う（推奨）か、SSH キーを使い始める必要がある。支障を避けるため」という意味です。

どれも HTTPS の側です。一方、「リモートリポジトリについて」と「GitHub への認証について」のコマンドラインの節は、2 つの違いを説明していて、どちらかを推奨する文はありません（「GitHub への認証について」にある recommend は、2 要素認証、パスワードの管理、API の認証についての文です）。迷ったら公式が推奨を付けている HTTPS、鍵の準備をしてもユーザー名と personal access token を毎回入れずにつなぎたいなら SSH、と上の表の違いで選べます。この記事は、SSH を選んだときの手順です。

SSH でつなぐ流れ

SSH を選ぶ場合の手順は、次の流れです。

手元に鍵がすでにあるか確かめる
鍵（秘密鍵と公開鍵の組）を作る
鍵を ssh-agent に登録する（Mac と Windows で手順が違います）
公開鍵を GitHub のアカウントに追加する
ssh -T [email protected] で、つながるか確かめる
すでに HTTPS で clone してあるリポジトリは、git remote set-url で SSH の URL に切り替える

SSH キーを作って ssh-agent に登録するには？（Mac・Windows）

SSH キーは、秘密鍵と公開鍵の 2 つのファイルで 1 組です。公開鍵は、秘密鍵と同じ名前の最後に .pub が付いたファイルです。SSH でつなぐときは、手元の秘密鍵で認証し、GitHub には公開鍵のほうを追加します。この節の手順は、公式の新しい SSH キーを生成して ssh-agent に追加するにもとづきます。

SSH キーを使っていると、誰かがあなたのコンピューターに入り込んだとき、その鍵を使うすべてのシステムに入れてしまいます。鍵に「パスフレーズ」（鍵を使うたびに入れる合言葉）を付けると、守りを一段足せます。

パスフレーズを付けた鍵は、使うたびにパスフレーズを入れる必要があります。毎回入れたくないときは、鍵を ssh-agent に入れておきます。ssh-agent は、鍵を管理して、パスフレーズを覚えてくれるプログラムです。公式の文書の Git for Windows で ssh-agent を自動で起動する節によると、ssh-agent のプロセスは、ログアウトする、電源を切る、プロセスを止める、のどれかをするまで動き続けます。同じ節は、しばらくしたら鍵を忘れさせたいときは ssh-add -t <seconds> を使う、と書いています（<seconds> には秒数を入れます）。

鍵がすでにあるか確かめる

新しい鍵を作る前に、手元に鍵があるか確かめます（公式のChecking for existing SSH keys）。Mac は「ターミナル」、Windows は「Git Bash」を開いて、次のコマンドを流します。ターミナルは、コマンドを文字で打つための画面です。Git Bash は、Windows で Git を使うときのターミナルです。

ls -al ~/.ssh

~/.ssh は、ホームフォルダの中にある隠しフォルダ .ssh のことです。GitHub が対応している公開鍵の既定のファイル名は、id_rsa.pub・id_ecdsa.pub・id_ed25519.pub のどれかです。

~/.ssh が無いというエラーが出たら、既定の場所に鍵の組はありません。次の手順で新しく作ります。
使いたい鍵の組（たとえば id_rsa.pub と id_rsa）がすでにあれば、新しく作らずに、その鍵を ssh-agent に追加すれば足ります。
鍵の組が無いとき、またはあるものを使いたくないときは、新しく作ります。

鍵を作る（共通）

Mac は「ターミナル」、Windows は「Git Bash」で、次のコマンドを流します。例のメールアドレスは、自分の GitHub のメールアドレスに置き換えます。

ssh-keygen -t ed25519 -C "[email protected]"

-t ed25519 は、鍵の種類（方式）に Ed25519 を選ぶ指定です。-C で渡したメールアドレスは、鍵のラベル（コメント）になります。

Ed25519 に対応していない古いシステムの場合は、次のコマンドを使います。

ssh-keygen -t rsa -b 4096 -C "[email protected]"

コマンドを流すと、まず保存先が聞かれます。Enter キーを押すと、既定の場所に保存されます。公式の見本では、既定の保存先は Mac が /Users/YOU/.ssh/id_ALGORITHM、Windows（Git Bash）が /c/Users/YOU/.ssh/id_ALGORITHM です。YOU はパソコンのユーザー名（ホームフォルダの名前）で、ALGORITHM の部分は鍵の種類の名前です（Ed25519 なら id_ed25519）。問いの文面は、OpenSSH_9.6p1（macOS）の ssh-keygen では Enter file in which to save the key です。公式の Mac の見本は Enter a file in which to save the key で、1 語だけ違います。

以前に鍵を作っていると、別の鍵を書き換えてよいかを聞かれることがあります（OpenSSH_9.6p1 の ssh-keygen には、already exists. と Overwrite (y/n)? という文面があります）。OpenSSH_9.6p1（macOS）では、n と答えると何も変えずに終わり、y と答えると前の鍵は新しい鍵に置き換わって、前の鍵は残りませんでした。前の鍵を GitHub などに登録して使っているなら、y と答えないでください。そのときは、名前を変えた鍵を作るよう公式は勧めています。保存先の問いに既定の場所を打ち、id_ALGORITHM の部分を自分で付ける鍵の名前に置き換えます。名前を変えた鍵を作ったら、このあと出てくる ~/.ssh/config の IdentityFile、ssh-add に渡す道筋、ssh -i の指定も、その名前に合わせます。

次に、パスフレーズを 2 回入れます。問いの文面は Enter passphrase (empty for no passphrase): と Enter same passphrase again: です。公式の手順は、安全なパスフレーズを入れるものです（"At the prompt, type a secure passphrase."）。パスフレーズは空にもできます。空は「パスフレーズなし」の意味です。

鍵ができると、鍵の指紋（SHA256: で始まる文字列。鍵を見分けるためのものです）と、randomart（記号で描いた絵）が表示されます。次は、OpenSSH_9.6p1（macOS）で鍵を作ったときの出力の一部です。この鍵は説明用に作って消したもので、誰の鍵でもありません。

The key fingerprint is:
SHA256:2aYlm1P64OupH18NXmGBrpKLJsQB+hLc3AvxC86UqrE [email protected]
The key's randomart image is:
+--[ED25519 256]--+
|             ..  |
|  ..        .  . |
|..o.=      .  o  |
|o. B.o   o  .. . |
| o=.o.o S.=.. .  |
|o..ooo  oX.. +   |
|.+ .   .Oo  o .  |
|E   . o..B .     |
|     o.+*.o      |
+----[SHA256]-----+

作られるファイルは 2 つです（macOS 14.4.1・OpenSSH_9.6p1 で調べた結果）。秘密鍵の権限は -rw-------（自分だけが読める）、公開鍵は -rw-r--r-- です。公開鍵（.pub）の中身は、ssh-ed25519 で始まり、英数字の長い文字列、最後に -C で渡したラベル（この確認では [email protected]）が続く 1 行です。秘密鍵の 1 行目は -----BEGIN OPENSSH PRIVATE KEY----- です。GitHub に追加するのは、.pub が付いた公開鍵のほうだけです。

ssh-agent に登録する（Mac）

Mac では、macOS に最初から入っている ssh-add を使います。MacPorts や Homebrew など、あとから入れたアプリのものは使いません。

手順 1: ssh-agent をバックグラウンドで起動する

eval "$(ssh-agent -s)"

次のように、プロセス番号が表示されます（公式の文書の例）。

Agent pid 59566

環境によっては、別のコマンドが必要です。公式の文書には、exec ssh-agent bash や exec ssh-agent zsh を使う例も書かれています。

eval で包んでいるのは、ssh-agent -s が、環境変数を設定するシェルのコマンドを出力するからです。OpenSSH_9.6p1（macOS）では、SSH_AUTH_SOCK=…; export SSH_AUTH_SOCK;、SSH_AGENT_PID=…; export SSH_AGENT_PID;、echo Agent pid …; の 3 行が出力されます（… の部分は環境ごとに違います）。eval は、渡されたものをシェルへの入力として読んで実行します。そのため eval "$(ssh-agent -s)" で、この 3 行が実行されます。

手順 2: ~/.ssh/config を直す

macOS Sierra 10.12.2 以降では、~/.ssh/config ファイルを直して、鍵を自動で ssh-agent に読み込み、パスフレーズをキーチェーンに保存するようにする必要があります。キーチェーンは、macOS がパスワードなどを保存しておく仕組みです。まず、config ファイルがあるか確かめます。

open ~/.ssh/config

ファイルが無いと、The file /Users/YOU/.ssh/config does not exist. と出ます（公式の文書の例）。そのときは、次のコマンドで作ります。

touch ~/.ssh/config

ファイルを開いて、次の 4 行を書きます。鍵の名前や場所が上の例と違うときは、IdentityFile の行を自分の設定に合わせます。

Host github.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

AddKeysToAgent yes: ファイルから読んだ鍵を、パスフレーズと一緒に、動いている ssh-agent に自動で足します（既定は no）。
UseKeychain yes: macOS だけの設定です。鍵を使うときにキーチェーンからパスフレーズを探し、パスフレーズが入力されたらキーチェーンに保存します（既定は no）。
IdentityFile: 使う秘密鍵のファイルです。

パスフレーズを付けなかったときは、UseKeychain の行を省きます。

Bad configuration option: usekeychain というエラーが出たら、IgnoreUnknown UseKeychain の行を足す、と公式の英語版は書いています。見本は Host github.com の下に 1 行足す形ですが、文章のほうは Host *.github.com の節に足すと書かれていて、見本と食い違っています（2026年10月時点）。なお、man ssh_config（macOS 14.4.1）は、IgnoreUnknown は設定ファイルの前のほうに書くよう勧めています。それより前に出てくる知らない項目には効かないためです。

すでに ~/.ssh/config に Host github.com の設定がある場合は、次の点に気をつけます。ssh のマニュアル（macOS 14.4.1 の man ssh_config）では、設定の同じ項目は、ふつう最初に得た値が使われます。ただし IdentityFile は例外で、複数書くと足し合わされ、書いた鍵が順に試されます。たとえば Host github.com を 2 か所に書き、それぞれに別の IdentityFile を書くと、両方の鍵が順に試されます。Host github.com を 2 つ書いたときの扱いは、この記事で見た GitHub の公式のページには書かれていませんでした（2026年10月時点）。複数の GitHub アカウントを使い分けるときの設定は、GitHubで複数アカウントを使い分け方法解説（Sourcetreeも可）で説明しています。

手順 3: 秘密鍵を ssh-agent に入れる

秘密鍵を ssh-agent に入れ、パスフレーズをキーチェーンに保存します。

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

鍵の名前が違うときは、id_ed25519 の部分を置き換えます。パスフレーズを付けなかったときは、--apple-use-keychain を付けずに流します。

--apple-use-keychain は、Apple 標準の ssh-add にあるオプションで、鍵を追加するときにパスフレーズをキーチェーンにも保存します。--apple-load-keychain は、キーチェーンに保存したパスフレーズを使って鍵を agent に追加するオプションです（macOS 14.4.1 の man ssh-add）。Monterey（macOS 12.0）より前の macOS では、--apple-use-keychain は -K、--apple-load-keychain は -A という書き方でした。

注意が必要なのは、公式の日本語版のエラーのページ（ssh-add: illegal option -- apple-use-keychain）です。この点が英語版と逆に訳されています（2026年10月時点）。英語版は「Monterey より前の macOS では、--apple-use-keychain の代わりに -K を使う」という意味で、この記事は英語版に従っています。

Apple 標準でない ssh-add を使っていると、ssh-add: illegal option -- apple-use-keychain というエラーになります。そのときは、Apple 版の道筋を指定して流します。

/usr/bin/ssh-add --apple-use-keychain ~/.ssh/id_ed25519

どの ssh-add を使っているかの見分け方は、この記事で見た公式のページには書かれていませんでした（2026年10月時点）。この記事で確かめた Mac（macOS 14.4.1）では、which ssh-add の結果は /usr/bin/ssh-add でした。

それでもパスフレーズを聞かれ続けるときは、手順 3 のコマンドを ~/.zshrc（bash なら ~/.bashrc）に足す必要があるかもしれない、と公式は書いています。

ssh-agent に登録する（Windows）

Windows では、使う画面が混ざります。公式の手順では、鍵を作るのは Git Bash（前の「鍵を作る」）で、ssh-agent を動かす準備は、管理者として開いた PowerShell で行います。PowerShell は、Windows でコマンドを打つ画面の 1 つです。道筋の書き方も手順ごとに違い、公式の見本は、鍵を作るときの Git Bash が /c/Users/YOU/.ssh/…、ssh-add の手順が c:/Users/YOU/.ssh/… です。

GitHub Desktop をすでに入れているなら、それでリポジトリを clone すれば、SSH キーを扱わずに済みます。また、Windows 10・11 に OpenSSH のクライアントが最初から入っているかどうかは、Microsoft の文書には書かれていません（2026年10月時点）。その文書には、入っているかの確かめ方と、入れ方が書かれています。

手順 1: 管理者の PowerShell で ssh-agent を動かす

管理者として開いた新しい PowerShell で、ssh-agent が動いているようにします。公式は、「SSH キーのパスフレーズを扱う」のページにある ssh-agent の自動起動の手順を使うか、次のように手で起動する方法を示しています。

Get-Service -Name ssh-agent | Set-Service -StartupType Manual
Start-Service ssh-agent

Microsoft の文書では、Windows の ssh-agent サービスは既定で無効なので、管理者として Get-Service ssh-agent | Set-Service -StartupType Automatic を流し、自動で起動するように設定する、と書かれています。GitHub の例の Manual は手で起動する設定で、Microsoft の例の Automatic は自動で起動する設定です。

手順 2: 管理者でないターミナルで鍵を登録する

そのあと、管理者権限を持たない（昇格していない）ターミナルで、秘密鍵を ssh-agent に追加します。鍵の名前が違うときは、id_ed25519 の部分を置き換えます。

ssh-add c:/Users/YOU/.ssh/id_ed25519

パスフレーズを聞かれ続けるとき（Git 同梱の ssh とのぶつかり）

Windows には、Windows 標準の OpenSSH と、Git for Windows に入っている OpenSSH（MSYS2/Bash がもと）が、並んで入ることがあります。PowerShell で Windows の ssh-agent にパスフレーズを保存しても、Git が同梱の ssh.exe（MSYS2 のもの）を使うと、Windows の ssh-agent サービスと話せません。その結果、git push などでパスフレーズを聞かれることがあります。

直すには、Git が Windows 標準の SSH を使うように指定します。

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

もう 1 つの方法は、Git for Windows を入れ直し、インストールの途中で Use external OpenSSH を選ぶことです。これは公式の英語版の表記で、日本語版では「[外部 OpenSSH を使用]」と書かれています。インストーラの画面でどう表示されるかは、確認できていません。

Git Bash を開いたときに ssh-agent を自動で起動する公式のスクリプトもあります（Git shell の ~/.profile か ~/.bashrc に貼ります）。スクリプトは、SSH キーのパスフレーズを扱うのページにあります。

公開鍵を GitHub のアカウントに追加するには？

SSH キーを作ったら、GitHub.com に公開鍵を追加します。これで、あなたのアカウントで SSH が使えるようになります。手順は、公式のGitHub アカウントへの新しい SSH キーの追加にもとづきます。

手順 1: 公開鍵をクリップボードに写す

写すのは、.pub が付いた公開鍵のファイルです。ファイル名が例と違うときは、自分の鍵のファイル名に置き換えます。写すときは、改行や空白を足さないようにします。

Mac のコマンドです。

pbcopy < ~/.ssh/id_ed25519.pub

Windows のコマンドです。

clip < ~/.ssh/id_ed25519.pub

新しい Windows の Windows Terminal など、PowerShell を使う画面では、< が使えず ParseError になることがあります。エラーの文面は The '<' operator is reserved for future use. です。そのときは、次のコマンドを使います。

cat ~/.ssh/id_ed25519.pub | clip

pbcopy や clip が動かないときは、隠しフォルダ .ssh の中の公開鍵のファイルをテキストエディタで開いて、中身を写してもかまいません。WSL（Windows Subsystem for Linux）では clip.exe が使えます。

手順 2: GitHub の画面で追加する

GitHub のどのページでも、右上のプロフィール写真をクリックし、Settings をクリックします。
サイドバーの "Access" セクションにある SSH and GPG keys をクリックします。
New SSH key または Add SSH key をクリックします。
"Title" 欄に、その鍵を見分けやすいラベルを入れます。たとえば、個人用のノートパソコンの鍵なら "Personal laptop" です。
鍵の種類で、認証（authentication）か署名（signing）のどちらかを選びます。SSH でつなぐために使う鍵は、認証のほうです。
"Key" 欄に、写した公開鍵を貼り付けます。
Add SSH key をクリックします。
求められたら、GitHub でアカウントへのアクセスを確認します。

項目名は公式文書の表記です。GitHub の画面そのものは、この記事では確認していません。同じ鍵を認証と署名の両方に使うなら、2 回アップロードする必要があります。

GitHub CLI（gh）を使っているなら、gh ssh-key add ~/.ssh/id_ed25519.pub のように、公開鍵のファイル（.pub の付いたほう）を渡しても登録できます（公式は "specifying your public key" と書いています。gh のマニュアル）。秘密鍵（.pub の付かないファイル）は渡しません。登録の前に、gh auth login で GitHub CLI に認証しておきます。--type を付けなければ、認証用の鍵として登録されます（既定は authentication）。題は -t（--title）で付けます。

ほかのアカウントやリポジトリにすでに追加した鍵を、もう一度追加しようとすると、Key already in use というエラーになります（公式のページ）。2 つ目の GitHub アカウントには、別の鍵が必要になります。複数のアカウントの使い分けは、GitHubで複数アカウントを使い分け方法解説（Sourcetreeも可）で説明しています。

公開鍵を追加したら、手元のリポジトリを SSH を使うように設定し直せます。やり方は、あとの「HTTPS のリポジトリを SSH に切り替えるには？」で説明します。

SSH でつながったか確かめるには？

次のコマンドで、GitHub に SSH でつながるか確かめます（公式のTesting your SSH connection）。Mac は「ターミナル」、Windows は「Git Bash」で流します。

ssh -T [email protected]

[email protected] は、git というユーザーで github.com につなぐ、という指定です。GitHub への接続は、リモート URL の場合も含めて、git ユーザーで行う必要があります。-T は、疑似端末（相手のコンピューターでコマンドを打つための画面）を割り当てない、という指定です（ssh のマニュアルより）。

このとき、鍵を作ったときに決めた SSH キーのパスフレーズで認証することになります。

初めてつなぐときの警告と、指紋の確かめ方

初めてつなぐときは、次のような警告が出ることがあります（公式の文書の例）。

The authenticity of host 'github.com (IP ADDRESS)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
Are you sure you want to continue connecting (yes/no)?

表示された指紋（fingerprint。鍵を見分けるための文字列）が、GitHub の公開鍵の指紋と合うかを確かめます。合っていれば yes と打ちます。GitHub の公開鍵の指紋（SHA256）は、次のとおりです。

鍵の種類	指紋（SHA256）
RSA	`SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s`
ECDSA	`SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM`
Ed25519	`SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU`

この 3 つの値は、公式のGitHub's SSH key fingerprintsのページに載っています。そのページの known_hosts の行から計算した値、GitHub のメタ情報 API（api.github.com/meta）の値と、3 通りで一致しました（2026年10月3日時点）。

問いの終わりの形は、公式の文書の例では、(yes/no)? で終わるものと (yes/no/[fingerprint])? で終わるものがあります。OpenSSH 8.0（2019年4月17日公開）から、新しいホスト鍵を記録するか聞かれたときに、yes の代わりに指紋を貼り付けてもよくなりました。OpenSSH_9.6p1 の ssh には、(yes/no)? と (yes/no/[fingerprint])? の両方の文面があります。どちらの形が出るかは、確かめていません。

つながったときの表示

つながると、次のようなメッセージが出ます（公式の文書の例）。USERNAME の部分に、自分のユーザー名が入っているかを確かめます。

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

メッセージの後半の「GitHub は shell へのアクセス（相手のコンピューターでコマンドを打つこと）を提供しない」は、エラーではなく、つながったことを知らせる文の一部です。このコマンドは終了コード 1 で終わるはず、と公式の英語版は書いています（"should exit with code 1"）。終了コードは、この記事では確かめていません。

permission denied と出たときは、次の「つながらないときは？」を見てください。

つながらないときは？（Permission denied (publickey)）

ssh -T [email protected] などで、次のように出てつながらないことがあります。

[email protected]: Permission denied (publickey).

Permission denied は、サーバー（GitHub）が接続を断った、という意味です。理由はいくつかありえます。公式の文書の見本は Permission denied (publickey). だけですが、画面には、その前に「ユーザー名@ホスト名:」が付いた、上の形で出ます（OpenSSH_9.6p1 の ssh の文面は %s@%s: Permission denied (%s). です）。

公式のエラー: アクセス許可の却下 (公開キー)が示している確認の順に、見ていきます。

確認 1: Git で `sudo` を使っていないか

Git で sudo や、管理者権限を使うべきではない、と公式は書いています。sudo を付けずに作った鍵は、sudo git push のように sudo を付けて流すと、使われません。

確認 2: 正しいサーバーにつないでいるか

次のコマンドで、つなぐ途中の経過を表示します。-v は、途中経過のデバッグ用のメッセージを表示する指定で、重ねると詳しくなります（最大 3 つ）。

ssh -vT [email protected]

出力の中に、22 番ポートにつないでいることを示す、次のような行があるか見ます（公式の文書の例）。

debug1: Connecting to github.com port 22.

HTTPS 経由の SSH（あとで説明する 443 番）に設定を変えていなければ、接続は 22 番ポートで行われます。

確認 3: `git` ユーザーでつないでいるか

GitHub への接続は、リモート URL の場合も含めて、git ユーザーで行う必要があります。GitHub のユーザー名でつなぐと、失敗します。たとえば ssh -T [email protected] は、Permission denied (publickey). になります。リモート URL に自分のユーザー名を使っているなら、git ユーザーの URL（[email protected]:OWNER/REPOSITORY.git の形）に変えます。

確認 4: 鍵が ssh-agent に読み込まれているか

次のコマンドで、ssh-agent に入っている鍵の指紋を表示します。

ssh-add -l -E sha256

公式は、長い英数字（指紋）が出るはずで、何も出なければ、新しい鍵を作って GitHub に関連付ける必要がある、と書いています。OpenSSH_9.6p1（macOS）では、何も出ないのではなく、状況に応じて次の文面が出ます。

ssh-agent に鍵が 1 つも入っていないとき: The agent has no identities.（終了コード 1）
ssh-agent の場所がわからない（SSH_AUTH_SOCK が無い）とき: Could not open a connection to your authentication agent.（終了コード 2）
SSH_AUTH_SOCK が、存在しないソケットを指しているとき: Error connecting to agent: No such file or directory（終了コード 2）

鍵がすでにあるなら、前の「ssh-agent に登録する」の手順で ssh-agent に入れます。鍵が無いなら、公式の書き方のとおり、新しい鍵を作って GitHub に関連付けます。

ssh は、既定では ~/.ssh/id_rsa・id_ecdsa・id_ecdsa_sk・id_ed25519・id_ed25519_sk・id_dsa という名前の秘密鍵を探します。これとは別に、ssh-agent に入っている鍵も使われます（設定で IdentitiesOnly を付けていなければ）。

Windows で ssh-agent を動かすには、Git Bash なら eval "$(ssh-agent -s)"、Git for Windows など別のターミナルなら eval $(ssh-agent -s) を使います。ssh-agent がすでにバックグラウンドのシステムサービスとして動いていると、これらのコマンドは失敗することがあります。

確認 5: `-v` の出力で、鍵のファイルが見つかっているか読む

鍵の名前が既定と違うときは、-i で秘密鍵を指定して確かめます。-i は、使う秘密鍵のファイルを選ぶ指定です。

ssh -i ~/.ssh/KEY-FILE -vT [email protected]

出力は、次のように読みます。

identity file … の行の終わりの「-1」（type -1）は、使うファイルが見つからなかった印です。
Trying private key の行が出るのも、ファイルが見つからなかったことを示します。
ファイルがあれば、それらの行は「1」になり、Offering public key の行が出ます。

確認 6: 公開鍵が GitHub のアカウントに付いているか

確認 4 と同じ ssh-add -l -E sha256 で、自分の鍵の指紋をメモします。次に、GitHub の Settings の SSH and GPG keys にある一覧と比べます。一覧に自分の鍵が無ければ、公開鍵を GitHub に追加します（前の「公開鍵を GitHub のアカウントに追加するには？」）。

GitHub は、1 年間使われていない SSH キーを、安全のために自動で削除します。一覧に自分の鍵が無いときは、この削除のこともあります。詳しくは、あとの「よくある質問」で説明します。

一覧に覚えのない SSH キーがあれば、すぐに削除して、GitHub Support に連絡します。

22 番ポートがふさがれているとき（443 番）

ファイアウォールやプロキシが、SSH の接続を拒むことがあります。22 番ポートで SSH がつながらないときは、HTTPS のポート（443 番）で SSH を使える場合があります。次のコマンドで試します。

ssh -T -p 443 [email protected]

-p は、つなぐ先のポートの指定です。443 番のホスト名は ssh.github.com で、github.com ではありません。

注意が必要なのは、公式の日本語版のこのページ（Using SSH over the HTTPS port）です。ホスト名の注意が、英語版と逆に訳されています（2026年10月時点）。英語版は "The hostname for port 443 is ssh.github.com, not github.com." で、「443 番のホスト名は ssh.github.com であり、github.com ではない」という意味です。この記事は英語版に従っています。

443 番で clone するときは、次の形の URL を使います。

git clone ssh://[email protected]:443/YOUR-USERNAME/YOUR-REPOSITORY.git

いつも 443 番を使うなら、~/.ssh/config に次の 4 行を足します。

Host github.com
  Hostname ssh.github.com
  Port 443
  User git

すでに ~/.ssh/config に Host github.com の設定がある場合は、Mac の手順 2 の最後にある、同じ項目を複数書いたときの注意も見てください。

切り替えたあと、初めてつなぐと、known_hosts（つないだことのある相手を記録するファイル）についての警告が出ることがあります。表示された指紋が、前の表にある GitHub の公開鍵の指紋と合っていれば、yes と答えてかまいません。

HTTPS のリポジトリを SSH に切り替えるには？

すでに HTTPS の URL で clone したリポジトリは、リモートの URL を SSH の URL に変えれば、SSH でつながるようになります（リモートリポジトリを管理する）。公開鍵を GitHub に追加したあとで行います。最初から SSH で使うなら、リポジトリの SSH の URL で clone します。SSH の URL は、リポジトリのページの、ファイル一覧の上にある Code をクリックし、SSH を選んで、コピーのアイコン（Copy to clipboard）をクリックすると写せます（Cloning a repository）。

手順 1: プロジェクトのフォルダへ移り、リモートの名前を確かめる

ターミナル（Windows は Git Bash）を開き、手元のプロジェクトのフォルダへ移ります。そのうえで、いまあるリモートを一覧にして、変えたいリモートの名前を確かめます。

git remote -v

手順 2: URL を SSH のものに変える

git remote set-url origin [email protected]:OWNER/REPOSITORY.git

git remote set-url は、いまあるリモートの URL を変えるコマンドです。引数は 2 つで、いまのリモートの名前（origin や upstream がよくあります）と、新しい URL です。OWNER/REPOSITORY の部分は、自分のリポジトリの持ち主とリポジトリの名前に置き換えます。

手順 3: 変わったか確かめる

git remote -v

次のように SSH の URL で表示されれば、切り替わっています（公式の文書の例）。

origin  [email protected]:OWNER/REPOSITORY.git (fetch)
origin  [email protected]:OWNER/REPOSITORY.git (push)

リモートの名前を打ち間違えると、fatal: No such remote 'sofake' のようなエラーになります（sofake は、公式の文書の例で打ち間違えた名前です）。名前を正しく打ったか確かめます。

逆に、SSH から HTTPS に戻すときは、次のコマンドです。

git remote set-url origin https://github.com/OWNER/REPOSITORY.git

そのあと fetch・pull・push をすると、GitHub のユーザー名とパスワードを聞かれます。パスワードの欄には、personal access token を入れます。

SSH の URL で clone・fetch・pull・push をすると、鍵にパスフレーズを付けている場合は、パスフレーズを聞かれます。鍵を ssh-agent に保存していれば、聞かれません。つながったあとの Git のコマンドは、【Github初心者】Gitコマンドのよく使う使い方を基本から学ぶで説明しています。

よくある質問

パスフレーズは必要？空（なし）でもいい？

公式の手順は、鍵を作るときに、安全なパスフレーズを入れるものです。パスフレーズは空にもできます。空にすると、パスフレーズなしの鍵になります。

公式が挙げているパスフレーズの役目は、次のとおりです。SSH キーを使っていると、誰かがコンピューターに入り込んだとき、その鍵を使うすべてのシステムに入れてしまいます。パスフレーズを付けると、守りを一段足せます。毎回入れるのが面倒なときは、鍵を ssh-agent に入れておけば、ssh-agent がパスフレーズを覚えてくれます。

パスフレーズなしの鍵にするときは、Mac では ~/.ssh/config の UseKeychain の行を省き、ssh-add は --apple-use-keychain を付けずに流します。

パスフレーズを変えたい・外したいときは？

鍵を作り直さずに、パスフレーズを付けたり変えたりできます。

ssh-keygen -p -f ~/.ssh/id_ed25519

いまのパスフレーズがあれば、先にそれを聞かれます。新しいパスフレーズを空にすると、パスフレーズなしで読める鍵になります（OpenSSH_9.6p1・macOS で確認した結果）。成功すると、次のように出ます（OpenSSH_9.6p1・macOS の出力）。

Key has comment '[email protected]'
Your identification has been saved with the new passphrase.

いまのパスフレーズを間違えると、incorrect passphrase supplied to decrypt private key というエラーになります。

パスフレーズを忘れたらどうなる？

ssh-keygen のマニュアルは、なくしたパスフレーズを取り戻す方法はない、と書いています。忘れたときは、新しい鍵を作って、公開鍵を配り直します。

Mac で、パスフレーズをキーチェーンに保存していれば、取り出せる場合があります（公式のページ）。Finder で「キーチェーンアクセス」を探し、「SSH」で検索して、項目をダブルクリックします。左下の「パスワードを表示」をクリックし、管理者のパスワードを入れます。

Windows には、取り戻す方法がありません。新しい鍵の組を作るか、HTTPS に切り替えて personal access token を使います。

GitHub の SSH キーに有効期限はある？

公式の文書には、1 年間使われていない SSH キーを、安全のために GitHub が自動で削除する、という決まりがあります（公式のページ）。削除されたら、新しい鍵を作って、アカウントに関連付け直します。

Ed25519 と RSA、どちらで作る？

公式の手順は、Ed25519 の鍵を作るコマンド（ssh-keygen -t ed25519 -C "[email protected]"）です。Ed25519 に対応していない古いシステムの場合に、RSA の鍵を作るコマンド（ssh-keygen -t rsa -b 4096 -C "[email protected]"）を使います。OpenSSH 9.5（2023年10月4日公開）から、ssh-keygen は何も指定しないと Ed25519 の鍵を作ります。

GitHub は、古い種類の鍵の扱いを変えています。2022年3月15日から、DSA の鍵（ssh-dss）は使えず、新しく追加もできません。RSA の鍵は使えますが、2021年11月2日より後に作った RSA の鍵（ssh-rsa）は、SHA-2 の署名が必要です。

まとめ

GitHub に push できる URL は、HTTPS と SSH の 2 種類です。公式によると、HTTPS は SSH より設定が簡単で、厳しいファイアウォールやプロキシでもふつう通ります。SSH は鍵の準備が要りますが、ユーザー名と personal access token を毎回入れずにつなげます。
この記事で見た公式のページでは、「推奨」が付いているのは HTTPS の側でした（「Git のセットアップ」の見出し、「リモートリポジトリを管理する」の例の前置き、2020年12月15日の GitHub のブログ）。SSH も、公式の手順がそろった方法です。
SSH でつなぐ流れは、鍵があるか確かめる → ssh-keygen -t ed25519 -C "[email protected]" で鍵を作る → ssh-agent に登録する（Mac と Windows で手順が違います）→ 公開鍵を GitHub の SSH and GPG keys に追加する → ssh -T [email protected] で確かめる、です。
つながらないときは、sudo、22 番ポート、git ユーザー、ssh-agent の鍵、-vT の出力、アカウントの鍵の順に確かめます。22 番ポートがふさがれているなら、443 番（ホスト名は ssh.github.com）を試します。
HTTPS で clone したリポジトリは、git remote set-url origin [email protected]:OWNER/REPOSITORY.git で SSH に切り替えられます。
公式の日本語版には、443 番のホスト名と、Monterey より前の -K の説明が、英語版と逆に訳されたページがあります（2026年10月時点）。迷ったら英語版も見比べてください。