今年のAdvent Calendarで注目を集めているのが、
だ。自分は宗教行事には参加しない主義なのでAdvent Calendarに記事は書かないが、このシリーズはちょっと見逃せない。で、本稿では12月3日に公開されたこちらの記事を取り上げたいと思う。
トラブルの原因は何か
sshログインできなくなったそもそもの原因は、~/.ssh/authorized_keys へのパーミッションが不適切になってしまったために、sshdがログインを拒否する状態になったということだ。そのきっかけになったのが、クライアント（依頼主）からのCSVファイルの取得依頼だったという流れだった。実験サーバを立てて、これを模してみよう。
[north@sayonara ~]$ chmod og+w /home/north
[north@sayonara ~]$ ls -al
total 28
drwx-w--w- 3 north north 4096 Dec 3 10:38 .
drwxr-xr-x. 4 root root 4096 Dec 3 10:45 ..
-rw------- 1 north north 8 Dec 3 10:37 .bash_history
-rw-r--r-- 1 north north 18 Oct 1 22:26 .bash_logout
-rw-r--r-- 1 north north 141 Oct 1 22:26 .bash_profile
-rw-r--r-- 1 north north 312 Oct 1 22:26 .bashrc
drwx------ 2 north north 4096 Dec 3 10:38 .ssh
[north@sayonara ~]$ ls -al .ssh
total 12
drwx------ 2 north north 4096 Dec 3 10:38 .
drwx-w--w- 3 north north 4096 Dec 3 10:38 ..
-rw------- 1 north north 1524 Dec 3 10:38 authorized_keys注目していただきたいのは、.sshディレクトリもauthorized_keysファイルもパーミッションはいじっていないということだ。実はsshdではStrictModesというオプションがデフォルトでONになっていて、ホームディレクトリにgroupまたはotherに対してwriteableだとログインできない仕様になっている。sshd(8)には、こう書いてある。
~/.ssh/authorized_keys
Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used
for logging in as this user. The format of this file is
described above. The content of the file is not highly sensi‐
tive, but the recommended permissions are read/write for the
user, and not accessible by others.
If this file, the ~/.ssh directory, or the user's home directory
are writable by other users, then the file could be modified or
replaced by unauthorized users. In this case, sshd will not
allow it to be used unless the StrictModes option has been set to
“no”.つまりホームディレクトリに不要なwriteを付けた時点でNGなのだ。というわけで、この時点で新規にログインできないようになってしまう。
どうやって復帰させるか
記事によると「シングルユーザーモードから復帰させた」とある。まずはこれを試してみよう。
Linux（CentOS8）のシングルブート
シングルユーザでブートするには、最低限コンソール・アクセスが必要だ。たとえばさくらのクラウドでは、仮想コンソールが用意されている。仮想のVGAディスプレイとキーボードで、VMにアクセスできる。仮想キーボードから、CTRL+ALT+DELを送信できるので、これでリブートする。
するとおなじみのブート画面がでてくる。
カウントダウンが始まるので、すかさず e を押す。するとブートコマンドを入力できるようになる。
さくらのクラウドが提供するCentOS8のパブリックアーカイブでは下記のようにカスタマイズされているが、だいたいどのブートコマンドでも「linux」で始まる行があり、「ro」という文字列を含んでいるはずだ。
そのroから後ろをカットして、「rw init=/bin/sh」と書き換える。
できたら CTRL+X を押してブートする。うまくいけば、shが起動してコマンドラインに落ちる。
chmodを使ってホームディレクトリのパーミッションを戻せば完了だ。
なお、このモードではリブートコマンドが使えないので、コントロールパネルから強制リブートすることになる。リブートすれば元通りなので、普通にログイン可能になっているはずだ。
【2019年12月4日追記】
やまけんさんからご指摘をいただいた。
実際に single-mode で exec /sbin/init すると一端ブートしてログインプロンプトが出るので、ここでCTRL+ALT+DELで再起動する、という手順がよさそうだ。情報ありがとうございます。
rootでログインした方が手っ取り早い、がしかし。
さて、実はコンソールが操作できるのなら、rootでログインしてchmodを実行すればすんなり復帰できそうなものだ。どうしてクライアントはそれをやらなかったのだろうか。rootパスワードを知らないのか、あるいはrootログインを禁止しているのだろうか。
もしコントロールパネルにアクセスできるならば、実質的にはroot権限よりもかなり大きな特権を保有していることになる。というのはコンパネから実行できる権限は、rootに比べたらはるかに大きいからだ。ご覧いただいた通り、パスワードなしでサーバにログインできてしまうほど大きな特権なのだ。だからrootのパスワードを教えないとか、rootログインを禁じるのは、この状況ではナンセンスだ。
しかしシングルモードのログインを選択したということは、クライアント（依頼主）はパスワードを知らなかった、ということになる。この種の現場では、こういうことはあり得る、と思う。まあそのためにこのようなハックが存在するわけであるが…。手間暇かかってあまりいいことはないように思う。