Պատմականորեն, sudo-ի թույլտվությունները ղեկավարվում էին ֆայլերի բովանդակությամբ /etc/sudoers.d и վիզուալ, և հիմնական թույլտվությունն իրականացվել է օգտագործելով ~/.ssh/authorized_keys. Այնուամենայնիվ, քանի որ ենթակառուցվածքները մեծանում են, ցանկություն է առաջանում կառավարել այդ իրավունքները կենտրոնացված կարգով: Այսօր կարող են լինել լուծման մի քանի տարբերակ.
- Կազմաձևման կառավարման համակարգ - Chef, Տիկնիկ, Հղիություն, Աղ
- Active Directory + սսսդ
- Տարբեր այլասերումներ՝ սցենարների և ֆայլերի ձեռքով խմբագրման տեսքով
Իմ սուբյեկտիվ կարծիքով կենտրոնացված կառավարման լավագույն տարբերակը դեռ համադրությունն է Active Directory + սսսդ. Այս մոտեցման առավելություններն են.
- Իսկապես մեկ կենտրոնացված օգտվողի գրացուցակ:
- Իրավունքների բաշխում sudo հանգում է նրան, որ օգտատեր ավելացվի անվտանգության հատուկ խմբին:
- Տարբեր Linux համակարգերի դեպքում անհրաժեշտ է դառնում լրացուցիչ ստուգումներ մտցնել՝ ՕՀ-ն որոշելու համար կոնֆիգուրացիայի համակարգեր օգտագործելիս:
Այսօրվա սյուիտը նվիրված կլինի հատուկ կապին Active Directory + սսսդ իրավունքների կառավարման համար sudo և պահեստավորում ssh բանալիները մեկ պահոցում:
Այսպիսով, դահլիճը սառեցրեց լարված լռության մեջ, դիրիժորը բարձրացրեց մահակը, և նվագախումբը պատրաստվեց։
Գնա։
Տրված է.
— Active Directory տիրույթ testopf.local Windows Server 2012 R2-ում:
— Linux հոսթ, որն աշխատում է Centos 7-ով
— Կազմաձևված թույլտվություն օգտագործելով սսսդ
Երկու լուծումներն էլ փոփոխություններ են կատարում սխեմայի մեջ Active Directory, այնպես որ մենք ամեն ինչ ստուգում ենք թեստային միջավայրում և միայն դրանից հետո փոփոխություններ ենք կատարում աշխատանքային ենթակառուցվածքում: Նշեմ, որ բոլոր փոփոխությունները նպատակային են և, ըստ էության, ավելացնում են միայն անհրաժեշտ ատրիբուտներն ու դասերը։
Գործողություն 1. վերահսկում sudo դերերի միջոցով Active Directory.
Շղթան ընդլայնելու համար Active Directory դուք պետք է ներբեռնեք վերջին թողարկումը
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Մի մոռացեք փոխարինել ձեր արժեքները)
Բացեք adsiedit.msc և միացեք լռելյայն համատեքստին.
Ստեղծեք բաժանում տիրույթի արմատում սուսերոներ. (Բուրժուազիան համառորեն պնդում է, որ հենց այս միավորում է դևը սսսդ որոնում է իր sudoRole առարկաներ. Այնուամենայնիվ, մանրամասն վրիպազերծումը միացնելուց և տեղեկամատյաններն ուսումնասիրելուց հետո պարզվեց, որ որոնումն իրականացվել է ամբողջ գրացուցակում:)
Մենք ստեղծում ենք բաժանման դասին պատկանող առաջին օբյեկտը sudoRole. Անունը կարելի է ընտրել բացարձակապես կամայականորեն, քանի որ այն ծառայում է բացառապես հարմար նույնականացման համար։
Սխեմայի ընդլայնման հնարավոր հասանելի ատրիբուտներից հիմնականները հետևյալն են.
- sudoCommand — որոշում է, թե որ հրամաններն են թույլատրվում կատարել հոսթի վրա:
- sudoHost — որոշում է, թե որ հյուրընկալողներին է վերաբերում այս դերը: Կարող է նշվել որպես ALL, և անհատ հյուրընկալողի համար՝ անունով: Հնարավոր է նաև դիմակ օգտագործել։
- sudoUser — նշեք, թե որ օգտատերերին է թույլատրվում կատարել sudo.
Եթե նշեք անվտանգության խումբ, անվան սկզբում ավելացրեք «%» նշանը: Եթե խմբի անվան մեջ բացատներ կան, անհանգստանալու ոչինչ չկա: Դատելով գերաններից՝ տարածություններից փախչելու գործն իր վրա է վերցնում մեխանիզմը սսսդ.
Նկ 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
Այս մոտեցումը թույլ է տալիս կենտրոնականորեն սահմանել սուդոյի դերերը տարբեր օգտվողների խմբերի համար:
ssh ստեղների պահպանում և օգտագործում Active Directory-ում
Սխեմայի մի փոքր ընդլայնմամբ հնարավոր է ssh ստեղները պահել Active Directory-ի օգտատերերի ատրիբուտներում և օգտագործել դրանք Linux-ի հոսթինգների թույլտվության ժամանակ:
sssd-ի միջոցով թույլտվությունը պետք է կազմաձևվի:
Ավելացրեք անհրաժեշտ հատկանիշը՝ օգտագործելով PowerShell սկրիպտը:
AddsshPublicKeyAttribute.ps1Ֆունկցիա 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';
հատկանիշ Id = $oid;
oMSyntax = 22;
χαρακτηριστικόSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Օգտագործողի հանրային բանալի SSH մուտք գործելու համար';
}
Նոր-ADObject -Name sshPublicKey -Տիպային հատկանիշSchema -Ուղին $schemapath -Այլ ատրիբուտներ $հատկանիշներ
$userSchema = get-adobject -SearchBase $schemapath -Զտիչ 'name -eq «user»'
$userSchema | Set-ADObject -Ավելացնել @{mayContain = 'sshPublicKey'}
Հատկանիշն ավելացնելուց հետո դուք պետք է վերագործարկեք Active Directory Domain Services-ը:
Անցնենք Active Directory-ի օգտատերերին: Մենք կստեղծենք բանալիների զույգ ssh կապի համար՝ օգտագործելով ձեզ հարմար ցանկացած եղանակ:
Մենք գործարկում ենք PuttyGen-ը, սեղմում ենք «Ստեղծել» կոճակը և խելագարորեն տեղափոխում ենք մկնիկը դատարկ տարածքում:
Գործընթացի ավարտից հետո մենք կարող ենք պահպանել հանրային և մասնավոր բանալիները, վերբեռնել հանրային բանալին Active Directory օգտվողի հատկանիշում և վայելել գործընթացը: Այնուամենայնիվ, հանրային բանալին պետք է օգտագործվի «Հանրային բանալի OpenSSH authorized_keys ֆայլում տեղադրելու համար.»:
Ավելացրեք բանալին օգտվողի հատկանիշին:
Տարբերակ 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 արմատի համար:
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Այս օրինակում ադմինիստրատորի հաշիվն օգտագործվում է գրացուցակին միանալու համար: Մարտական պայմաններում պետք է լինի առանձին հաշիվ՝ նվազագույն իրավունքների փաթեթով։
Անձամբ ես շատ շփոթված էի սկրիպտում գաղտնաբառի մաքուր ձևով, չնայած սահմանված իրավունքներին:
Տարբերակային լուծումներ.
- Ես պահպանում եմ գաղտնաբառը առանձին ֆայլում.
echo -n Supersecretpassword > /usr/local/etc/secretpass
- Ես ֆայլի թույլտվությունները սահմանեցի 0500-ի համար root-ի համար
chmod 0500 /usr/local/etc/secretpass
- ldapsearch գործարկման պարամետրերի փոփոխություն՝ պարամետր -w superSecret Գաղտնաբառ Ես փոխում եմ այն -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 daemon-ը սկրիպտի միջոցով հանում է հանրային բանալու արժեքը Active Directory-ում օգտագործողի հատկանիշից և կատարում է թույլտվություն՝ օգտագործելով ստեղները:
- sssd daemon-ը հետագայում նույնականացնում է օգտատիրոջը՝ հիմնվելով խմբի անդամակցության վրա: Ուշադրություն. Եթե սա կազմաձևված չէ, ապա տիրույթի ցանկացած օգտվող մուտք կունենա դեպի հոսթ:
- Երբ փորձում եք սուդո անել, sssd դեյմոնը դերեր է փնտրում Active Directory-ում: Եթե առկա են դերեր, ստուգվում են օգտվողի հատկանիշները և խմբի անդամությունը (եթե sudoRoles-ը կազմաձևված է օգտվողների խմբեր օգտագործելու համար)
Ընդհանուր:
Այսպիսով, բանալիները պահվում են Active Directory-ի օգտատերերի ատրիբուտներում, sudo-ի թույլտվություններում. նմանապես, տիրույթի հաշիվներով Linux հոսթներին մուտքն իրականացվում է Active Directory խմբում անդամակցությունը ստուգելու միջոցով:
Դիրիժորական մահակի վերջին ալիքը, և դահլիճը սառչում է ակնածալից լռության մեջ:
Գրավոր օգտագործվող ռեսուրսները.
Source: www.habr.com