hosts.allow、hosts.deny のファイル名変更は慎重に

とくに、VPSやAWS（Amazon Web Service）などのクラウドを使っている場合ですが、ともかく SSH で自分が入れなくなるとサーバーの本体が近くにあるわけではないので、大変困難な状況になるわけです。




私の場合   　　　　


hosts.deny は ALL:ALLで、
hosts.allow に許可IPやドメインを列記していました。

hosts.allowを編集する前に、稼働中の hosts.allow を
大事を取って「hosts.allow-backup」にリネームしました。（←ここがお馬鹿さん）


はい。
すべてアクセス遮断です。自分で自分を。


調べてみると、当該サーバーでは、SSHは tcp-wrappers でコントロールされているようで。

http://okwave.jp/qa/q614484.html
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1246947792
http://soudan1.biglobe.ne.jp/qa4586021.html

>>sshdのrestartの必要はありません
>>設定後(書き込み後)即反映されます

ぎゃーー！
hosts.allow が「ない」ので、リアルタイムに「allow対象がない」

よって
リモートでログインできない＝なにも操作できなくない＝元に戻せない

わけです。



てんまつ   　　　　

当該サーバーは実はAWSで、
お世話になっている方に使わせていただいているものでした。
連絡をさし上げたところ、技術者の方が対応してくださいました。

手順の概略は下記だったようです。

(1)当該サーバーのインスタンスと、ストレージを分離
(2)ストレージを、別のインスタンスに、ドライブとしてマウント
(3)上記にて、ファイル名をもとに戻す
(4)本来のインスタンスに、ストレージを戻す
(5)再起動して復旧

原因と今後の教訓　 　　　　


普段のhttpd.confとかでやってる流れ作業が癖になっていました。
まさかこんな大事な設定が、リアルタイムに影響することはないと思っていたんです。
sshd か inetd を再起動したタイミングで反映されるんだろうなと。。（←ここがお馬鹿さん）


今後、
ファイル修正時は、リネーム操作でバックアップを取ることは避ける。
↓
元ファイルを別名でコピーしてバックアップとし、
元ファイルを、新しいファイルで上書きする。


そういう習慣に変えようと思います。



以上、お恥ずかしい話でした。