从历史上看,sudo权限由
/etc/sudoers.d和
visudo中文件的内容来
控制 ,并且使用
〜/ .ssh / authorized_keys 进行密钥
授权 。 但是,随着基础设施的发展,人们希望集中管理这些权利。 迄今为止,可能有几种解决方案:
- 配置管理系统-Chef , Puppet , Ansible , 盐
- 活动目录 + sssd
- 脚本和手动编辑文件形式的各种变形
以我的主观观点,集中管理的最佳选择仍然是一堆
Active Directory +
sssd 。 这种方法的优点是:
- 真正是一个集中的用户目录。
- 分配sudo权限是关于将用户添加到特定的安全组。
- 对于各种Linux系统,在使用配置系统时,有必要引入其他检查来确定OS。
今天的套件将专用于
Active Directory +
sssd捆绑包,用于管理
sudo权限并将
ssh密钥存储在单个存储库中。
因此,听众在紧张的沉默中僵住了,指挥又举起了魔杖,乐团做好了准备。
走吧
鉴于:
- Windows Server 2012 R2上的Active Directory 域testopf.local 。
- 运行Centos 7的Linux主机
- 使用sssd配置的授权
两种解决方案都对
Active Directory架构进行了更改,因此我们在测试环境中检查所有内容,然后才对工作的基础结构进行更改。 我要指出-所有更改都是基于点的,实际上,仅添加必要的属性和类。
步骤1:通过Active Directory管理sudo角色。
要扩展
Active Directory架构,您需要立即下载最新的
sudo版本-1.8.27。 解压缩,将
schema.ActiveDirectory文件从./doc目录复制到域控制器。 从具有复制文件的目录中的管理员权限的命令行运行:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(不要忘记替换您的价值观)
打开
adsiedit.msc并连接到默认上下文:
在域的根目录下,创建一个
sudoers单元。 (资产阶级顽固地指出,
sssd守护程序正是在此细分中搜索
sudoRole对象。但是,在打开详细的调试并检查了日志之后,发现搜索是在整个目录树中进行的。)
在属于
sudoRole类的单元中创建第一个对象。 该名称可以绝对任意选择,因为它仅用于方便识别。
在模式扩展中可能的可用属性中,主要属性有:
- sudoCommand-确定允许哪些命令在主机上运行。
- sudoHost-确定此角色适用于哪些主机。 可以将其设置为ALL ,也可以将其设置为单个主机的名称。 也可以使用口罩。
- sudoUser-指示允许哪些用户执行sudo 。
如果指定了安全组,请在名称开头添加“%”符号。 如果群组名称中有空格,则无需担心。 从日志来看, sssd机制承担着转义空间的任务。
图1.目录根目录中sudoers单元中的sudoRole对象
图2. sudoRole对象中指定的安全组中的成员资格。在Linux端完成以下配置。
在
/etc/nsswitch.conf文件中,将该行添加到文件末尾:
sudoers: files sss
在
[sssd]部分的
/etc/sssd/sssd.conf文件中,将
sudo添加到服务中
cat /etc/sssd/sssd.conf | grep services services = nss, pam, sudo
完成所有操作后,您需要清除sssd守护程序缓存。 每6个小时会进行一次自动更新,但是为什么现在我们要等待那么多时间。
sss_cache -E
通常,清除缓存无济于事。 然后我们停止服务,清洁底座,然后开始服务。
service sssd stop rm -rf /var/lib/sss/db/* service sssd start
我们在第一个用户下进行连接,并检查其是否可以从sudo下访问:
su user1 [user1@testsshad log]$ id uid=1109801141(user1) gid=1109800513(domain users) groups=1109800513(domain users),1109801132(admins_) [user1@testsshad log]$ sudo -l [sudo] password for user1: Matching Defaults entries for user1 on testsshad: !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User user1 may run the following commands on testsshad: (root) /usr/bin/ls, /usr/bin/cat
我们对第二个用户也是如此:
su user2 [user2@testsshad log]$ id uid=1109801142(user2) gid=1109800513(domain users) groups=1109800513(domain users),1109801138(sudo_root) [user2@testsshad log]$ sudo -l Matching Defaults entries for user2 on testsshad: !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User user2 may run the following commands on testsshad: (root) ALL
这种方法使您可以集中定义不同用户组的sudo角色。
在Active Directory中存储和使用ssh密钥
通过对该方案进行较小的扩展,可以将ssh密钥存储在Active Directory用户属性中,并将其用于Linux主机上的授权。
必须配置通过sssd的授权。
使用PowerShell脚本添加所需的属性。
AddsshPublicKeyAttribute.ps1函数New-AttributeID {
$前缀=“ 1.2.840.113556.1.8000.2554”
$ GUID = [System.Guid] :: NewGuid()。ToString()
$零件= @()
$部分+ = [UInt64] ::解析($ guid.SubString(0.4),“ AllowHexSpecifier”)
$部分+ = [UInt64] ::解析($ guid.SubString(4,4),“ AllowHexSpecifier”)
$部分+ = [UInt64] ::解析($ guid.SubString(9,4),“ AllowHexSpecifier”)
$部分+ = [UInt64] ::解析($ guid.SubString(14,4),“ AllowHexSpecifier”)
$部分+ = [UInt64] ::解析($ guid.SubString(19,4),“ AllowHexSpecifier”)
$部分+ = [UInt64] ::解析($ guid.SubString(24.6),“ AllowHexSpecifier”)
$部分+ = [UInt64] ::解析($ guid.SubString(30.6),“ AllowHexSpecifier”)
$ oid = [String] ::格式(“ {0}。{1}。{2}。{3}。{4}。{5}。{6}。{7}”,$前缀,$份[ 0],
$零件[1],$零件[2],$零件[3],$零件[4],$零件[5],$零件[6])
$ oid
}
$ schemaPath =(Get-ADRootDSE).schemaNamingContext
$ oid =新属性ID
$属性= @ {
lDAPDisplayName ='sshPublicKey';
attributeId = $ oid;
oMSyntax = 22;
attributeSyntax =“ 2.5.5.5”;
isSingleValued = $ true;
adminDescription ='用于SSH登录的用户公共密钥';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Path $ schemapath -OtherAttributes $属性
$ userSchema = get-adobject -SearchBase $ schemapath -Filter'name -eq“ user”'
$ userSchema | Set-ADObject -Add @ {mayContain ='sshPublicKey'}
添加属性后,重新启动Active Directory域服务。
我们传递给Active Directory的用户。 为了您的方便,我们会为ssh连接生成一个密钥对。
启动PuttyGen,单击“生成”按钮,然后在空白区域内疯狂地单击鼠标。
完成该过程后,我们可以保存公钥和私钥,在Active Directory用户属性中填写公钥并享受该过程。 但是,必须从“
用于粘贴到OpenSSHauthorized_keys文件的公共密钥: ”窗口中使用
公共密钥 。

将密钥添加到用户属性。
选项1-GUI:

选项2-PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
现在,我们有了:填充了sshPublicKey属性的用户,配置了密钥授权的Putty客户端。 还有一点,如何使sshd守护程序从用户属性中提取我们需要的公钥。 在资产阶级互联网的开放空间中发现的一个小脚本成功地解决了这一问题。
cat /usr/local/bin/fetchSSHKeysFromLDAP
我们为root设置了0500权限。
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
在此示例中,管理员帐户用于绑定到目录。 在战斗条件下,应该有一个单独的帐户,其权限最少。
尽管设置了权限,但我个人对脚本中纯格式的密码感到困惑。
解决方案选项:
当今套件中的最后一个和弦是编辑sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe" PubkeyAuthentication yes AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP AuthorizedKeysCommandUser root
结果,我们在ssh客户端中配置了密钥身份验证,得到以下序列:
- 用户连接到服务器,并指出他的用户名。
- sshd守护程序通过脚本从Active Directory中的用户属性中提取公钥的值并授权密钥。
- sssd守护程序进一步根据组成员身份对用户进行身份验证。 注意! 如果未配置,则任何域用户都可以访问主机。
- 尝试sudo时,sssd守护程序在Active Directory目录中搜索角色。 如果有角色,则检查组的属性和用户成员资格(如果sudoRoles配置为使用用户组)
总结
因此,密钥存储在Active Directory用户属性,sudo权限中-类似地,通过检查Active Directory组中的成员身份来执行域帐户对Linux主机的访问。
指挥棒的最后一波-大厅冻结在敬畏的寂静中。
书面使用的资源: