ProHoster > Blogs > Administrācija > Uz skatuves atkal ir starptautisko konkursu SSH un sudo uzvarētāji. Vada izcilais Active Directory diriģents

Uz skatuves atkal ir starptautisko konkursu SSH un sudo uzvarētāji. Vada izcilais Active Directory diriģents

Vēsturiski sudo atļaujas regulēja failu saturs no /etc/sudoers.d Šø Visudo, un atslēgas autorizācija tika veikta, izmantojot ~/.ssh/authorized_keys. Taču, infrastruktÅ«rai augot, rodas vēlme Ŕīs tiesÄ«bas pārvaldÄ«t centralizēti. Å odien var bÅ«t vairākas risinājuma iespējas:

  • Konfigurācijas pārvaldÄ«bas sistēma - Å efpavārs, marionete, Iespējams, sāls
  • Active Directory + ssd
  • Dažādas perversijas skriptu un manuālas failu rediģēŔanas veidā

Manuprāt, vislabākais centralizētās pārvaldÄ«bas variants joprojām ir kombinācija Active Directory + ssd. Å Ä«s pieejas priekÅ”rocÄ«bas ir:

  • PatieŔām viens centralizēts lietotāju direktorijs.
  • TiesÄ«bu sadale sudo Tas ir saistÄ«ts ar lietotāja pievienoÅ”anu noteiktai droŔības grupai.
  • Dažādu Linux sistēmu gadÄ«jumā, izmantojot konfigurācijas sistēmas, kļūst nepiecieÅ”ams ieviest papildu pārbaudes, lai noteiktu OS.

Å odienas komplekts bÅ«s Ä«paÅ”i veltÄ«ts savienojumam Active Directory + ssd tiesÄ«bu pārvaldÄ«bai sudo un uzglabāŔana ssh atslēgas vienā repozitorijā.
Tā zāle sastinga saspringtā klusumā, diriģents pacēla zizli, un orķestris gatavojās.
Iesim.

Ņemot vērā:
ā€” Active Directory domēns testopf.local operētājsistēmā Windows Server 2012 R2.
ā€” Linux resursdators, kurā darbojas Centos 7
ā€” Konfigurēta autorizācija, izmantojot ssd
Abi risinājumi veic izmaiņas shēmā Active Directory, tāpēc mēs visu pārbaudām testa vidē un tikai pēc tam veicam izmaiņas darba infrastruktÅ«rā. Es vēlos atzÄ«mēt, ka visas izmaiņas ir mērÄ·tiecÄ«gas un faktiski pievieno tikai nepiecieÅ”amos atribÅ«tus un klases.

1. darbība: kontrole sudo lomas cauri Active Directory.

Lai paplaÅ”inātu ķēdi Active Directory jums ir nepiecieÅ”ams lejupielādēt jaunāko versiju sudo ā€” 1.8.27 no Å”odienas. Izpakojiet un kopējiet failu schema.ActiveDirectory no direktorija ./doc uz domēna kontrolleri. Komandrindā ar administratora tiesÄ«bām no direktorija, kurā fails tika kopēts, palaidiet:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Neaizmirstiet aizstāt savas vērtības)
Atvērt adsiedit.msc un izveidojiet savienojumu ar noklusējuma kontekstu:
Izveidojiet sadalÄ«jumu domēna saknē sudoers. (Buržuāzija spÄ«tÄ«gi apgalvo, ka tieÅ”i Å”ajā vienÄ«bā dēmons ssd meklē preci sudoRole objektus. Tomēr pēc detalizētas atkļūdoÅ”anas ieslēgÅ”anas un žurnālu izpētes atklājās, ka meklÄ“Å”ana tika veikta visā direktoriju kokā.)
Mēs izveidojam pirmo objektu, kas pieder klasei sadalījumā sudoRole. Vārdu var izvēlēties absolūti patvaļīgi, jo tas kalpo tikai ērtai identifikācijai.
Starp iespējamiem shēmas paplaÅ”inājuma pieejamajiem atribÅ«tiem galvenie ir Ŕādi:

  • sudoCommand ā€” nosaka, kuras komandas ir atļauts izpildÄ«t resursdatorā.
  • sudoHost ā€” nosaka, uz kuriem saimniekiem Ŕī loma attiecas. Var norādÄ«t kā VISS, un individuālam saimniekdatoram pēc nosaukuma. Ir iespējams arÄ« izmantot masku.
  • sudoUser ā€” norāda, kuriem lietotājiem ir atļauts izpildÄ«t sudo.
    Ja norādāt droŔības grupu, nosaukuma sākumā pievienojiet zÄ«mi ā€œ%ā€. Ja grupas nosaukumā ir atstarpes, nav par ko uztraukties. Spriežot pēc baļķiem, uzdevumu izbēgt no telpām pārņem mehānisms ssd.

Uz skatuves atkal ir starptautisko konkursu SSH un sudo uzvarētāji. Vada izcilais Active Directory diriģents
1. att. sudoRole objekti sudoers apakÅ”nodaļā direktorija saknē

Uz skatuves atkal ir starptautisko konkursu SSH un sudo uzvarētāji. Vada izcilais Active Directory diriģents
2. attēls. DalÄ«ba droŔības grupās, kas norādÄ«tas sudoRole objektos.

Tālāk norādÄ«tā iestatÄ«Å”ana tiek veikta Linux pusē.
Failā /etc/nsswitch.conf pievienojiet rindiņu faila beigās:

sudoers: files sss

Failā /etc/sssd/sssd.conf sadaļā [sssd] pievienot pakalpojumiem sudo

cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo

Pēc visām darbÄ«bām jums ir jāiztÄ«ra sssd dēmona keÅ”atmiņa. Automātiski atjauninājumi notiek ik pēc 6 stundām, bet kāpēc mums bÅ«tu jāgaida tik ilgi, ja mēs to vēlamies tagad?

sss_cache -E

Bieži gadās, ka keÅ”atmiņas notÄ«rÄ«Å”ana nepalÄ«dz. Pēc tam mēs pārtraucam pakalpojumu, iztÄ«rām datu bāzi un sākam pakalpojumu.

service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start

Mēs izveidojam savienojumu kā pirmais lietotājs un pārbaudām, kas viņam ir pieejams zem 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

Mēs darām to paÅ”u ar savu otro lietotāju:

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

Šī pieeja ļauj centralizēti definēt sudo lomas dažādām lietotāju grupām.

Ssh atslēgu glabāŔana un izmantoÅ”ana Active Directory

Nedaudz paplaÅ”inot shēmu, ir iespējams glabāt ssh atslēgas Active Directory lietotāja atribÅ«tos un izmantot tos, veicot autorizāciju Linux resursdatoros.

Jākonfigurē autorizācija, izmantojot sssd.
Pievienojiet nepiecieŔamo atribūtu, izmantojot PowerShell skriptu.
AddsshPublicKeyAttribute.ps1Funkcija New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$Parts+=[UInt64]::Parsēt($guid.SubString(0,4),ā€œAllowHexSpecifierā€)
$Parts+=[UInt64]::Parsēt($guid.SubString(4,4),ā€œAllowHexSpecifierā€)
$Parts+=[UInt64]::Parsēt($guid.SubString(9,4),ā€œAllowHexSpecifierā€)
$Parts+=[UInt64]::Parsēt($guid.SubString(14,4),ā€œAllowHexSpecifierā€)
$Parts+=[UInt64]::Parsēt($guid.SubString(19,4),ā€œAllowHexSpecifierā€)
$Parts+=[UInt64]::Parsēt($guid.SubString(24,6),ā€œAllowHexSpecifierā€)
$Parts+=[UInt64]::Parsēt($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 = jauns atribūta ID
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
atribūtiId = $oid;
oMSintakse = 22;
atribūtiSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Lietotāja publiskā atslēga SSH pieteikÅ”anai';
}

Jauns-ADObject -Nosaukums sshPublicKey -Type atribūtiSchema -CeļŔ $schemapath -Citi atribūti $atribūti
$userSchema = get-adobject - SearchBase $schemapath - Filtrs 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}

Pēc atribÅ«ta pievienoÅ”anas jums ir jārestartē Active Directory domēna pakalpojumi.
Pāriesim pie Active Directory lietotājiem. Mēs ģenerēsim atslēgu pāri ssh savienojumam, izmantojot jebkuru jums ērtu metodi.
Mēs palaižam PuttyGen, nospiežam pogu ā€œÄ¢enerētā€ un izmisÄ«gi pārvietojam peli tukÅ”ajā apgabalā.
Pēc procesa pabeigÅ”anas mēs varam saglabāt publisko un privāto atslēgu, augÅ”upielādēt publisko atslēgu Active Directory lietotāja atribÅ«tā un izbaudÄ«t procesu. Tomēr publiskā atslēga ir jāizmanto no "Publiskā atslēga ielÄ«mÄ“Å”anai OpenSSH authorised_keys failā:".
Uz skatuves atkal ir starptautisko konkursu SSH un sudo uzvarētāji. Vada izcilais Active Directory diriģents
Pievienojiet atslēgu lietotāja atribūtam.
1. iespēja ā€” GUI:
Uz skatuves atkal ir starptautisko konkursu SSH un sudo uzvarētāji. Vada izcilais Active Directory diriģents
2. iespēja ā€” PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Tātad paÅ”laik mums ir: lietotājs ar aizpildÄ«tu atribÅ«tu sshPublicKey, konfigurēts Putty klients autorizācijai, izmantojot atslēgas. Joprojām ir viens mazs jautājums: kā piespiest sshd dēmonu iegÅ«t mums nepiecieÅ”amo publisko atslēgu no lietotāja atribÅ«tiem. Neliels buržuāziskajā internetā atrasts skripts ar to var veiksmÄ«gi tikt galā.

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'

Mēs iestatījām tā atļaujas uz 0500 root.

chmod 0500  /usr/local/bin/fetchSSHKeysFromLDAP

Å ajā piemērā, lai izveidotu saiti ar direktoriju, tiek izmantots administratora konts. Cīņas apstākļos ir jābÅ«t atseviŔķam kontam ar minimālu tiesÄ«bu kopumu.
Mani personīgi ļoti mulsināja paroles mirklis tīrā veidā skriptā, neskatoties uz noteiktajām tiesībām.
Risinājuma variants:

  • Es saglabāju paroli atseviŔķā failā: 
    echo -n Supersecretpassword > /usr/local/etc/secretpass

  • Es iestatÄ«ju faila atļaujas uz 0500 root 
    chmod 0500 /usr/local/etc/secretpass

  • Ldapsearch palaiÅ”anas parametru maiņa: parametrs -w superSecretPassword Es to mainu uz -y /usr/local/etc/secretpass

Pēdējais akords Å”odienas komplektā ir sshd_config rediģēŔana

cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root

Rezultātā mēs iegÅ«stam Ŕādu secÄ«bu ar atslēgas autorizāciju, kas konfigurēta ssh klientā:

  1. Lietotājs izveido savienojumu ar serveri, norādot savu pieteikŔanos.
  2. Sshd dēmons, izmantojot skriptu, izvelk publiskās atslēgas vērtību no Active Directory lietotāja atribūta un veic autorizāciju, izmantojot atslēgas.
  3. Sssd dēmons tālāk autentificē lietotāju, pamatojoties uz dalību grupā. Uzmanību! Ja tas nav konfigurēts, jebkuram domēna lietotājam būs piekļuve resursdatoram.
  4. Mēģinot veikt sudo, sssd dēmons Active Directory meklē lomas. Ja lomas ir klāt, tiek pārbaudÄ«ti lietotāja atribÅ«ti un dalÄ«ba grupā (ja sudoRoles ir konfigurēts lietotāju grupu lietoÅ”anai)

Kopsavilkums.

Tādējādi atslēgas tiek glabātas Active Directory lietotāju atribūtos, sudo atļaujās - līdzīgi domēna kontu piekļuve Linux saimniekiem tiek veikta, pārbaudot dalību Active Directory grupā.
Pēdējais diriÄ£enta pulciņa vilnis ā€“ un zāle sastingst godbijÄ«gā klusumā.

Rakstniecībā izmantotie resursi:

Sudo, izmantojot Active Directory
Ssh atslēgas, izmantojot Active Directory
Powershell skripts, pievienojot atribūtu Active Directory shēmai
sudo stabila izlaiŔana

Avots: www.habr.com

Pievieno komentāru