Гістарычна склалася, што sudo правы рэгуляваліся змесцівам файлаў з /etc/sudoers.d и visudo, а аўтарызацыя па ключах вялася з выкарыстаннем ~/.ssh/authorized_keys. Аднак з ростам інфраструктуры ўзнікае жаданне кіраваць гэтымі правамі цэнтралізавана. На сённяшні дзень варыянтаў рашэння можа быць некалькі:
- Сістэма кіравання канфігурацыяй - Шэф-повар, Лялечны, анзибль, Соль
- 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 дэмана. Аўтаматычнае абнаўленне праводзіцца раз у 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.ps1Function New-AttributeID {
$Prefix=«1.2.840.113556.1.8000.2554»
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$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 = New-AttributeID
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'User Public key for SSH login';
}
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 Domain Services.
Пераходзім да карыстальнікаў Active Directory. Любым зручным для Вас спосабам які генеруецца пару ключоў для ssh падлучэння.
Запускаем PuttyGen, націскаем кнопачку «Generate» і сутаргава елазім мышшу ў межах пустой вобласці.
Па завяршэнні працэсу мы можам захаваць публічны і прыватныя ключы, заліць публічны ключ у атрыбут карыстальніка Active Directory і атрымліваць асалоду ад працэсам. Аднак публічны ключ неабходна выкарыстоўваць з акнаPublic key for pasting into OpenSSH authorized_keys file:«.
Дадаем ключ у атрыбут карыстальніка.
Варыянт 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 superSecretPassword мяняю на -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.
Фінальны ўзмах дырыжорскай палачкі - і зала замірае ў поўнае глыбокай пашаны цішыні.
Рэсуры, скарыстаныя пры напісанні:
Крыніца: habr.com