シェルの扱いには要注意
sshでログインできなくなるのは、何もファイアウォールの設定を間違えるとか、~/.ssh以下のパーミッションを間違えるとか、そういったことだけではなく発生する。気をつけておきたいのはデフォルトシェルの変更だ。
Linux系のディストリビューションは、デフォルトシェルにbashを採用していることが多い（/bin/bash）。bashをそのままインタラクティブシェルとして使っている場合、こうした問題は生じにくいのだが、別のシェルに変更していると思わぬところで落とし穴にハマる可能性がある。
例えば、以下のユーザーはデフォルトシェルをfishに変更している。fishはそれほどメジャーなインタラクティブシェルではないが、後発のシェルの1つで、とにかくデフォルトの状態で扱いやすい。Ctrl-Fを押すという操作だけ覚えておけば、かなり賢い補完が機能するので便利なのだ。
デフォルトシェルをfishに変更しているユーザー
daichi@ubuntu1804 ~> chsh
パスワード:
Changing the login shell for daichi
Enter the new value, or press ENTER for the default
Login Shell [/usr/bin/fish]:
daichi@ubuntu1804 ~>
この状態でシステムからfishをアンインストールしてみる。
ユーザーがデフォルトシェルに設定しているシェルをアンインストール
root@ubuntu1804 ~# apt remove fish
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
以下のパッケージが自動でインストールされましたが、もう必要とされていません:
fish-common libpcre2-32-0
これを削除するには 'apt autoremove' を利用してください。
以下のパッケージは「削除」されます:
fish
アップグレード: 0 個、新規インストール: 0 個、削除: 1 個、保留: 0 個。
この操作後に 3,824 kB のディスク容量が解放されます。
続行しますか? [Y/n]
(データベースを読み込んでいます ... 現在 146418 個のファイルとディレクトリがインストールされています。)
fish (2.7.1-3) を削除しています ...
root@ubuntu1804 ~#
こうするとどうなるかというと、当然だがそのユーザーはssh経由でログインできなくなる。プロンプトにはログインできない理由として「Permission denied」と表示されるために、どんな理由でログインできなくなったか、予想もできないだろう。
-
デフォルトシェルが消えると当然ログインできなくなる
アンインストールされたシェルを再度インストールすると、次のようにもう一度ssh経由でログインできるようになる。
-
アンインストールしたシェルを再インストールすると、再度ログインできるようになる
こんな感じで、シェルのアンインストールを行う時は注意が必要だ。ローカルにサーバが設置されているならまだしも、データセンターやパブリッククラウドのIaaSのサーバにログインして作業する時は特に注意しなければならない。
インストールやアンインストールを繰り返して環境がごちゃごちゃしてきたと感じた時は、パッケージをまるっとアンインストールして最初から構築し直したいと考えるかもしれない。しかし、そんな時でもシェルの扱いにだけは注意しておこう。ログインできなくなると、かなり困ったことになる。
