実行してはいけないLinuxコマンド(25) Linuxサーバにおいてsshで締め出される恐怖 - その4

ssh締め出しストーリー最新版

クラウドの仮想サーバを使う場合、基本的に公開鍵認証を設定したssh経由でログインして作業を行うことになる。このため、仮想サーバを作成する段階で公開鍵を登録するか、またはインストールの初期段階で作業用のアカウントに公開鍵を設置してssh経由でログインできるようにして、あとはそのアカウント経由でインストール作業を行うことになる。

気を張っている時や十分に時間が取れる時は問題ないのだが、セットアップするサーバの数が増えてきたり、疲れてきたり、時間的余裕がなかったりすると、sshで締め出しを喰らうことがある。筆は先日またsshで締め出されてしまったので、その失敗談をお伝えしよう。

コピー時のパーミッションキープ忘れが原因

仮想サーバを使う場合、単一の仮想ディスクを使うこともあるが、オペレーティングシステムの領域は最小限の仮想ディスクにしておき、アプリケーションで利用する領域に別の仮想ディスクを使うといったことを行うことがある。後から高速な仮想ディスクや廉価な仮想ディスクサービスが出るかもしれないし、こうした作りにしておくと、後から新しい仮想ディスクに移行するのが容易だ。利用料金に合わせてディスクサイズの変更なんかもしやすいし、なにかと応用が利くのだ。

次のコマンドは失敗した時の作業を模倣したものだ。新しい仮想ディスクをマウントして使おうとしている。ホームディレクトリ以下にアプリケーション用の領域が用意してあるので(そして公開鍵もここに置いてあった)、ここを一旦/tmp/以下にコピーし、そのあとで新しい仮想ディスクにZFSをセットアップして、それをホームディレクトリの領域にマウントし、最後に退避しておいた/tmp/以下のデータを差し戻し、使えるようにしている。

失敗した作業の模倣

% sudo su -l
Password:
# 
# cp -rp /home/daichi /tmp/
# zpool create z /dev/da2
# zfs create z/home
# zfs set mountpoint=/usr/home z/home
#
# cp -r /tmp/daichi /usr/home/      ← アウトォ！！
# 
# shutdown -r now

問題はデータを戻す時のコマンドだ。上記の方法で/tmp/からホームディレクトリにデータをバックすると、持ち主がすべてrootになってしまう。公開鍵は適切なパーミッションの状態になっていないと読み込まれない。つまり、この状態ではssh経由でログインすることができない。

案の定、次のような感じでssh経由でのログインはできなくなった。

ssh締め出しを喰らったサンプル

ほかにもいくつかの作業を並行して行っていたので、どの作業が問題の原因だったのか整理するまで時間がかかった。しかし、時すでに遅し。ログインできないものはしょうがない。この仮想サーバは捨ててもう一度構築をやり直すことになった。

確認が機能しなかった理由は?

この手の作業を行う時は、システムの再起動やsshdの再起動を行う前に、別のターミナルからssh経由でログインできることを確認することが推奨される。自分もそのプラクティスの重要性は身をもって知っているので、この時も確認は行った。はずなのだが、後から思い返してみると次のうちどれかの失敗をしていた気がする。