В исторически план разрешенията на sudo се управляват от съдържанието на файловете от /etc/sudoers.d и visudoи упълномощаването на ключ е извършено с помощта на ~/.ssh/authorized_keys. С нарастването на инфраструктурата обаче възниква желание тези права да се управляват централно. Днес може да има няколко варианта за решение:
- Система за управление на конфигурацията - Главният ни готвач, Кукла на конци, Ansible, Сол
- Active Directory + ssd
- Различни извращения под формата на скриптове и ръчно редактиране на файлове
По мое субективно мнение най-добрият вариант за централизирано управление все още е комбинацията Active Directory + ssd. Предимствата на този подход са:
- Наистина една централизирана потребителска директория.
- Разпределение на права Sudo се свежда до добавяне на потребител към определена група за сигурност.
- В случай на различни Linux системи става необходимо да се въведат допълнителни проверки за определяне на операционната система, когато се използват конфигурационни системи.
Днешният пакет ще бъде посветен специално на връзката Active Directory + ssd за управление на правата Sudo и съхранение SSH ключове в едно хранилище.
И така, залата застина в напрегната тишина, диригентът вдигна палката, а оркестърът се приготви.
Да вървим.
Като се има предвид:
— Домейн на Active Directory testopf.local на Windows Server 2012 R2.
— Linux хост, работещ с Centos 7
— Конфигурирано оторизиране чрез ssd
И двете решения правят промени в схемата Active Directory, така че проверяваме всичко в тестова среда и едва след това правим промени в работещата инфраструктура. Бих искал да отбележа, че всички промени са целеви и всъщност добавят само необходимите атрибути и класове.
Действие 1: контрол Sudo роли чрез Active Directory.
За разширяване на веригата Active Directory трябва да изтеглите най-новата версия — 1.8.27 от днес. Разопаковайте и копирайте файла schema.ActiveDirectory от директорията ./doc към домейн контролера. От командния ред с администраторски права от директорията, в която е копиран файлът, изпълнете:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Не забравяйте да замените вашите стойности)
отворено adsiedit.msc и се свържете с контекста по подразбиране:
Създайте разделение в основата на домейна sudoers. (Буржоазията упорито твърди, че именно в тази единица демонът ssd търси артикул sudoRole обекти. Въпреки това, след включване на подробно отстраняване на грешки и изучаване на регистрационните файлове, беше разкрито, че търсенето е извършено в цялото дърво на директорията.)
Създаваме първия обект, принадлежащ към класа в разделянето sudoRole. Името може да бъде избрано абсолютно произволно, тъй като служи единствено за удобна идентификация.
Сред възможните налични атрибути от разширението на схемата основните са следните:
- sudoCommand — определя кои команди са разрешени за изпълнение на хоста.
- sudoHost — определя за кои хостове се прилага тази роля. Може да се посочи като ALL, а за отделен хост по име. Възможно е и използването на маска.
- sudoUser — посочете на кои потребители е разрешено да изпълняват Sudo.
Ако зададете група за сигурност, добавете знак „%“ в началото на името. Ако в името на групата има интервали, няма за какво да се притеснявате. Съдейки по трупите, задачата за бягство от пространства се поема от механизма ssd.
Фигура 1. Обекти sudoRole в подразделение sudoers в корена на директорията
Фигура 2. Членство в групи за сигурност, посочени в sudoRole обекти.
Следната настройка се извършва от страна на Linux.
Във файла /etc/nsswitch.conf добавете реда в края на файла:
sudoers: files sssВъв файла /etc/sssd/sssd.conf в раздел [sssd] добавете към услугите Sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
След всички операции трябва да изчистите кеша на sssd daemon. Автоматичните актуализации се извършват на всеки 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 роли за различни потребителски групи.
Съхраняване и използване на ssh ключове в Active Directory
С леко разширяване на схемата е възможно да се съхраняват ssh ключове в потребителските атрибути на Active Directory и да се използват при оторизиране на Linux хостове.
Упълномощаването чрез sssd трябва да бъде конфигурирано.
Добавете необходимия атрибут с помощта на скрипт на PowerShell.
AddsshPublicKeyAttribute.ps1Функция New-AttributeID {
$Префикс="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Части=@()
$Parts+=[UInt64]::Parse($guid.SubString(0,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(4,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(9,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(14,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(19,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(24,6),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(30,6),“AllowHexSpecifier”)
$oid=[String]::Format(«{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}»,$prefix,$Parts[0],
$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = Нов идентификатор на атрибут
$атрибути = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Потребителски публичен ключ за влизане в SSH';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
След като добавите атрибута, трябва да рестартирате домейн услугите на Active Directory.
Нека да преминем към потребителите на Active Directory. Ние ще генерираме двойка ключове за ssh връзка по всеки удобен за вас метод.
Стартираме PuttyGen, натискаме бутона „Генериране“ и трескаво движим мишката в празната област.
След завършване на процеса можем да запазим публичния и частния ключ, да качим публичния ключ в потребителския атрибут на Active Directory и да се насладим на процеса. Публичният ключ обаче трябва да се използва от "Публичен ключ за поставяне във файл Authorized_keys на OpenSSH:".
Добавете ключа към потребителския атрибут.
Вариант 1 - GUI:
Вариант 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
И така, в момента имаме: потребител с попълнен атрибут sshPublicKey, конфигуриран Putty клиент за оторизация чрез ключове. Остава една малка точка: как да принудим sshd демона да извлече публичния ключ, от който се нуждаем, от атрибутите на потребителя. Малък скрипт, намерен в буржоазния интернет, може успешно да се справи с това.
cat /usr/local/bin/fetchSSHKeysFromLDAP
#!/bin/sh
ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D [email protected] -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/n *//g;s/sshPublicKey: //gp'Зададохме разрешенията за него на 0500 за root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
В този пример се използва администраторски акаунт за свързване към директорията. В бойни условия трябва да има отделен акаунт с минимален набор от права.
Аз лично бях много объркан от момента на паролата в чист вид в скрипта, въпреки зададените права.
Опция за решение:
- Записвам паролата в отделен файл:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Зададох разрешения за файлове на 0500 за root
chmod 0500 /usr/local/etc/secretpass - Промяна на параметрите за стартиране на ldapsearch: параметър -w суперсекретна парола Променям го на -y /usr/local/etc/secretpass
Последният акорд в днешния пакет е редактирането на 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 - по същия начин достъпът до хостове на Linux чрез акаунти на домейн се осъществява чрез проверка на членството в групата на Active Directory.
Последното помахване на палката на диригента - и залата застива в благоговейна тишина.
Ресурси, използвани в писмен вид:
Източник: www.habr.com