AWS EC2接続エラー:'Permission denied'でハマる時間をゼロにする完全ガイド

せっかくEC2インスタンスを立ち上げ、ステータスチェックも「2/2 合格」を確認したのに、いざターミナルから接続しようとした瞬間に突きつけられるこの無慈悲なエラー。

Permission denied (publickey)

もしあなたが今、この画面の前で「セキュリティグループ設定は合っているはずなのに!」と頭を抱えているなら、安心してください。これはAWSのバグでも、あなたのネットワーク設定ミスでもありません。これは、SSHクライアントが「あなたの鍵の管理が雑すぎる」と警告してくれている、健全なセキュリティ機能なのです。

この記事では、単なるコマンドのコピペで終わらせず、「なぜエラーが出るのか」を腹落ちさせ、Windowsユーザー特有の厄介な権限問題を含めて、二度と同じエラーで時間を無駄にしないための恒久対策をシニアエンジニアの視点で解説します。

1. なぜSSHはあなたの鍵を拒否するのか?(原因の解剖)

エラーログをよく見ると、Permission denied の前に、もっと重要な警告が出ているはずです。

WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for 'key.pem' are too open.

これはSSHの「過保護」とも言える設計思想によるものです。秘密鍵(.pem)は、物理的な「家の鍵」と同じです。もしあなたが家の鍵を玄関マットの下(=誰でも読める状態)に置いていたら、警備会社は「危険すぎるのでセキュリティ契約を結べません」と言うでしょう。

SSHクライアントも同じことを言っています。「所有者以外(グループや他のユーザー)も読み取れる設定になっている鍵なんて、怖くて使えないよ」と、接続を自ら遮断しているのです。

エンジニアの心得: このエラーが出た時、サーバー側の設定(セキュリティグループやIAM)を確認しに行くのは時間の無駄です。問題は100%、あなたの手元のPC(クライアント側)にあります。

2. Mac / Linux ユーザーの解決策:3秒で終わるコマンド

UNIX系OSを使っている場合、解決は一瞬です。多くの記事で chmod 600 が紹介されますが、私は chmod 400 を強く推奨します。

# ディレクトリへ移動(通常はDownloadsか.ssh)
cd ~/Downloads

# パーミッションを変更
chmod 400 your-key-pair.pem

# 確認( -r-------- になっていればOK)
ls -l your-key-pair.pem
なぜ 400 なのか?
600(読み書き可能)でも接続はできますが、400(読み取り専用)にすることで、誤ってエディタで鍵ファイルを開いて中身を書き換えてしまう事故(=鍵の破損)を防げます。「秘密鍵は生成後、二度と編集しない」のが鉄則です。

3. Windows ユーザーの解決策:GUI操作は卒業しよう

Windowsユーザーにとって、このエラーは厄介です。Windowsのファイルシステム(NTFS)には chmod という概念がないからです。多くの解説記事は「ファイルを右クリックしてプロパティから…」と長大な手順を説明しますが、エンジニアなら PowerShellでスマートに解決 しましょう。

以下のコマンドを管理者権限のPowerShellで実行してください。GUIでポチポチ設定する手間を一撃で解決します。

# 変数にキーのパスを代入(パスは適宜書き換えてください)
$path = ".\your-key-pair.pem"

# 現在の継承権限をリセット
icacls $path /reset

# 現在のユーザーにのみ「読み取り(R)」権限を付与
icacls $path /grant:r "$($env:USERNAME):(R)"

# その他すべての継承権限を削除(ここが重要!)
icacls $path /inheritance:r

これで、UNIXの chmod 400 と同等の「自分だけが読める」状態になります。WSL(Windows Subsystem for Linux)を使っている場合は、Linux側のファイルシステムに鍵を置いて chmod 400 するのが最も手っ取り早いです。

4. もうIPアドレスは打たない:~/.ssh/config の活用

パーミッション問題を解決したとしても、毎回以下のようなコマンドを打つのは苦行でしかありません。

ssh -i ~/.ssh/my-key.pem ec2-user@192.0.2.1

シニアエンジニアは、接続情報を ~/.ssh/config ファイルに記述して効率化します。まだ設定していないなら、今すぐ作成しましょう。

# ~/.ssh/config ファイルを編集
Host my-server
    HostName 192.0.2.1  # またはパブリックDNS
    User ec2-user
    IdentityFile ~/.ssh/my-key.pem
    Port 22

この設定をしておけば、ターミナルで以下のように打つだけで接続できます。

ssh my-server

これなら、鍵ファイルのパス指定忘れやIPアドレスのコピペミスも防げます。チーム開発でも「configファイルを共有(秘密鍵は除く)」することで、オンボーディングが劇的に早くなります。

5. それでも繋がらない時の「最終奥義」

権限も直した、ユーザー名(Amazon Linuxならec2-user、Ubuntuならubuntu)も合っている。それでも繋がらない場合は、詳細デバッグモードを使いましょう。

ssh -v -i your-key.pem ec2-user@xx.xx.xx.xx

-v(verbose)オプションをつけることで、SSHの通信プロセスが全て表示されます。ここで「key type not supported」などのエラーが出ている場合、鍵のフォーマット自体(OpenSSH形式か、PuTTY形式か)が間違っている可能性があります。

まとめ:エラーは味方につけろ

Permission denied は初心者が必ず通る道ですが、セキュリティの基本原則である「最小権限の原則」を学ぶ絶好の機会です。

  • Mac/Linuxなら chmod 400
  • Windowsなら icacls で権限剥奪
  • 運用は ~/.ssh/config で楽をする

これらを徹底して、インフラ作業のストレスをゼロにしましょう。

Post a Comment