突然つながらなくなったEC2

投稿日: 2025-07-07 | カテゴリ: 開発

ある日、いつも通りEC2インスタンスへSSH接続しようとしたら、突然つながらなくなりました。
IPアドレスも間違っていないし、秘密鍵のパスも合っています。前日までは普通に接続できていたのに。

以前にも同じようなトラブルがあり、その時はEC2の再起動で直った記憶があったので、今回も再起動を試みましたが、状況は改善しませんでした。
その時の対処をまとめたブログを読み返そうとしたのですが、そもそもブログ自体にアクセスできないというオチで、これが盲点でしたね。

仕方なくGitから過去の記録を辿ったのですが、今回の問題は別の原因だと判明しました。
この記事では、その原因と対処についてまとめていきます。

しばしの調査と気づき

SSH接続をデバッグモード（ssh -vvv）で試すと、
「identity file xxx.pem type -1」と表示され、秘密鍵が認識されていない様子でした。

そこで秘密鍵ファイルのパーミッションを確認したところ、なんと400ではなく600になっていました。すぐにchmod 400 iskuu.pemで秘密鍵のパーミッションを修正すると、見事にSSH接続が復活しました。

「600でも問題ないのでは？」と思いましたが、実は秘密鍵のパーミッションが緩すぎると、SSHがセキュリティ上の理由で接続を拒否することがあります。
最近ではSSHのセキュリティポリシーが徐々に厳しくなっているようです。

もしかすると、元々400に設定していたものを、いつの間にか600に変更してしまったのかもしれません。そんなことはないと思おうのだけど、、、

Linuxのファイルパーミッションは数字で表されますが、600と400は意味は以下の通りです。

400: ファイルの所有者が読み取り（r）のみ可能。書き込み（w）や実行（x）は不可。
→ 秘密鍵ファイルとして最も安全な設定。
600: ファイルの所有者が読み取り（r）と書き込み（w）が可能。実行は不可。
→ 書き込み権限があるため、秘密鍵が書き換えられるリスクがわずかに上がる。

SSHは秘密鍵の権限が緩い（例：他のユーザーにも読める・書き込める）場合、セキュリティ上問題があるとして接続を拒否します。
そのため秘密鍵ファイルは、基本的に「所有者のみが読み取り可能（400）」の設定が推奨されます。

一方で、600でも所有者以外にはアクセスできないため動く場合もありますが、書き込み可能な状態は安全性の観点から推奨されません。
特にAWSなどの公式ドキュメントでも秘密鍵のパーミッションは400が推奨されているようです。