Historiallisesti sudo-käyttöoikeuksia säänteli tiedostojen sisältö /etc/sudoers.d и visudo, ja avaimen valtuutus suoritettiin käyttämällä ~/.ssh/authorized_keys. Infrastruktuurin kasvaessa näitä oikeuksia halutaan kuitenkin hallita keskitetysti. Tänään voi olla useita ratkaisuvaihtoehtoja:
- Kokoonpanonhallintajärjestelmä - Kokki, nukke, Ansible, Suolaa
- Active Directory + ssd
- Erilaisia perversioita skriptien ja manuaalisen tiedostojen muokkauksen muodossa
Subjektiivisen käsitykseni mukaan paras vaihtoehto keskitetylle hallinnoinnille on edelleen yhdistelmä Active Directory + ssd. Tämän lähestymistavan edut ovat:
- Todella yksi keskitetty käyttäjähakemisto.
- Oikeuksien jakaminen sudo tarkoittaa käyttäjän lisäämistä tiettyyn suojausryhmään.
- Erilaisten Linux-järjestelmien tapauksessa on tarpeen ottaa käyttöön lisätarkistuksia käyttöjärjestelmän määrittämiseksi konfigurointijärjestelmiä käytettäessä.
Tämän päivän sviitti on omistettu nimenomaan yhteydelle Active Directory + ssd oikeuksien hallintaa varten sudo ja varastointi ssh avaimet yhdessä arkistossa.
Niinpä sali jäätyi kireään hiljaisuuteen, kapellimestari kohotti sauvansa ja orkesteri valmistui.
Mennään.
ilmoittautua:
— Active Directory -toimialue testopf.local Windows Server 2012 R2:ssa.
- Linux-isäntä, jossa on Centos 7
— Määritetty valtuutus käyttämällä ssd
Molemmat ratkaisut tekevät muutoksia skeemaan Active Directory, joten tarkistamme kaiken testiympäristössä ja teemme vasta sitten muutoksia toimivaan infrastruktuuriin. Haluan huomata, että kaikki muutokset on kohdennettu ja itse asiassa lisäävät vain tarvittavat attribuutit ja luokat.
Toimi 1: ohjaus sudo roolit läpi Active Directory.
Piirin laajentamiseksi Active Directory sinun on ladattava uusin julkaisu - 1.8.27 tästä päivästä alkaen. Pura ja kopioi tiedosto schema.ActiveDirectory ./doc-hakemistosta toimialueen ohjaimeen. Suorita komentoriviltä järjestelmänvalvojan oikeuksilla hakemistosta, johon tiedosto kopioitiin:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Älä unohda korvata arvojasi)
Avata adsiedit.msc ja muodosta yhteys oletuskontekstiin:
Luo jako verkkotunnuksen juureen sudoers. (Porvaristo väittää itsepäisesti, että demoni on juuri tässä yksikössä ssd etsii tuotetta sudoRole esineitä. Yksityiskohtaisen virheenkorjauksen käyttöönoton ja lokien tutkimisen jälkeen paljastui kuitenkin, että haku suoritettiin koko hakemistopuusta.)
Luomme jaossa ensimmäisen luokkaan kuuluvan objektin sudoRole. Nimi voidaan valita täysin mielivaltaisesti, koska se palvelee yksinomaan kätevää tunnistamista.
Kaaviolaajennuksessa käytettävissä olevista määritteistä tärkeimmät ovat seuraavat:
- sudoCommand — määrittää, mitkä komennot sallitaan suorittaa isännässä.
- sudoHost — määrittää, mitä isäntiä tämä rooli koskee. Voidaan määrittää nimellä KAIKKI, ja yksittäiselle isännälle nimellä. On myös mahdollista käyttää maskia.
- sudoUser — ilmoittaa, mitkä käyttäjät voivat suorittaa sudo.
Jos määrität suojausryhmän, lisää "%"-merkki nimen alkuun. Jos ryhmän nimessä on välilyöntejä, ei ole syytä huoleen. Tukkien perusteella päätellen tiloja karkaamisen hoitaa mekanismi ssd.
Kuva 1. sudoRole-objektit sudoers-alaosastossa hakemiston juuressa
Kuva 2. Jäsenyys sudoRole-objekteissa määritettyihin suojausryhmiin.
Seuraava asennus tehdään Linux-puolella.
Tiedostossa /etc/nsswitch.conf lisää rivi tiedoston loppuun:
sudoers: files sssTiedostossa /etc/sssd/sssd.conf osiossa [sssd] lisätä palveluihin sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Kaikkien toimintojen jälkeen sinun on tyhjennettävä sssd-daemonin välimuisti. Automaattiset päivitykset tapahtuvat 6 tunnin välein, mutta miksi meidän pitäisi odottaa niin kauan, kun haluamme sen nyt?
sss_cache -EUsein käy niin, että välimuistin tyhjentäminen ei auta. Sitten lopetamme palvelun, puhdistamme tietokannan ja käynnistämme palvelun.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Yhdistämme ensimmäisenä käyttäjänä ja tarkistamme, mitä hänelle on tarjolla sudon alla:
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/catTeemme samoin toisen käyttäjämme kanssa:
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
Tämän lähestymistavan avulla voit määrittää keskitetysti sudo-roolit eri käyttäjäryhmille.
Ssh-avainten tallentaminen ja käyttö Active Directoryssa
Mallia hieman laajennettaessa on mahdollista tallentaa ssh-avaimia Active Directoryn käyttäjämääritteissä ja käyttää niitä valtuutettaessa Linux-isännissä.
Valtuutus sssd:n kautta on määritettävä.
Lisää vaadittu attribuutti PowerShell-komentosarjan avulla.
AddsshPublicKeyAttribute.ps1Funktio New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[Järjestelmä.Opas]::NewGuid().ToString()
$Osat=@()
$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 = Uusi-attribuutintunnus
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
attribuuttiId = $oid;
oMSyntaksi = 22;
attribuutisyntaksi = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Käyttäjän julkinen avain SSH-kirjautumiseen';
}
Uusi-ADO-objekti -Nimi sshPublicKey -tyyppiattribuuttiSchema -polku $schemapath -muut attribuutit $attribuutit
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Kun olet lisännyt määritteen, sinun on käynnistettävä Active Directory Domain Services uudelleen.
Siirrytään Active Directoryn käyttäjiin. Luomme avainparin ssh-yhteyttä varten millä tahansa sinulle sopivalla menetelmällä.
Käynnistämme PuttyGenin, painamme "Generate" -painiketta ja liikutamme kiihkeästi hiirtä tyhjällä alueella.
Prosessin päätyttyä voimme tallentaa julkiset ja yksityiset avaimet, ladata julkisen avaimen Active Directory -käyttäjäattribuutille ja nauttia prosessista. Julkista avainta on kuitenkin käytettävä "Julkinen avain liittämistä varten OpenSSH:n authorised_keys-tiedostoon:".
Lisää avain käyttäjämääritteeseen.
Vaihtoehto 1 – GUI:
Vaihtoehto 2 – PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Meillä on siis tällä hetkellä: käyttäjä, jolla on sshPublicKey-attribuutti täytettynä, määritetty Putty-asiakasohjelma avaimien valtuutusta varten. Jäljellä on yksi pieni kohta: kuinka pakottaa sshd-daemon poimimaan tarvitsemamme julkinen avain käyttäjän määritteistä. Porvarillisesta Internetistä löytyvä pieni käsikirjoitus selviää tästä onnistuneesti.
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'Asetamme sen käyttöoikeuksiksi 0500 rootille.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Tässä esimerkissä hakemistoon sitomiseen käytetään järjestelmänvalvojan tiliä. Taisteluolosuhteissa on oltava erillinen tili, jossa on vähimmäismäärä oikeuksia.
Itse olin hyvin hämmentynyt salasanan hetkestä sen puhtaassa muodossaan käsikirjoituksessa, huolimatta asetetuista oikeuksista.
Ratkaisuvaihtoehto:
- Tallennan salasanan erilliseen tiedostoon:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Asetin rootin tiedostooikeuksiksi 0500
chmod 0500 /usr/local/etc/secretpass - Ldapsearch-käynnistysparametrien muuttaminen: parametri -w superSecretPassword vaihdan siihen -y /usr/local/etc/secretpass
Tämän päivän sarjan viimeinen sointu on sshd_config:n muokkaaminen
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Tämän seurauksena saamme seuraavan sekvenssin ssh-asiakkaassa määritetyllä avaimen valtuuksilla:
- Käyttäjä muodostaa yhteyden palvelimeen ilmoittamalla sisäänkirjautumisensa.
- Sshd-demoni poimii komentosarjan avulla julkisen avaimen arvon Active Directoryn käyttäjän määritteestä ja suorittaa valtuutuksen avaimilla.
- Sssd-daemon todentaa käyttäjän edelleen ryhmän jäsenyyden perusteella. Huomio! Jos tätä ei ole määritetty, kaikilla verkkotunnuksen käyttäjillä on pääsy isäntään.
- Kun yrität tehdä sudoa, sssd-demoni etsii Active Directorysta rooleja. Jos rooleja on, käyttäjän attribuutit ja ryhmän jäsenyys tarkistetaan (jos sudoRoles on määritetty käyttämään käyttäjäryhmiä)
Yhteenveto.
Siten avaimet tallennetaan Active Directory -käyttäjäattribuutteihin, sudo-oikeuksiin - samoin verkkotunnustilien pääsy Linux-isäntään tapahtuu tarkistamalla Active Directory -ryhmän jäsenyys.
Kapellimestarisauvan viimeinen aalto – ja sali jäätyy kunnioittavaan hiljaisuuteen.
Kirjoituksessa käytetyt resurssit:
Lähde: will.com