Оказывается, это было что-то несвязанное -DOH.
Для ssh AuthorizedKeysCommand выполнялся пользовательский сценарий bash для извлечения ключей из атрибута LDAP. Он записывал кэшированную версию ключа в домашний каталог пользователя и создавал путь, если он не существовал .
Это, как оказалось, приводило к тому, что pam _mkhomedir никогда не запускался, потому что каталог уже был там, по крайней мере, если я использовал аутентификацию на основе ключа. Таким образом, с pam mkdir вообще не было проблем.
Когда я удалил этот скрипт, он заработал отлично. Теперь я переписал скрипт для хранения кэша ключей ssh вне домашнего каталога, и все работает точно так, как ожидалось.
Просто задокументировал это здесь в качестве напоминания всем, кто может так же застрять, -думать нестандартно и убедиться, что pam _mkhomedir действительно работает, когда должен, особенно когда используются пользовательские сценарии.
Поведение было вызвано systemd
, которое запускает службы в средеunshare
(1 ), если какая-либо из директив InaccessiblePaths
, PrivateMounts
, PrivateTmp
, PrivateDevices
, ProtectSystem
, ProtectHome
, ReadOnlyPaths
или ReadWritePaths
включены в файле tomcat9.service
.
Я вышел из этого, закомментировав любой из них. Вот как теперь выглядит часть безопасности [Service]
:
# Security
User=tomcat
Group=tomcat
# PrivateTmp=yes
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=false
CacheDirectory=tomcat9
CacheDirectoryMode=750
# ProtectSystem=strict
# ReadWritePaths=/etc/tomcat9/Catalina/
# ReadWritePaths=/var/lib/tomcat9/webapps/
# ReadWritePaths=/var/log/tomcat9/
# ReadWritePaths=/path/to/data/
# ReadWritePaths=/path/to/user/
(NoNewPrivileges=false
необходимо для успешного sudo
.)