不思議な現象ですね。
そこで主要部分をそのままで、最後に「なにか情報はありますか？」とAIに問い合わせてみたところ、
★☆★☆★
(WinSCP誤操作も疑われていて事実関係はハッキリしませんが)
現時点の結論は(何らかの理由で)authorized_keys のパーミッション破損
～～ [AI回答] ～～
AWS＋WinSCP では実際に似た事例が報告されています。検索結果から、原因として特に有力なものをまとめます。
----------------------------------------
見つかった有力な原因候補（実例ベース）
----------------------------------------
① authorized_keys のパーミッションが壊れる（最有力）
AWS re:Post でもまったく同じ症状が報告されており、
\u0026gt; 最初は接続できるが、しばらくすると「サーバが鍵を拒否しました」になる
\u0026gt; → authorized_keys のパーミッションが変わってしまっている可能性
と指摘されています。
【よくある壊れ方】
- /home/ec2-user/.ssh/authorized_keys の権限が 600 以外になる
- .ssh ディレクトリの権限が 700 以外になる
- 所有者が ec2-user 以外に変わる
→ WinSCP の GUI 操作で誤って変更されるケースが多い
----------------------------------------
② ファイル操作で root や別ユーザが所有者になってしまう
AWS re:Post でも、
\u0026gt; 特定のディレクトリにファイルを配置した後に接続できなくなる
\u0026gt; → 所有者やパーミッションが変わっている可能性
と報告されています。
WinSCP は GUI で操作しやすいため、知らないうちに所有者変更が起きることがあります。
----------------------------------------
③ AMI 共有・再作成系の鍵不整合（別事例）
別の AWS 事例では、AMI 共有後に鍵が拒否される問題がありましたが、今回のケースとは少し違います。
----------------------------------------
どう切り分けるべきか
----------------------------------------
【Step 1】ログインできなくなった直後に SSH ログを見る
AWS re:Post でも推奨されています。
- Systems Manager Session Manager でログイン
- /var/log/secure を確認
- 「Authentication refused: bad ownership or modes for directory /home/ec2-user/.ssh」
などのエラーが出ていれば確定
----------------------------------------
ほぼ確実に直る対処法
----------------------------------------
① パーミッションを修正
Session Manager で入って以下を実行：
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown ec2-user:ec2-user ~/.ssh -R
② WinSCP の「保存時のパーミッション変更」を無効化
WinSCP はアップロード時にパーミッションを勝手に変える設定があります。
- 設定 → 転送 → デフォルト → パーミッション
- 「パーミッションを設定する」のチェックを外す
これで勝手に壊れるのを防げます。
----------------------------------------
まとめ：この現象は「珍しいけど実在する」
----------------------------------------
検索結果から、AWS re:Post にまったく同じ症状の報告が存在し、
原因はほぼ authorized_keys のパーミッション破損と考えられます。
WinSCP は GUI で操作しやすい反面、
知らないうちに .ssh の権限を壊す事故が非常に多いです。
━
