ProHoster > Blog > uprava > Pobjednici međunarodnih natjecanja SSH i sudo ponovno su na pozornici. Vodi istaknuti voditelj Active Directory-a

Pobjednici međunarodnih natjecanja SSH i sudo ponovno su na pozornici. Vodi istaknuti voditelj Active Directory-a

Povijesno gledano, dopuštenjima za sudo upravljao je sadržaj datoteka iz /etc/sudoers.d и visado, a autorizacija ključa provedena je pomoću ~/.ssh/ovlašteni_ključevi. Međutim, kako infrastruktura raste, postoji želja da se tim pravima upravlja centralno. Danas može postojati nekoliko opcija rješenja:

  • Sustav upravljanja konfiguracijom - Kuhar, Lutka, Ansible, Sol
  • Active Directory + ssd
  • Razne perverzije u obliku skripti i ručnog uređivanja datoteka

Po mom subjektivnom mišljenju, najbolja opcija za centralizirano upravljanje još uvijek je kombinacija Active Directory + ssd. Prednosti ovog pristupa su:

  • Doista jedan centralizirani korisnički imenik.
  • Raspodjela prava sudo svodi se na dodavanje korisnika u određenu sigurnosnu grupu.
  • U slučaju različitih Linux sustava, postaje potrebno uvesti dodatne provjere za određivanje OS-a pri korištenju konfiguracijskih sustava.

Današnji paket bit će posvećen upravo vezi Active Directory + ssd za upravljanje pravima sudo i skladištenje ssh ključeve u jednom repozitoriju.
Tako je dvorana zastala u napetoj tišini, dirigent je podigao palicu, a orkestar se spremio.
Ići.

dati:
— domena aktivnog imenika testopf.lokalni na Windows Server 2012 R2.
— Linux host koji pokreće Centos 7
— Konfigurirana autorizacija korištenjem ssd
Oba rješenja mijenjaju shemu Active Directory, dakle sve provjeravamo u testnom okruženju i tek onda radimo izmjene na radnoj infrastrukturi. Želio bih napomenuti da su sve promjene ciljane i zapravo dodaju samo potrebne atribute i klase.

Radnja 1: kontrola sudo uloge kroz Active Directory.

Za proširenje kruga Active Directory morate preuzeti najnovije izdanje sudo — 1.8.27 od danas. Raspakirajte i kopirajte datoteku shema.ActiveDirectory iz direktorija ./doc u kontroler domene. Iz naredbenog retka 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)
Otvoreno adsiedit.msc i spojite se na zadani kontekst:
Napravite odjeljak u korijenu domene džemperi. (Buržoazija tvrdoglavo tvrdi da je u ovoj jedinici demon ssd traži stavku sudoRole objekti. Međutim, nakon uključivanja detaljnog otklanjanja pogrešaka i proučavanja zapisa, otkriveno je da je pretraga izvršena kroz cijelo stablo imenika.)
Kreiramo prvi objekt koji pripada klasi u diviziji sudoRole. Ime se može odabrati apsolutno proizvoljno, jer služi isključivo za prikladnu identifikaciju.
Među mogućim dostupnim atributima iz proširenja sheme, glavni su sljedeći:

  • sudoCommand — određuje koje se naredbe smiju izvršavati na glavnom računalu.
  • sudoHost — određuje na koje se hostove ova uloga odnosi. Može se odrediti kao SVE, a za pojedinog domaćina imenom. Također je moguće koristiti masku.
  • sudoUser — označite koji korisnici smiju izvršiti sudo.
    Ako navedete sigurnosnu grupu, dodajte znak "%" na početku naziva. Ako u nazivu grupe ima razmaka, nema razloga za brigu. Sudeći po zapisima, zadatak bježanja iz prostora preuzima mehanizam ssd.

Pobjednici međunarodnih natjecanja SSH i sudo ponovno su na pozornici. Vodi istaknuti voditelj Active Directory-a
Slika 1. objekti sudoRole u pododjeljku sudoers u korijenu direktorija

Pobjednici međunarodnih natjecanja SSH i sudo ponovno su na pozornici. Vodi istaknuti voditelj Active Directory-a
Slika 2. Članstvo u sigurnosnim grupama navedenim u sudoRole objektima.

Sljedeće postavljanje se vrši na strani Linuxa.
U spisu /etc/nsswitch.conf dodajte redak na kraj datoteke:

sudoers: files sss

U spisu /etc/sssd/sssd.conf u odjeljku [sssd] dodati uslugama sudo

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

Nakon svih operacija morate očistiti predmemoriju sssd demona. Automatsko ažuriranje događa se svakih 6 sati, ali zašto bismo čekali toliko dugo kada to želimo sada?

sss_cache -E

Često se događa da brisanje predmemorije ne pomaže. Zatim zaustavljamo uslugu, čistimo bazu podataka i pokrećemo uslugu.

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

Spajamo se kao prvi korisnik i provjeravamo što 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 s 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 vam pristup omogućuje centralno definiranje sudo uloga za različite grupe korisnika.

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

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

Mora biti konfigurirana autorizacija putem sssd-a.
Dodajte traženi atribut pomoću skripte PowerShell.
AddsshPublicKeyAttribute.ps1Funkcija New-AttributeID {
$Prefiks="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 = ID novog atributa
$atributi = @{
lDAPDisplayName = 'sshPublicKey';
atributId = $oid;
oMSintaksa = 22;
atributSintaksa = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Korisnički javni ključ za SSH prijavu';
}

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'}

Nakon dodavanja atributa, morate ponovno pokrenuti Active Directory Domain Services.
Prijeđimo na korisnike Active Directoryja. Generirati ćemo par ključeva za ssh vezu bilo kojom metodom koja vam odgovara.
Pokrećemo PuttyGen, pritisnemo tipku “Generate” i mahnito pomičemo miš unutar praznog područja.
Po završetku procesa možemo spremiti javni i privatni ključ, učitati javni ključ u korisnički atribut Active Directory i uživati ​​u procesu. Međutim, javni ključ mora se koristiti od "Javni ključ za lijepljenje u datoteku Authorized_keys OpenSSH:”.
Pobjednici međunarodnih natjecanja SSH i sudo ponovno su na pozornici. Vodi istaknuti voditelj Active Directory-a
Dodajte ključ korisničkom atributu.
Opcija 1 - GUI:
Pobjednici međunarodnih natjecanja SSH i sudo ponovno su na pozornici. Vodi istaknuti voditelj Active Directory-a
Opcija 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Dakle, trenutno imamo: korisnika s popunjenim atributom sshPublicKey, konfiguriran Putty klijent za autorizaciju pomoću ključeva. Ostaje još jedna mala točka: kako prisiliti sshd demon 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 na 0500 za root.

chmod 0500  /usr/local/bin/fetchSSHKeysFromLDAP

U ovom primjeru, administratorski račun se koristi za vezanje na imenik. U borbenim uvjetima mora postojati zaseban račun s minimalnim skupom prava.
Osobno sam bio vrlo zbunjen trenutkom lozinke u svom čistom obliku u skripti, unatoč postavljenim pravima.
Opcija rješenja:

  • Lozinku spremam u posebnu datoteku: 
    echo -n Supersecretpassword > /usr/local/etc/secretpass

  • Postavio sam dopuštenja datoteke na 0500 za root 
    chmod 0500 /usr/local/etc/secretpass

  • Promjena parametara pokretanja ldapsearch: parametar -w supertajna lozinka mijenjam ga u -y /usr/local/etc/secretpass

Posljednji 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, dobivamo sljedeći niz s autorizacijom ključa konfiguriranom u ssh klijentu:

  1. Korisnik se spaja na poslužitelj navodeći svoju prijavu.
  2. Sshd demon, putem skripte, izvlači vrijednost javnog ključa iz korisničkog atributa u Active Directoryju i provodi autorizaciju pomoću ključeva.
  3. Sssd demon dalje autentificira korisnika na temelju članstva u grupi. Pažnja! Ako ovo nije konfigurirano, tada će svaki korisnik domene imati pristup hostu.
  4. Kada pokušate sudo, sssd demon pretražuje Active Directory za uloge. Ako su uloge prisutne, provjeravaju se korisnički atributi i članstvo u grupi (ako je sudoRoles konfiguriran za korištenje korisničkih grupa)

Sažetak.

Dakle, ključevi su pohranjeni u korisničkim atributima Active Directory, sudo dopuštenja - slično, pristup Linux hostovima po domenskim računima provodi se provjerom članstva u Active Directory grupi.
Posljednji zamah dirigentske palice - i dvorana se smrzava u tišini pune poštovanja.

Izvori korišteni u pisanju:

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

Izvor: www.habr.com

Dodajte komentar