Linuxサーバにおいてsshで締め出される恐怖 - その2

ssh締め出しの例

前回は、「ssh接続から閉め出されることがあるので注意しよう」という内容をまとめた。sshで締め出される、または、アクセスができなくなるのにはいくつかの理由がある。設定ファイルのパーミッションや設定ミスが理由になることもあれば、ファイアウォールの設定ミスが原因になることもある。

理由はどうあれ、sshで締め出しをくらった時の絶望感はなんとも言えない。今回は、実際にどのようなケースで締め出しをくらうのかを見てみよう。

例えば、以下のスクリーンショットはsshでUbuntu Server 18.04 LTSにログインしたあとで、ファイアウォールの設定を確認しているというものだ。

このサーバは、sshでのアクセスはすべての接続に対して許可されている。sshの運用をもう少し厳しくしようとして、このユーザーはまずsshdへのアクセスをすべて拒否するように設定を変更している。

このあと、特定のIPアドレスからの接続だけを許可する設定を追加していこう、というのがこのユーザーの考えだ。それほど間違った発想ではなく、よく行う作業だ。

• sshへのアクセスをとりあえず拒否する

ということで、適切に設定を行えばよいのだが、ターミナルアプリケーションがクラッシュして落ちてssh接続が失われてしまうこともあるし、設定をする前に誤って接続を切ってしまうこともある。設定そのものを間違えることだってある。そうなると、悲惨な結果を生むことになる。

さらに注意が必要なのは、ssh経由で作業ができてしまっているために錯覚しやすいことだ。いったん確立したssh接続は保持されたままなので、sshは接続できるという根拠のない自信がユーザーに生まれがちだ。

問題を確認するために、試しに、アクセス許可設定を追加していないこの状態でssh接続を切ってみる。次のように、当然だがログインできなくなる（注意：現実のサーバではこのようなことをしてはいけない）。

• アクセス拒否した状態でssh接続を切ると、sshアクセスできなくなる

しばらく待つと、次のようにタイムアウトでログインできなくなったことを確認できる。この辺りで事態がおぼろげながらにわかってきて、顔面が蒼白になってくる。

• タイムアウトしてsshログインできないことに気がつく

sshでログインした状態でファイアウォールの設定を変更する時は、これが最大の注意点だ。作業中のssh接続はそのまま利用できているため、外部からアクセス可能な状態になっているかを確認しないまま作業を終えてしまうことがある。作業を終えてssh接続を切る前に、別のターミナルアプリケーションからサーバにsshログインできるかどうか確認することを推奨しておきたい。

不幸はいつやってくるかわからない

自分ならこんな失敗はしない――多くのエンジニアが考えると思う。

たしかに、ちょっと注意すれば回避できることだ。しかし、アプリケーションのクラッシュはユーザーでは回避できないし、電源タップのスイッチが何かの拍子にOFFになって、作業中のデスクトップPCの電源がいきなり落ちるといったことが100%起こらないとは言えない。起こってからはもう取り返しがつかない。

「この操作はまずいかも」という悪い予感がする時は、作業する前に防御策を打っておくことをお薦めしたい。sshアクセスを許可するコマンドをcrontabに仕込んでおいて、最悪でも1時間後にはいったんアクセスできる状態にするといったことも保険になる。なお、作業が完了したら、この保険を無効にすることも忘れないようにしよう。