Korábban a sudo engedélyeket a forrásból származó fájlok tartalma szabályozta /etc/sudoers.d и visado, és a kulcs engedélyezése a használatával történt ~/.ssh/authorized_keys. Az infrastruktúra növekedésével azonban felmerül a vágy, hogy ezeket a jogokat központilag kezeljék. Ma több megoldási lehetőség is lehet:
- Konfigurációkezelő rendszer - Séf, Báb, Ansible, Só
- Active Directory + ssd
- Különféle perverziók szkriptek és kézi fájlszerkesztés formájában
Szubjektív véleményem szerint a központosított irányítás legjobb megoldása továbbra is a kombináció Active Directory + ssd. Ennek a megközelítésnek az előnyei a következők:
- Valóban egyetlen központi felhasználói könyvtár.
- A jogok elosztása sudo a felhasználó hozzáadása egy adott biztonsági csoporthoz.
- Különböző Linux rendszerek esetén további ellenőrzések bevezetése válik szükségessé az operációs rendszer meghatározásához konfigurációs rendszerek használatakor.
A mai csomagot kifejezetten a kapcsolatnak szenteljük Active Directory + ssd jogkezeléshez sudo és tárolás ssh kulcsok egyetlen tárolóban.
Így aztán a terem feszült csendben megdermedt, a karmester felemelte a pálcát, és a zenekar elkészült.
Megy.
adott:
— Active Directory tartomány testopf.local Windows Server 2012 R2 rendszeren.
- Linux gazdagép, amelyen a Centos 7 fut
— Konfigurált jogosultság a használatával ssd
Mindkét megoldás módosítja a sémát Active Directory, tehát mindent tesztkörnyezetben ellenőrizünk, és csak ezután hajtunk végre változtatásokat a működő infrastruktúrán. Szeretném megjegyezni, hogy minden változtatás célzott, és valójában csak a szükséges attribútumokat és osztályokat adja hozzá.
1. művelet: ellenőrzés sudo szerepek révén Active Directory.
Az áramkör bővítésére Active Directory le kell töltened a legújabb kiadást — 1.8.27 a mai naptól. Csomagolja ki és másolja a fájlt schema.ActiveDirectory a ./doc könyvtárból a tartományvezérlőbe. A parancssorból adminisztrátori jogokkal abból a könyvtárból, ahová a fájlt másolták, futtassa:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Ne felejtse el helyettesíteni az értékeit)
nyissa ki az adsiedit.msc és csatlakozzon az alapértelmezett környezethez:
Hozzon létre egy felosztást a tartomány gyökerében pulóverek. (A burzsoázia makacsul állítja, hogy ebben az egységben van a démon ssd elemet keres sudoRole tárgyakat. A részletes hibakeresés bekapcsolása és a naplók tanulmányozása után azonban kiderült, hogy a keresést a teljes címtárfán végrehajtották.)
Létrehozzuk az első osztályhoz tartozó objektumot az osztásban sudoRole. A név teljesen tetszőlegesen választható, mivel kizárólag a kényelmes azonosítást szolgálja.
A sémabővítményből elérhető attribútumok közül a főbbek a következők:
- sudoCommand — meghatározza, hogy mely parancsok hajthatók végre a gazdagépen.
- sudoHost — meghatározza, hogy mely gazdagépekre vonatkozik ez a szerep. Megadható, mint MINDEN, és egy egyedi gazdagép esetében név szerint. Lehetőség van maszk használatára is.
- sudoUser — jelzi, mely felhasználók hajthatnak végre sudo.
Ha biztonsági csoportot ad meg, adjon hozzá egy „%” jelet a név elejéhez. Ha a csoport nevében szóközök vannak, akkor nincs ok az aggodalomra. A rönkökből ítélve a terek kiszökésének feladatát a mechanizmus veszi át ssd.
1. ábra: sudoRole objektumok a sudoers alosztályban a könyvtár gyökerében
2. ábra: Tagság a sudoRole objektumokban megadott biztonsági csoportokban.
A következő beállítás Linux oldalon történik.
Fájlban /etc/nsswitch.conf add hozzá a sort a fájl végéhez:
sudoers: files sssFájlban /etc/sssd/sssd.conf szakaszban [sssd] hozzáadni a szolgáltatásokhoz sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Minden művelet után törölnie kell az sssd démon gyorsítótárát. Az automatikus frissítések 6 óránként történnek, de miért várjunk olyan sokáig, amikor most szeretnénk?
sss_cache -EGyakran előfordul, hogy a gyorsítótár törlése nem segít. Ezután leállítjuk a szolgáltatást, megtisztítjuk az adatbázist, és elindítjuk a szolgáltatást.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Első felhasználóként csatlakozunk, és ellenőrizzük, hogy mi áll rendelkezésére a sudo alatt:
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/catUgyanezt tesszük a második felhasználónkkal is:
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
Ez a megközelítés lehetővé teszi a sudo szerepkörök központi meghatározását a különböző felhasználói csoportokhoz.
Az ssh kulcsok tárolása és használata az Active Directoryban
A séma enyhe bővítésével lehetőség nyílik az ssh kulcsok Active Directory felhasználói attribútumokban való tárolására és a Linux gazdagépeken történő engedélyezésére.
Az sssd-n keresztüli engedélyezést be kell állítani.
Adja hozzá a szükséges attribútumot egy PowerShell-szkript segítségével.
AddsshPublicKeyAttribute.ps1Funkció New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$Parts+=[UInt64]::Elemzés($guid.SubString(0,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Elemzés($guid.SubString(4,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Elemzés($guid.SubString(9,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Elemzés($guid.SubString(14,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Elemzés($guid.SubString(19,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Elemzés($guid.SubString(24,6),“AllowHexSpecifier”)
$Parts+=[UInt64]::Elemzés($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 = Új attribútumazonosító
$attribútumok = @{
lDAPDisplayName = 'sshPublicKey';
attribútumId = $oid;
oMSyntax = 22;
attribútumSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Felhasználói nyilvános kulcs az SSH bejelentkezéshez';
}
Új-ADO-objektum -Név sshPublicKey -Típus attribútumSéma -Path $schemapath -EgyébAttribútumok $attribútumok
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADOBject -Add @{mayContain = 'sshPublicKey'}
Az attribútum hozzáadása után újra kell indítania az Active Directory tartományi szolgáltatásokat.
Térjünk át az Active Directory felhasználókra. Létrehozunk egy kulcspárt az ssh-kapcsolathoz az Ön számára megfelelő módszerrel.
Elindítjuk a PuttyGen-t, megnyomjuk a „Generate” gombot, és eszeveszetten mozgatjuk az egeret az üres területen.
A folyamat befejeztével elmenthetjük a nyilvános és privát kulcsokat, feltölthetjük a nyilvános kulcsot az Active Directory felhasználói attribútumába, és élvezhetjük a folyamatot. A nyilvános kulcsot azonban a "Nyilvános kulcs az OpenSSH authorised_keys fájlba való beillesztéshez:”.
Adja hozzá a kulcsot a felhasználói attribútumhoz.
1. lehetőség – GUI:
2. lehetőség – PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Jelenleg tehát van egy felhasználónk az sshPublicKey attribútummal, egy konfigurált Putty kliens a kulcsok használatával történő engedélyezéshez. Marad egy apró pont: hogyan kényszeríthetjük rá az sshd démont, hogy kivonja a szükséges nyilvános kulcsot a felhasználó attribútumaiból. A burzsoá interneten talált kis szkript sikeresen megbirkózik ezzel.
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'A root jogosultságokat 0500-ra állítottuk be.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Ebben a példában egy rendszergazdai fiókot használunk a címtárhoz való kapcsolódáshoz. Harckörülmények között külön fióknak kell lennie minimális jogokkal.
Engem személy szerint nagyon megzavart a jelszó tiszta formájában a szkriptben, a beállított jogok ellenére.
Megoldási lehetőség:
- A jelszót egy külön fájlba mentem:
echo -n Supersecretpassword > /usr/local/etc/secretpass - A fájlengedélyeket 0500-ra állítottam a root számára
chmod 0500 /usr/local/etc/secretpass - Az ldapsearch indítási paramétereinek módosítása: paraméter -w SuperSecretPassword megváltoztatom -y /usr/local/etc/secretpass
A mai programcsomag utolsó akkordja az sshd_config szerkesztése
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Ennek eredményeként a következő sorozatot kapjuk az ssh kliensben konfigurált kulcsengedélyezéssel:
- A felhasználó bejelentkezési adatainak megadásával csatlakozik a szerverhez.
- Az sshd démon egy parancsfájlon keresztül kivonja a nyilvános kulcs értékét egy felhasználói attribútumból az Active Directoryban, és hitelesítést hajt végre a kulcsok segítségével.
- Az sssd démon tovább hitelesíti a felhasználót a csoporttagság alapján. Figyelem! Ha ez nincs konfigurálva, akkor bármely tartományfelhasználó hozzáférhet a gazdagéphez.
- Amikor megpróbálja a sudo-t, az sssd démon szerepeket keres az Active Directoryban. Ha vannak szerepkörök, akkor a felhasználó attribútumait és csoporttagságát ellenőrzi (ha a sudoRoles felhasználói csoportok használatára van beállítva)
Összegzés.
Így a kulcsok az Active Directory felhasználói attribútumaiban, a sudo engedélyekben tárolódnak - hasonlóképpen a Linux-gazdagépekhez való hozzáférés a tartományfiókok által az Active Directory csoport tagságának ellenőrzésével történik.
A karmesteri pálca utolsó hulláma – és a terem áhítatos csendbe fagy.
Az írásban felhasznált források:
Forrás: will.com