前書き
NISの構築でハマったまま気づかずにいると無限に抜け出せなさそうなある種の落とし穴について書きます。私はかなり長い時間ハマっていました(丸1日くらい)
また、本記事ではNISサーバやNISクライアントの設定について深く突っ込みません。その辺りを詳しく知りたい方は別途調べてください。
サーバーの構成とNISクライアント構成時の参考情報
NISマスターサーバはCentOS 7を使ってもともと構築されていて、NISクライアントをUbuntu18.04を使って設定しようとしていました。CentOSの方にいるユーザの情報を使ってUbuntuにログインするという構成です。
NISクライアントの設定は以下を参考にして実施しました。とても参考になりました。
https://www.server-world.info/query?os=Ubuntu_18.04&p=nis&f=1
なぜログインできなかったのか
これはタイトルの通りで、ユーザ情報に指定されたログインシェルが未インストールだったためです。
NIS設定が正しくてもログインできない
上記リンク先を参考に設定した結果、ypwhich で正しいドメインが表示されるし、ypcat passwd でNISサーバからユーザ情報も正しく持ってこれていて、NISの設定はうまくいっていました。
にもかかわらずログインできない状態でとても不思議だったのですが、結果としてはsshdがログインを拒否していました。
Dec 6 20:50:16 serv sshd[2310]: User user001 not allowed because shell /bin/tcsh does not exist
このログによると「/bin/tcshがいないからuser001のログインは許可できない」とのこと。
そこで、aptをつかってtcshをインストールしてから改めてログインすると、すんなり成功しました。
sudo apt install
諸事情により、NISサーバ(CentOS)では各ユーザのログインシェルが/bin/tcshとなっている環境なのですが、確かに Ubuntu 18.04 インストール直後はtcshが入っていなく、bashがデフォルトの環境でした（もしかしたら特殊かもしれない）。
長時間ハマった理由
ログを見れば一瞬で解決できるのになぜ長時間ハマったかというと、ローカルのpasswdにいるアカウントは普通にSSHログインできたからです。
加えてNISの知識不足もあり、ずっとNISの設定が悪いと思っていたのも理由の一つです。
結局のところしらみつぶしでログを確認し始めてから判明したという感じで、SSHログインのところで問題が発生しているという発想はログを見るまでありませんでした。
まとめ
- NISユーザが指定しているログインシェルはあらかじめインストールしておこう
- ログはちゃんと見ましょう（当たり前）