2025年、新年あけましておめでとうございます。本年もどうぞよろしくお願いいたします。
年明けであまり忙しくないうちにと思い、弊社のイントラで使っているFreeBSD 13.3-RELEASEを14.2-RELEASEに移行したところ、アップデート後に「qjail console jailname」でJailのシェルにログインが出来なくなる現象が発生しました。
この記事では皆様に切り分け方と対策を共有しようと思います。
ホスト側でfreebsd-updateやpkg upgrade、qjail update -b後、”qjail restart jailname”をして”qjail console jailname”をしても何のエラー出力も無くJailのシェルにログインができない
14.0-RELEASE以降でopie(4)が廃止されためで、Jail内のベースシステムを13.xからホスト側と同じ14.xにupgradeするとコンテナ内のpam_opie.soが消えて無くなります。
ホスト側のfreebsd-update(8)の時はetcupdate(8)が/etc/pam.d/配下の設定を更新するようお守りをしてくれるのですが、qjailの場合は手動で面倒を見る必要があります。
そのため、freebsd-update直後にJail内へログインしようとすると存在しないpam_opieを読み込もうとしてログインに失敗します。
cat /usr/jails/jailname/var/log/auth.logなどでコンテナ内のログを見るとこのようにログが残っています。
Jan 8 21:16:32 jailname login[27272]: in openpam_load_module(): no pam_opie.so found
“qjail start jailname”で該当Jailをスタート後に”jexec -u root jailname”とするとJail内のシェルにログインすることが出来ます。
コンテナ内の”/etc/pam.d/system”からpam_opieに関する行をコメントアウトする
jailname /root >vi /etc/pam.d/system
#
# $FreeBSD: releng/12.0/lib/libpam/pam.d/system 197769 2009-10-05 09:28:54Z des $
#
# System-wide defaults
#
# auth
#auth sufficient pam_opie.so no_warn no_fake_prompts #ココと
#auth requisite pam_opieaccess.so no_warn allow_local #ココをコメントアウト
#auth sufficient pam_krb5.so no_warn try_first_pass
#auth sufficient pam_ssh.so no_warn try_first_pass
auth required pam_unix.so no_warn try_first_pass nullok
(略)
弊社ではpam_opieを利用していないためコメントアウトしましたが、pam_opieが必要な場合はリリースノートに従ってJailコンテナ内で”security/opie”を導入すると良いと思われます。
sshdやfreeradiusなど、ほかにpam認証を利用していてpam_opieが残っていそうな場合も同様に/etc/pam.d/内の設定ファイルを編集しましょう。
【Blast-RADIUS】対策でfreeradiusがupdateされたためにSoftEtherからのradius認証が失敗する
sysutils/qjail not working properly on RELEASE/14
https://forums.freebsd.org/threads/sysutils-qjail-not-working-properly-on-release-14.91106/
この方は結局”sysutils/bastille”に移行したらしい・・
zfsの機能でコンテナ管理したいことを考えると弊社もqjailからの移行先を探すべきなのかもしれないですね。
FreeBSD 14.0-RELEASE Release Notes
https://www.freebsd.org/releases/14.0R/relnotes/
“Userland Configuration Changes”のあたりでOPIEに関する記述を探してみてください。