ProHoster > Blog > Uprava > Zmagovalci mednarodnih tekmovanj SSH in sudo spet na odru. Vodi ugledni vodja Active Directory

Zmagovalci mednarodnih tekmovanj SSH in sudo spet na odru. Vodi ugledni vodja Active Directory

V preteklosti so dovoljenja za sudo urejala vsebina datotek iz /etc/sudoers.d и visudo, avtorizacija ključa pa je bila izvedena z uporabo ~/.ssh/authorized_keys. Ker pa infrastruktura raste, obstaja želja po centraliziranem upravljanju teh pravic. Danes lahko obstaja več možnosti rešitve:

  • Sistem za upravljanje konfiguracije - Chef, Lutkovno, Možno, Sol
  • Active Directory + ssd
  • Razne perverzije v obliki skriptov in ročnega urejanja datotek

Po mojem subjektivnem mnenju je še vedno najboljša možnost centraliziranega upravljanja kombinacija Active Directory + ssd. Prednosti tega pristopa so:

  • Resnično en centraliziran uporabniški imenik.
  • Razdelitev pravic sudo se zmanjša na dodajanje uporabnika v določeno varnostno skupino.
  • V primeru različnih sistemov Linux je pri uporabi konfiguracijskih sistemov potrebno uvesti dodatna preverjanja za določitev OS.

Današnja zbirka bo posvečena prav povezavi Active Directory + ssd za upravljanje pravic sudo in shranjevanje ssh ključev v enem samem repozitoriju.
Tako je dvorana zamrznila v napeti tišini, dirigent je dvignil dirigentsko palico in orkester se je pripravil.
Pojdi.

Glede na:
— Domena Active Directory testopf.local na Windows Server 2012 R2.
— Gostitelj Linux, ki izvaja Centos 7
— Konfigurirana avtorizacija z uporabo ssd
Obe rešitvi spreminjata shemo Active Directory, zato vse preverimo v testnem okolju in šele nato izvedemo spremembe na delujoči infrastrukturi. Opozoriti bi rad, da so vse spremembe usmerjene in dejansko dodajajo samo potrebne atribute in razrede.

1. ukrep: nadzor sudo vloge skozi Active Directory.

Za razširitev vezja Active Directory prenesti morate najnovejšo izdajo sudo — 1.8.27 od danes. Razpakirajte in kopirajte datoteko schema.ActiveDirectory iz imenika ./doc v krmilnik domene. V ukazni vrstici s skrbniškimi pravicami iz imenika, v katerega je bila kopirana datoteka, zaženite:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Ne pozabite zamenjati svojih vrednosti)
Odpri adsiedit.msc in se povežite s privzetim kontekstom:
Ustvarite razdelek v korenu domene Sudoers. (Buržoazija trmasto trdi, da je v tej enoti demon ssd išče predmet sudoRole predmetov. Vendar pa je bilo po vklopu podrobnega odpravljanja napak in preučevanju dnevnikov ugotovljeno, da je bilo iskanje izvedeno po celotnem drevesu imenikov.)
Ustvarimo prvi objekt, ki pripada razredu v delitvi sudoRole. Ime lahko izberete popolnoma poljubno, saj služi izključno za priročno identifikacijo.
Med možnimi razpoložljivimi atributi iz razširitve sheme so glavni naslednji:

  • sudoCommand — določa, katere ukaze je dovoljeno izvajati na gostitelju.
  • sudoHost — določa, za katere gostitelje velja ta vloga. Lahko se določi kot VSE, za posameznega gostitelja pa po imenu. Možna je tudi uporaba maske.
  • sudoUser — navedite, katerim uporabnikom je dovoljeno izvajanje sudo.
    Če določite varnostno skupino, dodajte znak »%« na začetek imena. Če so v imenu skupine presledki, ni razloga za skrb. Po dnevnikih sodeč nalogo uhajanja prostorov prevzame mehanizem ssd.

Zmagovalci mednarodnih tekmovanj SSH in sudo spet na odru. Vodi ugledni vodja Active Directory
Slika 1. Objekti sudoRole v razdelku sudoers v korenu imenika

Zmagovalci mednarodnih tekmovanj SSH in sudo spet na odru. Vodi ugledni vodja Active Directory
Slika 2. Članstvo v varnostnih skupinah, določenih v objektih sudoRole.

Naslednja nastavitev se izvede na strani Linuxa.
V datoteki /etc/nsswitch.conf dodajte vrstico na konec datoteke:

sudoers: files sss

V datoteki /etc/sssd/sssd.conf v razdelku [sssd] dodajte storitvam sudo

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

Po vseh operacijah morate počistiti predpomnilnik demona sssd. Samodejne posodobitve se zgodijo vsakih 6 ur, a zakaj bi morali čakati tako dolgo, ko pa jih želimo zdaj?

sss_cache -E

Pogosto se zgodi, da brisanje predpomnilnika ne pomaga. Nato zaustavimo storitev, očistimo bazo podatkov in zaženemo storitev.

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

Priklopimo se kot prvi uporabnik in preverimo, kaj mu je na voljo 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

Enako storimo z drugim uporabnikom:

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

Ta pristop vam omogoča centralno definiranje vlog sudo za različne skupine uporabnikov.

Shranjevanje in uporaba ključev ssh v imeniku Active Directory

Z rahlo razširitvijo sheme je možno shraniti ključe ssh v uporabniške atribute Active Directory in jih uporabiti pri avtorizaciji na gostiteljih Linuxa.

Pooblastilo prek sssd mora biti konfigurirano.
Dodajte zahtevani atribut s pomočjo skripta PowerShell.
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 = ID novega atributa
$atributi = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSintaksa = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Uporabniški javni ključ za prijavo SSH';
}

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

Ko dodate atribut, morate znova zagnati domenske storitve Active Directory.
Preidimo k uporabnikom Active Directory. Ustvarili bomo par ključev za povezavo ssh na kateri koli način, ki vam ustreza.
Zaženemo PuttyGen, pritisnemo gumb »Generate« in mrzlično premikamo miško znotraj praznega območja.
Po končanem procesu lahko shranimo javni in zasebni ključ, naložimo javni ključ v uporabniški atribut Active Directory in uživamo v procesu. Vendar je treba javni ključ uporabiti od "Javni ključ za lepljenje v datoteko Authorized_keys OpenSSH:".
Zmagovalci mednarodnih tekmovanj SSH in sudo spet na odru. Vodi ugledni vodja Active Directory
Dodajte ključ atributu uporabnika.
Možnost 1 – GUI:
Zmagovalci mednarodnih tekmovanj SSH in sudo spet na odru. Vodi ugledni vodja Active Directory
2. možnost – PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Torej, trenutno imamo: uporabnika z izpolnjenim atributom sshPublicKey, konfiguriranega odjemalca Putty za avtorizacijo s ključi. Ostaja še ena majhna točka: kako prisiliti demon sshd, da iz uporabniških atributov izvleče javni ključ, ki ga potrebujemo. S tem se lahko uspešno spopade majhna skripta, ki jo najdemo na meščanskem internetu.

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'

Dovoljenja zanj smo nastavili na 0500 za root.

chmod 0500  /usr/local/bin/fetchSSHKeysFromLDAP

V tem primeru je skrbniški račun uporabljen za povezovanje z imenikom. V bojnih razmerah mora obstajati ločen račun z minimalnim naborom pravic.
Osebno me je zelo zmedel trenutek gesla v čisti obliki v skriptu, kljub nastavljenim pravicam.
Možnost rešitve:

  • Geslo shranim v ločeno datoteko: 
    echo -n Supersecretpassword > /usr/local/etc/secretpass

  • Dovoljenja datoteke sem nastavil na 0500 za root 
    chmod 0500 /usr/local/etc/secretpass

  • Spreminjanje parametrov zagona ldapsearch: parameter -w superSecretPassword Spremenim ga v -y /usr/local/etc/secretpass

Zadnji akord današnje zbirke je urejanje sshd_config

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

Kot rezultat dobimo naslednje zaporedje z avtorizacijo ključa, konfigurirano v odjemalcu ssh:

  1. Uporabnik se poveže s strežnikom tako, da navede svojo prijavo.
  2. Demon sshd prek skripta izvleče vrednost javnega ključa iz uporabniškega atributa v imeniku Active Directory in izvede avtorizacijo s pomočjo ključev.
  3. Demon sssd nadalje overi uporabnika na podlagi članstva v skupini. Pozor! Če to ni konfigurirano, bo imel vsak uporabnik domene dostop do gostitelja.
  4. Ko poskusite sudo, demon sssd išče vloge v imeniku Active Directory. Če so vloge prisotne, se preverijo uporabniški atributi in članstvo v skupini (če je sudoRoles konfiguriran za uporabo uporabniških skupin)

Povzetek.

Tako so ključi shranjeni v uporabniških atributih imenika Active Directory, dovoljenja sudo – podobno se dostop do gostiteljev Linuxa po domenskih računih izvaja s preverjanjem članstva v skupini imenika Active Directory.
Zadnji zamah dirigentske palice - in dvorana zamrzne v spoštljivi tišini.

Pisno uporabljeni viri:

Sudo prek Active Directory
Ssh ključi prek Active Directory
Skript Powershell, dodajanje atributa v shemo Active Directory
stabilna izdaja sudo

Vir: www.habr.com

Dodaj komentar