ProHoster > Блог > Administracija > Pobjednici međunarodnih takmičenja SSH i sudo ponovo su na sceni. Predvodi istaknuti dirigent Active Directory

Pobjednici međunarodnih takmičenja SSH i sudo ponovo su na sceni. Predvodi istaknuti dirigent Active Directory

Istorijski gledano, sudo dozvole su bile vođene sadržajem datoteka iz /etc/sudoers.d и visado, a autorizacija ključa je izvršena korištenjem ~/.ssh/authorized_keys. Međutim, kako infrastruktura raste, postoji želja da se ovim pravima upravlja centralno. Danas može postojati nekoliko opcija rješenja:

  • Sistem upravljanja konfiguracijom - glava, lutka, Ansible, so
  • Aktivni direktorij + ssd
  • Razne perverzije u obliku skripti i ručnog uređivanja datoteka

Po mom subjektivnom mišljenju, najbolja opcija za centralizovano upravljanje je i dalje kombinacija Aktivni direktorij + ssd. Prednosti ovog pristupa su:

  • Zaista jedan centralizirani korisnički direktorij.
  • Distribucija prava sudo svodi se na dodavanje korisnika određenoj sigurnosnoj grupi.
  • U slučaju različitih Linux sistema, postaje neophodno uvesti dodatne provjere za određivanje OS-a kada se koriste konfiguracijski sistemi.

Današnji paket će biti posebno posvećen povezivanju Aktivni direktorij + ssd za upravljanje pravima sudo i skladištenje ssh ključeve u jednom spremištu.
Dakle, sala se ukočila u napetoj tišini, dirigent je podigao palicu, a orkestar se spremio.
Idi.

S obzirom:
— Active Directory domena testopf.local na Windows Server 2012 R2.
— Linux host koji pokreće Centos 7
— Konfigurisana autorizacija pomoću ssd
Oba rješenja unose promjene u šemu Aktivni direktorij, tako da sve provjeravamo u testnom okruženju i tek onda vršimo promjene u radnoj infrastrukturi. Želio bih napomenuti da su sve promjene ciljane i, zapravo, dodaju samo potrebne atribute i klase.

Akcija 1: kontrola sudo kroz uloge Aktivni direktorij.

Za proširenje kola Aktivni direktorij morate preuzeti najnovije izdanje sudo — 1.8.27 od danas. Raspakujte i kopirajte fajl schema.ActiveDirectory iz ./doc direktorija u kontroler domene. Iz komandne linije s administratorskim pravima iz direktorija u koji je datoteka kopirana, pokrenite:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Ne zaboravite zamijeniti svoje vrijednosti)
Otvori adsiedit.msc i povežite se na zadani kontekst:
Napravite podjelu u korijenu domene džemperi. (Buržoazija tvrdoglavo tvrdi da je u ovoj jedinici demon ssd traži stavku sudoRole objekata. Međutim, nakon uključivanja detaljnog otklanjanja grešaka i proučavanja dnevnika, otkriveno je da je pretraga izvršena u cijelom stablu direktorija.)
Kreiramo prvi objekat koji pripada klasi u diviziji sudoRole. Ime se može izabrati apsolutno proizvoljno, jer služi isključivo za zgodnu identifikaciju.
Među mogućim dostupnim atributima iz ekstenzije sheme, glavni su sljedeći:

  • sudoCommand — određuje koje naredbe se smiju izvršavati na hostu.
  • sudoHost — određuje na koje se hostove ova uloga odnosi. Može se navesti kao SVE, a za pojedinačnog domaćina po imenu. Moguća je i upotreba maske.
  • sudoUser — naznačiti koji korisnici mogu izvršiti sudo.
    Ako navedete sigurnosnu grupu, dodajte znak “%” na početak imena. Ako u nazivu grupe ima razmaka, nema razloga za brigu. Sudeći po logovima, zadatak bijega iz prostora preuzima mehanizam ssd.

Pobjednici međunarodnih takmičenja SSH i sudo ponovo su na sceni. Predvodi istaknuti dirigent Active Directory
Slika 1. Objekti sudoRole u pododjelu sudoers u korijenu direktorija

Pobjednici međunarodnih takmičenja SSH i sudo ponovo su na sceni. Predvodi istaknuti dirigent Active Directory
Slika 2. Članstvo u sigurnosnim grupama navedenim u objektima sudoRole.

Sljedeće podešavanje se vrši na Linux strani.
U fajlu /etc/nsswitch.conf dodajte red na kraj fajla:

sudoers: files sss

U fajlu /etc/sssd/sssd.conf u sekciji [sssd] dodati uslugama sudo

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

Nakon svih operacija, potrebno je da obrišete sssd daemon keš memoriju. Automatska ažuriranja se dešavaju svakih 6 sati, ali zašto bismo čekali toliko dugo kada to želimo sada?

sss_cache -E

Često se dešava da brisanje keša ne pomaže. Zatim zaustavljamo uslugu, čistimo bazu podataka i pokrećemo servis.

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

Povezujemo se kao prvi korisnik i provjeravamo šta mu je dostupno pod 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

Isto radimo i sa našim drugim korisnikom:

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

Ovaj pristup vam omogućava da centralno definirate sudo uloge za različite grupe korisnika.

Pohranjivanje i korištenje ssh ključeva u Active Directory

Uz malo proširenje sheme, moguće je pohraniti ssh ključeve u korisničke atribute Active Directory i koristiti ih prilikom autorizacije na Linux hostovima.

Autorizacija putem sssd-a mora biti konfigurirana.
Dodajte traženi atribut pomoću PowerShell skripte.
AddsshPublicKeyAttribute.ps1Funkcija 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 = Novi ID atributa
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSintaksa = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Korisnički javni ključ za SSH prijavu';
}

Novi-ADObject -Naziv sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}

Nakon dodavanja atributa, morate ponovo pokrenuti Active Directory domenske usluge.
Pređimo na korisnike Active Directory-a. Generisat ćemo par ključeva za ssh konekciju bilo kojom metodom koja vam odgovara.
Pokrećemo PuttyGen, pritisnemo dugme “Generate” i mahnito pomeramo miš unutar praznog područja.
Po završetku procesa možemo sačuvati javni i privatni ključ, učitati javni ključ u korisnički atribut Active Directory i uživati ​​u procesu. Međutim, javni ključ se mora koristiti od "Javni ključ za lijepljenje u OpenSSH authorized_keys fajl:".
Pobjednici međunarodnih takmičenja SSH i sudo ponovo su na sceni. Predvodi istaknuti dirigent Active Directory
Dodajte ključ atributu korisnika.
Opcija 1 - GUI:
Pobjednici međunarodnih takmičenja SSH i sudo ponovo su na sceni. Predvodi istaknuti dirigent Active Directory
Opcija 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Dakle, trenutno imamo: korisnika sa popunjenim atributom sshPublicKey, konfigurisanog Putty klijenta za autorizaciju pomoću ključeva. Ostaje jedna mala stvar: kako natjerati sshd demona da izdvoji javni ključ koji nam je potreban iz korisničkih atributa. Mala skripta pronađena na buržoaskom Internetu može se uspješno nositi s tim.

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'

Postavili smo dozvole za njega na 0500 za root.

chmod 0500  /usr/local/bin/fetchSSHKeysFromLDAP

U ovom primjeru, administratorski račun se koristi za vezivanje za direktorij. U borbenim uslovima mora postojati poseban nalog sa minimalnim skupom prava.
Ja sam lično bio veoma zbunjen trenutkom lozinke u njenom čistom obliku u skripti, uprkos postavljenim pravima.
Opcija rješenja:

  • Sačuvam lozinku u poseban fajl: 
    echo -n Supersecretpassword > /usr/local/etc/secretpass

  • Postavio sam dozvole za fajl na 0500 za root 
    chmod 0500 /usr/local/etc/secretpass

  • Promjena parametara pokretanja ldapsearch: parametar -w superTajna lozinka Ja ga menjam u -y /usr/local/etc/secretpass

Završni akord u današnjem paketu je uređivanje sshd_config

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

Kao rezultat, dobijamo sljedeću sekvencu s autorizacijom ključa konfiguriranom u ssh klijentu:

  1. Korisnik se povezuje na server navodeći svoju prijavu.
  2. Sshd daemon, putem skripte, izdvaja vrijednost javnog ključa iz korisničkog atributa u Active Directory-u i vrši autorizaciju pomoću ključeva.
  3. Sssd daemon dalje autentifikuje korisnika na osnovu članstva u grupi. Pažnja! Ako ovo nije konfigurirano, tada će svaki korisnik domene imati pristup hostu.
  4. Kada pokušate sudo, sssd demon traži uloge u Active Directoryju. Ako su uloge prisutne, provjeravaju se atributi korisnika i članstvo u grupi (ako je sudoRoles konfiguriran da koristi korisničke grupe)

Rezultat.

Dakle, ključevi se pohranjuju u Active Directory korisničkim atributima, sudo dozvolama - slično tome, pristup Linux hostovima po domenskim nalozima vrši se provjerom članstva u Active Directory grupi.
Posljednji zamah dirigentske palice - i dvorana se smrzava u pobožnoj tišini.

Izvori korišteni u pisanju:

Sudo preko Active Directory
Ssh ključevi preko Active Directory
Powershell skripta, dodavanje atributa Active Directory shemi
sudo stabilno izdanje

izvor: www.habr.com

Dodajte komentar