ssh締め出しの恐怖

Linuxサーバでの作業となると、sshでログインしてリモートで作業を行うというパターンが大半だろう。サーバが置かれている場所はオンプレミスであったりデータセンターであったり、はたまたクラウドサービスであったりとさまざまだろうが、目の前にLinuxサーバがあり、そのサーバに接続されたキーボードを使って作業を行うことは、業務ではあまりないだろう。

  • ssh経由でUbuntu 18.04 LTSにログイン中

    ssh経由でUbuntu 18.04 LTSにログイン中

sshでログインしてリモートで作業を行う際は、sshは設定を間違えるとすぐに接続できなくなる点に注意する必要がある。クラウドサービスによってはsshでログインするしかアクセス手段を提供していないものだってある。そうしたケースでは、sshでアクセスできなくなるということは、そのシステムを失うに等しいことになる。

sshでリモートログインして作業することが当たり前になってくると、sshでログインできて当然と考えるというか、もうそれが習慣になってしまって、そこに注意を払わなくなる。しかし、sshはちょっとした手違いですぐにアクセスできなくなるのだ。やらかしてしまってから冷や汗をかくことは避けたい。経験者ならわかると思うが、sshでログインできなくなってから原因がぼんやりとわかってしまってからの絶望感はほかには代えがたいものがある。

やってしまいがちなミス

sshでアクセスできなくなる理由はいくつもあるが、例えばサーバ側では次のようなケースがある。

  • ファイアウォールの設定を誤った
  • ~/.ssh/authorized_keysファイルの編集を誤った
  • ~/.sshや~/.ssh/authorized_keysのパーミッションが不適切だった

ファイアウォールの設定を変更している時は特に注意が必要だ。疲れてきて自分が設定したフィルタリングルールがわからなくなってくると、「とりあえず一旦クリアしてからもう1回設定するか……」と考えて、全部のアクセスをブロックしてしまうことがある。これをやってしまったらアウトだ。もうどうにもならない。

~/.ssh/authorized_keysファイルを編集して、なぜか該当する公開鍵を削除してしまうケースもある。やっかいなのはchmod 664 *みたいにパーミッションを設定しようとして、これを~/.ssh/で実行してしまうケースだ。~/.ssh/authorized_keysが不適切な状態になると、sshでログインできなくなる。

クライアント側の理由は次のようなものがある。

  • ~/.ssh/*の秘密鍵を誤って削除してしまった
  • ~/.ssh/configファイルの編集を誤った

秘密鍵を削除してしまったらもうダメだ。バックアップを取っていなければ、もうログインできないと諦めたほうがよい。~/.ssh/configの設定のミスはありがちだが、こちらはまだ修復が可能だ。焦らずに原因を探そう。ssh -vvvで情報を多めに表示させれば原因にたどり着きやすいはずだ。

生命線は維持しておこう

ssh系の設定を変更したり、作業したりする時は、まず1本は接続した状態のsshを確保しておくことが望ましい。設定を誤ってログインできなくなっても、すでに接続が確立しているsshは使い続けることができる。フィルタリングの設定を間違えて閉め出されたらおしまいだが、そうでなければなんとかなる。

また、作業はサーバを設置しているデータセンターのサービス窓口や管理者と連絡がつく時間帯に行ったほうがよい。いざとなったら、電話して代わりに作業してもらうことができる。

もし、リモート越しにファイアウォールフィルタリングの設定を編集するのであれば、一定時間経過したら設定を元に戻すような処理をcrontabに仕込んでおくとよい（仕込んだものがブロックするものになっていると、やっぱりアウトだが）。

そして最大の安全策は、そもそもこうした作業は行わないことだ。セットアップの最初の段階でこの辺りの設定はクリアにしておき、使い出してから大幅に書き換える必要がないようにしておこう。sshが接続できなくなった時の絶望感は味わいたくないものだ。