☰

SSSD（LDAP）sudo 密码与基于 ssh 密钥的登录

tag-icon • tag-icon sudo sssd
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 部分：根据 @ognjen 的建议，sudo 和 pam 详细信息：

个人认为：与工作机器相比，它们几乎完全相同。难道不是 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 的日志调查指向

在深入研究日志之后，我发现了一件奇怪的事情。SSSD 的 LDAP 日志与正常工作的机器和停止工作的机器有很大不同。

来自已解散者的日志：https://pastebin.com/05p2KszE 工作日志：https://pastebin.com/t6av2xdy

日志记录，我添加了一些空白行以方便阅读，没有删除任何行。日志对应于一次尝试sudo（重复尝试没有变化）

从日志来看，没有运行密码登录的人似乎基本上只是放弃查找服务

答案1

以下是我的综合清单，希望对您有所帮助：

确保 sssd 响应器套接字已启用，请参阅这里。在虚拟机上全新安装 20.10 服务器后，我注意到随后 apt 安装 sssd、sssd-utils、sssd-dbus 导致所有响应器套接字都被启用。虽然很多次我不得不启用我需要的响应器套接字。

检查证书（客户端和服务器）。请参阅常见问题解答 - LDAP 身份验证失败ldap_tls_reqcert = never。我在 sssd.conf 中注意到我需要 Google LDAPS，因为轻量级目录访问协议需要信噪比而 CentOS 7,8 和 Ubuntu 20.04 没有提供相同的功能，导致 Google 返回了自签名证书。

最后，按照以下步骤深入研究日志SUDO 故障排除。

相关内容