EC2 を1台立てた。次は「SSH でつなぐ」と書いてある。鍵のファイルを落として、言われたとおりコマンドを打ったのに、Permission denied や timed out で止まる。鍵って何を渡しているのか、「ポート 22 を開ける」とはどこの話なのか、自分の端末とあの1台のあいだで何が起きているのか。ここが絵になっていないと、つながらない理由を当てずっぽうで探すことになります。この記事は、SSH を「合鍵」のたとえで掴んでから、接続の3段階・門（ポート 22）・切り分けの順番までを1本で整理します。
この記事の結論
- SSH とは、遠くにある1台のコンピュータに、暗号化された通信で「文字で入る」道具です。
- 公開鍵は配ってよい「南京錠」、秘密鍵は渡してはいけない「鍵」。サーバーに置くのは南京錠だけです。
- SSH の接続は「相手の確認 → 自分の証明 → 暗号化された会話」の3段階で進みます。
- ポート 22 は門で、セキュリティグループが自分の IP に開いていなければ、鍵が正しくても門に着きません。
- つながらないときは「道が無い → 門が閉じている → 鍵が違う → 鍵ファイルの権限」の順に切り分けます。
- 秘密鍵は自分の端末から出さない。パスワード認証を使わないのは、総当たりで試せてしまうからです。
SSH とは「遠くの1台に文字で入る」道具
SSH（Secure Shell）は、ネットワークの向こうにあるコンピュータに入って、その中でコマンドを打つための約束事（プロトコル）です。ターミナルの読み方で触った黒い画面が、手元のパソコンではなく、遠くの1台の中で動く。それだけです。
たとえるなら、SSH は「遠隔地の部屋に電話をつないで、そこにいる自分の分身にキーボードを打たせる」道具です。画面に出る文字は、向こうの部屋で起きていることの報告です。
なぜ「Secure」が付くのか。SSH が生まれる前は telnet や rsh という道具が同じことをしていましたが、打った文字もパスワードも、そのままの形で回線を流れていました。途中で覗けば全部読める。それを暗号化して、しかも「相手が本物か」「自分が本人か」を確かめてから会話を始めるようにしたのが SSH です。仕様は RFC 4251 に「認証・暗号化・改ざん検出を備えた安全なリモートログイン」と書かれています。
クラウドでは、この道具が「借りた1台の中に入る唯一の道」になることが多いです。EC2 とは何かで借りた1台は、データセンターのどこかにあり、画面もキーボードも付いていません。だから最初の一歩は SSH で入ることになります。
READ ALSO — 未経験向け・段1 入口
EC2 とは何か｜インスタンス・AMI・EBS・セキュリティグループを「借りた1台」で理解する
公開鍵と秘密鍵は「南京錠と鍵」。配ってよいものと、渡さないもの
SSH で本人確認に使うのが、公開鍵と秘密鍵の対（キーペア）です。名前が似ているので混ざりますが、役割は正反対です。
- 公開鍵は南京錠。 誰に配ってもかまいません。南京錠を持っているだけでは、それを開けることはできないからです。
- 秘密鍵は鍵。 対になる南京錠を開けられる、世界で1本の鍵です。人に渡さず、自分の端末から出しません。
EC2 でキーペアを作ると、公開鍵（南京錠）がその EC2 の中に登録され、秘密鍵（鍵）のファイルが1回だけ手元に落ちてきます。以後、ログインのたびにサーバーは「この南京錠を開けられる鍵を持っているか」を確かめます。鍵そのものを送るのではなく、「持っている」ことを計算で証明するだけなので、途中で覗かれても鍵は漏れません。
PADLOCK AND KEY合鍵のたとえで
南京錠は配ってよい。鍵は渡さない
合鍵のたとえ日常の道具で
SSH の言葉正確な名前で
合鍵のたとえ: 南京錠 — 誰に配ってもよい
SSH の言葉: 公開鍵 — サーバーに登録する
合鍵のたとえ: 鍵 — 世界で1本。人に渡さない
SSH の言葉: 秘密鍵 — 自分の端末から出さない
合鍵のたとえ: 南京錠を扉に取り付ける
SSH の言葉: EC2 のキーペアで公開鍵を1台に置く
合鍵のたとえ: 鍵を持っていると見せる
SSH の言葉: 秘密鍵で署名し、公開鍵で検算する
ここで、たとえ話を正確な言葉に戻しておきます。公開鍵と秘密鍵は数学的に対になった2つの数値で、片方で作った署名を、もう片方でだけ検算できます。サーバーは公開鍵で検算し、通ればその人が秘密鍵を持っていると分かる。これが RFC 4252 に書かれている公開鍵認証です。
なぜパスワードではなく鍵なのか
パスワード認証は「合言葉を送る」方式です。短く、人が覚えられる範囲で作られ、しかも試行を何度でも受け付けます。インターネットに向けた 22 番には、機械が休みなく合言葉を試しに来ます。
秘密鍵は数百桁の数値で、しかも送りません。端末から出ない限り、試しようがない。AWS の EC2 が最初からパスワード認証を無効にしているのは、この理由からです。
CHECK 1ここまでの確認
EC2 のキーペアを作ったとき、サーバー（EC2）側に置かれるのはどちら?
答えと解説
答え: 2. 公開鍵。南京錠は配ってよいから
サーバーに登録されるのは公開鍵（南京錠）だけです。秘密鍵（鍵）は自分の端末に1つだけ置き、接続のたびに「持っている」ことを証明します。「公開鍵と秘密鍵は南京錠と鍵」の節を読み直してください。
接続は3段階で進む。相手の確認 → 自分の証明 → 暗号化された会話
ssh と打ってからプロンプトが出るまで、裏では3段階が順に進んでいます。
- 相手の確認（ホスト認証）。 サーバーは自分のホスト鍵を示し、端末は「前に会った相手と同じか」を照らし合わせます。初めての相手だと「本当にこの相手でよいか」と聞かれるのはこの段階です。偽のサーバーに秘密鍵の証明を渡さないための確認です。
- 自分の証明（ユーザー認証）。 端末は秘密鍵で署名を作り、サーバーは登録された公開鍵で検算します。通れば「あなたはこの鍵の持ち主」と認められます。
- 暗号化された会話。 ここからの文字は全部暗号化されて流れます。打ったコマンドも、返ってきた結果も、途中では読めません。
THREE STEPS TO LOGINssh と打ってから
相手を確かめ、自分を証明し、それから暗号化された会話
-
門に着く
TCP の 22 番。セキュリティグループが開いていれば
-
相手の確認
サーバーのホスト鍵を、前に会った相手と照合
-
自分の証明
秘密鍵で署名。サーバーは公開鍵で検算
-
暗号化された会話
打ったコマンドも結果も途中では読めない
順番に意味があります。相手を確かめてから、自分を証明する。逆だと、なりすましの相手に自分の証明を差し出すことになります。「初めて接続する相手です」の確認をよく読まずに yes と打つ癖は、この順番の意味を知ると直ります。
なお、この3段階が始まるのは「門に着いてから」です。門に着かなければ、相手の確認すら始まりません。次の節がその門の話です。
ポート 22 は門。セキュリティグループが開いていないと着かない
SSH のサーバーは、既定で TCP の 22 番で待ち受けています。ネットワークとは何かの言葉で言えば、22 番は「その1台の中で SSH が待っている窓口」です。
EC2 では、その窓口の前にセキュリティグループという門があります。門には「どの窓口を、どこから来た通信に開けるか」の札が並んでいて、札に無い通信は跳ね返されます。鍵が正しくても、門が閉じていれば鍵を見せる場所まで着きません。
PORT 22 IS A DOOR門の札は「どこから」
22 番は自分の IP からだけ開ける
セキュリティグループ（EC2 の門）
- 22SSH 通る自分の IP から
- 22SSH 止まる知らない IP から
- 443HTTPS 通る全世界から
門の札で大事なのは「どこから」です。22 番を全世界（0.0.0.0/0）に開けると、鍵を持たない人も門の前までは来られます。門の前で鍵を試され続けるのは気持ちのよいものではないので、22 番は自分の IP からだけ開けるのが基本です。自宅の IP は変わることがあるので、つながらなくなったら「門の札の IP が古い」を疑います。
門の手前には、そもそも「道」があるかという問題もあります。EC2 がパブリック IP を持っていない、サブネットからインターネットへの経路が無い、といった場合は門にすら着きません。この「道」の話は VPC とは何かで扱います。
CHECK 2ここまでの確認
ssh コマンドを打つと、しばらく待たされて「Connection timed out」で終わる。最初に疑うのはどれ?
答えと解説
答え: 3. 経路が無いか、セキュリティグループの 22 番が自分の IP に開いていない
timed out は「相手まで届かなかった」の印です。鍵やユーザー名を調べるのは、門（ポート 22）に着いてからです。「ポート 22 は門」と「切り分けの順番」の節を読み直してください。
つながらないときは、この順番で切り分ける
「SSH できない」は1つの症状ではなく、止まる場所が4つあります。出たメッセージで、どこで止まったかがだいたい分かります。手前から順に疑うのがコツで、鍵を疑う前に道と門を見ます。
| 順 | 止まる場所 | よく出るメッセージ | 疑うこと |
|---|---|---|---|
| 1 | 道が無い | Connection timed out（長く待って諦める） |
パブリック IP が無い、サブネットにインターネットへの経路が無い、インスタンスが起動していない |
| 2 | 門が閉じている | Connection timed out / Connection refused |
セキュリティグループの 22 番が自分の IP に開いていない、自分の IP が変わった |
| 3 | 鍵が違う | Permission denied (publickey) |
別のキーペアの秘密鍵を指定している、ユーザー名が違う（AMI によって既定のユーザー名が違う） |
| 4 | 鍵ファイルの権限 | UNPROTECTED PRIVATE KEY FILE! |
秘密鍵のファイルが他の人からも読める状態。自分だけが読める権限に直す |
1と2は同じ timed out に見えることが多いので、「道はあるか」を先に確かめてから門を見ます。3は門を通った証拠でもあります。相手には着いていて、自分の証明で止まっている。4は SSH クライアント側の安全装置で、ファイルの権限の話がそのまま出てきます。秘密鍵が誰でも読める状態だと、クライアントは鍵を使うのを拒みます。
SSH を使わない入り方もある
ここまで読んで「門を開けるのも鍵を配るのも面倒だ」と感じたなら、その感覚は正しいです。AWS には、22 番を開けずに1台へ入る道が用意されています。
- EC2 Instance Connect: 短時間だけ有効な公開鍵を AWS 側が送り込んで接続する仕組み。手元に秘密鍵ファイルを置き続けなくてよい。
- Session Manager（AWS Systems Manager）: 22 番を開けずに、AWS の経路を通してシェルに入る仕組み。誰がいつ入ったかの記録も残る。
実務ではこちらが選ばれることが増えていますが、その裏でも「相手の確認 → 自分の証明 → 暗号化された会話」の考え方は同じです。だから先に SSH の仕組みを掴んでおく価値があります。設定の手順は公式ドキュメントで確認してください。
CHECK 3ここまでの確認
「Permission denied (publickey)」と出た。門には着いている。次に疑う順番として近いのは?
答えと解説
答え: 2. ユーザー名 → 指定した鍵ファイル → 鍵ファイルの権限
publickey で拒まれたということは、門は通っていて「自分の証明」で止まっています。ユーザー名・鍵の取り違え・鍵ファイルの権限（他の人が読める状態）を順に見ます。「切り分けの順番」の表を読み直してください。
まとめ
SSH は、遠くの1台に暗号化された通信で「文字で入る」道具です。公開鍵は配ってよい南京錠、秘密鍵は渡さない鍵で、サーバーに置くのは南京錠だけ。接続は「相手の確認 → 自分の証明 → 暗号化された会話」の順に進み、それが始まるのはポート 22 の門を通ってからです。つながらないときは「道 → 門 → 鍵 → 鍵ファイルの権限」の順に切り分ける。秘密鍵は端末から出さず、22 番は自分の IP からだけ開ける。
やることは3つだけです。EC2 を1台立てるときにキーペアを作って秘密鍵を自分だけが読める場所に置く。セキュリティグループの 22 番を自分の IP に限って開ける。ssh で入って、whoami のような壊さないコマンドを1つ打つ。入れたら、次は「誰に何を許すか」を決める IAM とは何かへ進んでください。
READ ALSO — 学習中向け・段1 入口
IAM とは何か｜ユーザー・ロール・ポリシーを「誰が・何に・何をしてよいか」で読み解く
参照ソース
- OpenSSH Manual Pages — ssh(1)・sshd(8)・ssh-keygen(1) のマニュアル。公開鍵認証・ホスト鍵の確認・秘密鍵ファイルの権限の扱いの根拠（2026年9月時点）
- RFC 4251 “The Secure Shell (SSH) Protocol Architecture” — SSH が認証・暗号化・改ざん検出を備えたリモートログインの約束事であること、サーバーがホスト鍵を持つことの根拠（2006年）
- RFC 4252 “The Secure Shell (SSH) Authentication Protocol” — 公開鍵認証で、秘密鍵による署名をサーバーが公開鍵で検証する仕組みの根拠（2006年）
- SSH を使用して Linux インスタンスに接続する（Amazon EC2 ユーザーガイド） — 秘密鍵ファイルを他の人から読めない権限にすること、AMI ごとの既定のユーザー名、セキュリティグループで 22 番を許可する前提の根拠（2026年9月時点）
- Amazon EC2 のキーペアと Linux インスタンス（Amazon EC2 ユーザーガイド） — 公開鍵がインスタンスに保存され、秘密鍵は利用者が保管すること、EC2 が既定でパスワード認証を無効にしていることの根拠（2026年9月時点）
- EC2 Instance Connect を使用して Linux インスタンスに接続する（Amazon EC2 ユーザーガイド） と AWS Systems Manager Session Manager — 22 番を開けずに入る代替手段の根拠（2026年9月時点）
