Пароль SSSD (LDAP) sudo с входом на основе ключа ssh

Я пытаюсь получить сервер OpenLDAP запуск и запуск небольшого набора серверов. Некоторым пользователям, естественно, нужен доступ root / sudo.

OpenLDAP настроен на использование ssh-ключей для входа в систему с использованием https://github.com/AndriiGrytsenko/openssh-ldap-publickey

Для этой цели на сервере ldap существует группа с именем sudo. Клиенты используют SSSD для установки, все системы работают под управлением Ubuntu Server.

sssd.conf от клиента:

[sssd]
config_file_version = 2
domains = user-server

[domain/user-server]
id_provider = ldap
auth_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://user-server
cache_credentials = False
ldap_search_base = dc=user-server
ldap_sudo_search_base = ou=sudo,dc=user-server

nsswitch.conf

passwd:         files systemd sss
group:          files systemd sss
shadow:         files sss
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files sss
ethers:         db files
rpc:            db files

netgroup:       nis sss
automount:      sss

Похоже, что команда sudo работает, если я ввел пароль для входа по ssh на машине до запуска sudo , но если у меня нет, он будет продолжать спрашивать для пароля, как будто он не ищет пароль.

Если пароль пользователя изменен, это повлияет на все рабочие машины. То же самое, если я удаляю пользователя из группы sudo, он теряет доступ, как ожидалось, и доступ восстанавливается, когда пользователь снова добавляется в группу.

Как мне заставить мой sudo проверять пароль по моему ldap, как ожидалось?

Изменить: комментарий от @ognjen заставил меня немного поискать и понял, что этот журнал может быть полезен:

из auth.log :

Apr  8 14:44:36 client-machine sudo: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory
Apr  8 14:44:40 client-machine sudo: pam_unix(sudo:auth): Couldn't open /etc/securetty: No such file or directory
Apr  8 14:44:40 client-machine sudo: pam_sss(sudo:auth): authentication failure; logname=rohdef uid=10000 euid=0 tty=/dev/pts/1 ruser=rohdef rhost= user=rohdef
Apr  8 14:44:40 client-machine sudo: pam_sss(sudo:auth): received for user rohdef: 9 (Authentication service cannot retrieve authentication info)

Редактировать часть 1: подробности sudo и pam согласно предложению @ognjen:

Personal not: сравнивал их с рабочей машиной, и они практически идентичны. Разве не SSSD должен заботиться о pam и всем, что необходимо поверх слоев, а не sudo? Кто-нибудь может подтвердить?

rohdef@client-machine ~ [1]> ldd (which sudo)
        linux-vdso.so.1 (0x0000ffff91dba000)
        libaudit.so.1 => /lib/aarch64-linux-gnu/libaudit.so.1 (0x0000ffff91d14000)
        libselinux.so.1 => /lib/aarch64-linux-gnu/libselinux.so.1 (0x0000ffff91cdb000)
        libutil.so.1 => /lib/aarch64-linux-gnu/libutil.so.1 (0x0000ffff91cc7000)
        libsudo_util.so.0 => /usr/lib/sudo/libsudo_util.so.0 (0x0000ffff91c9b000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff91b22000)
        /lib/ld-linux-aarch64.so.1 (0x0000ffff91d88000)
        libcap-ng.so.0 => /lib/aarch64-linux-gnu/libcap-ng.so.0 (0x0000ffff91b0d000)
        libpcre2-8.so.0 => /lib/aarch64-linux-gnu/libpcre2-8.so.0 (0x0000ffff91a7f000)
        libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff91a6b000)
        libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff91a3b000)

rohdef@client-machine ~> sudo -V
Sudo version 1.9.1
Sudoers policy plugin version 1.9.1
Sudoers file grammar version 48
Sudoers I/O plugin version 1.9.1
Sudoers audit plugin version 1.9.1

rohdef@client-machine ~> sudo -L
sudo: invalid option -- 'L'
usage: sudo -h | -K | -k | -V
usage: sudo -v [-AknS] [-g group] [-h host] [-p prompt] [-u user]
usage: sudo -l [-AknS] [-g group] [-h host] [-p prompt] [-U user] [-u user] [command]
usage: sudo [-AbEHknPS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] [VAR=value] [-i|-s] [<command>]
usage: sudo -e [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...

Редактировать часть 2: исследования из журналов @ Guser314 указали на

. Покопавшись в журналах, я обнаружил одну любопытную вещь. Журналы для LDAP от SSSD довольно сильно отличаются от работающей и неработающей машины.

Журналы из несуществующего: https://pastebin.com/05p2KszE Журналы из рабочего: https://pastebin.com/t6av2xdy

Запись журнала , Я добавил несколько пустых строк для удобства чтения, ни одна строка не была удалена.Журналы соответствуют ровно одной попытке sudo (нет никаких изменений от повторных попыток)

Судя по журналам, кажется, что тот, у которого не было входа в систему с паролем, в основном просто отказывается от поиска служба