この記事では、Amazon EC2 で突然 SSH 接続ができなくなったときに、 どのように原因を特定し、実際に復旧したかを時系列で詳しく解説します。
Permission deniedやConnection refusedが出ている- EBS を救出して設定を直したい
- 「PasswordAuthentication no」で締め出された
こうした状況の人に、きっと役立つ内容です。
1. 発生状況｜ EC2 で SSH が「Connection refused」になった
2025 年 10 月 18 日、Amazon EC2（Amazon Linux 2023）に SSH 接続を試みた際、次のエラーが発生しました。
ssh: connect to host 57.181.53.168 port 22: Connection refusedWeb サイトSIer社員の生存戦略は正常に稼働しており、Apacheも動作中。
しかし SSH だけが完全に拒否され、サーバへログインできない状態になっていました。
2. SSH 接続できなくなった原因の分析
✅ 結論
原因は、以前お名前.comのセキュリティ診断の指摘を受けてSSH 設定を強化したことにありました。 その設定が過剰に厳しく、結果としてサーバが自己ロックアウト状態に陥りました。
具体的には、以下の/etc/ssh/sshd_config の設定です。
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yesこの設定は一見正しいのですが、次の 3 つの条件が重なり、SSH が完全に使えなくなっていました。
① sshd が設定エラーでクラッシュしていた
sshd（SSH サーバ）は起動時に/etc/ssh/sshd_configを読み込みますが、構文ミスや存在しない設定項目があると、即座にエラー終了します。
実際、systemctl status sshdでは以下のように出ていました：
Active: activating (auto-restart) (Result: exit-code)
Process: 21554 ExecStart=/usr/sbin/sshd -D (code=exited, status=255/EXCEPTION)つまり、設定ファイルの文法誤りやコメント削除時の改行抜けなどにより、sshdが正常起動できていなかったのです。
② .sshディレクトリのパーミッション不整合
sshd はセキュリティ上、権限が少しでも緩いとその鍵を自動的に無視します。
たとえば以下のような状態だと認証が拒否されます。
| パス | 問題例 |
|---|---|
/home/ec2-user が 755 |
他ユーザーに読み取り権限あり |
/home/ec2-user/.ssh が 755 |
鍵が他人に見える可能性 |
authorized_keys が 644 |
公開鍵リストが第三者に読める |
| 所有者が root | ec2-user 本人のものではない |
| SELinux ラベル不一致 | Amazon Linux では即拒否 |
この問題は、障害発生時点の原因ではなく、復旧作業中に root 権限で操作した際に一時的に発生した副作用でした。 chroot 環境で .ssh ディレクトリを編集した結果、所有者が root:root になり、 sshd が「ec2-user 本人が管理していない鍵」と判断して無視していました。 そのため、修復の最終段階で公開鍵認証が通らず、接続に失敗する状態となっていました。
③ PasswordAuthentication no により代替経路も封鎖
SSH には複数のログイン方法があります。
- 公開鍵認証（pem キー）
- パスワード認証
- PAM/キーボードインタラクティブ認証
しかしこの設定では：
PasswordAuthentication no
PubkeyAuthentication yesつまり「鍵だけ許可」。
その鍵が ② の理由で認識されなかったため、全てのログイン手段が失われたのです。
🔄 要因の連鎖まとめ
| 段階 | 内容 | 結果 |
|---|---|---|
| ① | sshd_config の構文エラー | sshd が起動せず「Connection refused」 |
| ② | パーミッション不正 | 鍵を無視され認証失敗 |
| ③ | PasswordAuthentication=no | 代替経路が封鎖され完全ロックアウト |
3. EC2 SSH 接続を復旧する手順（EBS マウント・chroot 編）
まず、結構色々しているので、大きく 6step に分けると以下のことをやりました。
🧾 今回行った復旧アクション一覧
- EBS を他インスタンスに接続して中身を調査
- chroot で仮想ログインして設定修正
- OpenSSH を再構築（rpm 再インストール）
- SSH 設定を初期化
- パーミッションと SELinux を修正
- EBS を元に戻して再起動
次にそれぞれについて詳細を記載します。
(1) EBS を別インスタンスに接続
AWS マネジメントコンソール（Management Console）から以下の手順でEBSの付け替えをしました。 特に注意点はありませんが、別インスタンスを立ち上げるので、別途料金が発生してしまうことは注意しないとですね。
- 元の EC2 インスタンスを停止
- ルート EBS ボリュームをデタッチ
- 別のインスタンスを起動（同一 AZ 内）
- 問題の EBS を
/dev/nvme1n1として接続
(2) マウントと chroot 環境の構築
別インスタンスに元のEBSを繋いで、マウントとchroot環境の構築をします。 ここも、特に詰まるポイントはないと思います。
sudo mkdir /mnt/recovery
sudo mount /dev/nvme1n1p1 /mnt/recovery
sudo chroot /mnt/recovery💡chroot とは？
chroot は指定ディレクトリを“仮想的なルート（/）”として扱う機能。
壊れた EBS の中にログインしたかのように操作できます。
これにより、停止中のシステムの設定を直接修正可能になります。
(3) OpenSSH の再構築
目的
sshd が壊れている・依存関係が壊れている可能性を排除するため、再インストールを実施。
recoveryインスタンス側で
sudo dnf reinstall -y --downloadonly --downloaddir=/home/ec2-user/sshpkgs openssh openssh-server openssh-clients
sudo cp /home/ec2-user/sshpkgs/*.rpm /mnt/recovery/root/chroot内で
cd /root
rpm -Uvh --force *.rpm| コマンド | 意味 |
|---|---|
-Uvh |
アップグレード＋インストール |
--force |
競合しても強制上書き |
.rpm |
OpenSSH 関連パッケージファイル群 |
この処理で壊れた sshd を健全な状態へ再構築。
(4) SSH 設定をリセット
SSH設定を厳格にしてしまっていたので、一時的に緩和させます。
cat > /etc/ssh/sshd_config <<'EOF'
Port 22
Protocol 2
PermitRootLogin yes
PasswordAuthentication yes
PubkeyAuthentication yes
UsePAM yes
Subsystem sftp /usr/libexec/openssh/sftp-server
EOF
sshd -t
systemctl enable sshd
systemctl restart sshd| 設定 | 意味 |
|---|---|
PermitRootLogin yes |
緊急時に root ログインを許可 |
PasswordAuthentication yes |
パスワードログインを再有効化 |
PubkeyAuthentication yes |
鍵認証を維持 |
UsePAM yes |
PAM 経由の認証を許可 |
※ 本設定は復旧作業のための一時的なものであり、復旧後は「PermitRootLogin prohibit-password」に戻すことを推奨します。
(5) 権限の修正
鍵ファイルの修正もします。 最初に述べたように、sshd はセキュリティ上、権限が少しでも緩いとその鍵を自動的に無視しますので、 この値はちゃんと設定が必要ですね。
chmod 700 /home/ec2-user
chmod 700 /home/ec2-user/.ssh
chmod 600 /home/ec2-user/.ssh/authorized_keys
chmod 600 /home/ec2-user/.ssh/id_rsa
chmod 644 /home/ec2-user/.ssh/id_rsa.pub
chown -R ec2-user:ec2-user /home/ec2-user/.ssh
restorecon -Rv /home/ec2-user/.ssh| コマンド | 目的 |
|---|---|
chmod 700 |
ディレクトリを本人専用に |
chmod 600 |
鍵ファイルを本人だけが読めるように |
chown |
所有者を修正 |
restorecon |
SELinux コンテキストを修正 |
これにより、sshd が鍵ファイルを信頼できるようになります。
(6) EBS を戻して再起動
sudo umount /mnt/recoveryAWS コンソールで EBS を元インスタンスに再接続し、起動。
systemctl status sshdが active (running) であれば復旧成功。
ここまでスムーズに行かなかったので、私は4時間ほど要しました。
4. 再発防止策
| 対策 | 内容 |
|---|---|
| 設定変更前にバックアップ | cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak |
| PasswordAuthentication は段階的に no へ | 最初から no にしない |
| 構文チェックの徹底 | sshd -t 実行で構文エラーを防ぐ |
| パーミッション確認 | ls -ld ~/.ssh と ls -l ~/.ssh/* を都度確認 |
| UserData 過信禁止 | 編集後再実行されないため復旧用途には不適 |
| recovery 手順を保存 | chroot+EBS マウント手法を記録しておく |
5. 教訓まとめ
- 原因：セキュリティ強化による過剰な制限と権限不整合
- 結果：鍵・パスワードの両方が無効化されログイン不可
- 対応：EBS マウント＋ chroot ＋ OpenSSH 再構築＋権限修正
- 教訓：安全性を上げる前に「再入室ルート」を必ず確保する
EC2 は“中身（EBS）さえ無事なら復活できる”。
今回のトラブルで、それを実感しました。
SIer で働いていると、セキュリティといえば「ネットワークを物理的に遮断する」アプローチが多く、 こうしたサーバ設定レベルでの制御にはあまり触れません。
今回の件で、インフラ管理の基本を改めて学べた気がします。 ただ、貴重な土曜日が潰れたのはやっぱり痛かったですね……（笑）
