Egyszerű központi authentikáció linux szerverekhez

Linux-haladó

Linux szerverek adminisztrációjához (gyak. kizárólag ssh auth, ~5 user, 10+ szerver) keresnék valami egyszerű, de megbízható user management / központi authentikációs megoldást.
Keresgéltem a fórumokon, sokan ajánlják a FreeIPA-t, megnéztem, nem is rossz, de talán ágyúval verébre.
Esetleg PAM-LDAP? Az tud kulcs alapú auth-ot? - ez lényeges lenne!
Illetve, ilyen esetben mi a szokásos vész-forgatókönyv, ha valami oknál fogva épp az auth szerver áll?
Ki milyen megoldást javasolna, ami DMZ-be is biztonsággal kiengedhető?

  • 2462 megtekintés

( kroozo v | 2016. 04. 20., sze – 10:07 )

A free ipa miért annyira ágyúval verébre? Értem én, hogy komplex, de egyébként is össze kéne kalapálni a local user managementet, kulcsterítést, ldap szervert ilyesmit, és a freeipa egyébként elég strandard eszközökből rakja ezt össze -- abból, amiből jó eséllyel te is összeraknád, és nem kell vele pöcsölni, elég szög egyszerű a telepítés meg az enrollment. Enyni userre valószínűleg sokat enni nem kér.

Esetleg fogsz valami puppetet vagy ansiblet, amivel szépen tolod a useradd / userdelt, meg a helyére másolgatod mindenkinek a pub kulcsát.

+1, hasonló méretű rendszernél simán megléptem azt, hogy két gépre aktív-aktív replikával IPA, és a többiek onnan authentikáltak. És a DNS-t sem kellett külön matatni...
A kulcstologatás és userek generálása/leszedése configmanagement felől sem rossz, de az IPA-hoz képest extrém fapad - és mire kikalapálod, a szívásfaktor is magasabb lesz.

DMZ felől lehet, hogy elég (picit szegelős, de szerintem megoldható) csak a kerberos-t engedni ("bent" kinit, és a tickettel megy ki a DMZ-s gépre), ezt még nem próbáltam megoldani.

Ha nagyon paranoid vagy, akkor lehet kétfaktorosan (OTP-vel) authentikálni - ekkor viszont a sudo csak authentikáció _nélkül_ fog működni (ismert hiba, valamikor 4.x-ben javítani fogják, elég mélyen csücsül a probléma gyökere)

Esetleg fogsz valami puppetet vagy ansiblet, amivel szépen tolod a useradd / userdelt, meg a helyére másolgatod mindenkinek a pub kulcsát.

ansible vagy mas amugy is van a topiknyitonal. 5 usert kezelni egy bebi konnyu playbook, oszt viszonlatasra...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

kérdés, hogy mi a cél. Ha alapvetően a saját életét akarja megkönnyíteni a team, nem pedig az auditálhatóság és hasonlók irányából érkezik a dolog, akkor ekkora mennyiségnél lehet egyszerűbb valami favágó lófaszt összerakni, azt jóidő, ha néha valahol eltörik, azt majd megjavítják, sokáig úgy tippre nem marad, mert be azért mászkálnak gondolom rendszeresen ennyi gépre (szóval nem az van mint nagyobb rendszereken előfordul, hogy van, ahova ha nincs gond fél évig a kutya se...)

Jól veszem ki, hogy ez "csak" a klienseken cache-eli a központi authentikációt (azaz pont a vészforgatókönyvet intézi), de a külön központi rendszer (pl. AD, vagy IPA) kell mögé?

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Igen, jól értelmezed kell valami kiszolgáló hozzá.
A vészforgatókönyvre vész esetén lesz szükség, amíg működik az sssd addig nincs vész :) Szóval én még tolnék mellé egy local admin usert(ami nem feltétlen root, környezetttől függ), ahogy fentebb említették pupet/chef/salt/ansiblie-el vagy egy jó for ciklussal managelheted a local admin usered. Vagy vészforgatókönyvnek használhatod helyi konzolon a root-ot is, általában az szokott lenni a vészforgatókönyv :)
--------------------
http://grant-it.com/

( dap | 2016. 04. 20., sze – 12:55 )

Néunk ezt megoldotta a Puppet, Ansible. Ugyan nem központi auth, de központilag adminisztrált. Nem muszáj a teljes szervert menedzselni velük, lehet szorítkozni a juzermenedzsmentre.

( golgota | 2016. 04. 20., sze – 16:32 )

Tobben irtuk it a FreeIPA-t es nem veletlenul. Ossze van rakva na. Nekem csak egyszer doglott le az egesz egy update-nel (tobb verziot ugrottunk), mikoris a cert storeba belegeneralt egy uj cert-et, de a regi id-jevel akart mukodni ehelyett az uj id helyett. Vagy ket hetig nyomoztuk a RedHat supportal, hogy mi a franc van. :D

De ez mar regen volt.

Amugy tenyleg minek sajat, ha ebben van 389DS, Kerberos, Cert store, meg minden egybeepitve es osszecsiszolva. El lehet molyolni ugyanennek az osszerakasaval par hetig.

( Kayapo | 2016. 04. 20., sze – 16:45 )

Ha kevesebb mint 2 tucat géped van én sem egyiket sem másikat nem javaslom, szerintem bőven elég egy központi config management cuccos ami tud usert létrehozni, törölni. Én a magam részéről a puppet -et javaslom

----
올드보이

( battila | 2016. 04. 21., cs – 06:32 )

Hali,

en openldap-ot hasznalok ssh kulcsokkal.
Alapbol az ldap-ban nincs kulcs tarolo atributum, igy azt kerestem egyet a neten:


#
# LDAP Public Key Patch schema for use with openssh-ldappubkey
# Author: Eric AUGE
#
# Based on the proposal of : Mark Ruijter
#

# octetString SYNTAX
attributetype ( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey'
DESC 'MANDATORY: OpenSSH Public key'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

# printableString SYNTAX yes|no
objectclass ( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' SUP top AUXILIARY
DESC 'MANDATORY: OpenSSH LPK objectclass'
MAY ( sshPublicKey $ uid )
)

Ha jol remlik a 6-os openssh-tol mar tud kulso kulcskezelot hasznalni, igy elharult az akadaly is (AuthorizedKeysCommand, AuthorizedKeysCommandUser).
Irtam egy perl scriptet ami kiszedi a kulcsokat az ldap-bol es azt hasznalom. Mivel gitolite-hoz is kellett, ezert kicsit varialgattam rajta, hogy a git felhasznalonak az ossze kulcsot kiadja. Mukodik frankon, erdemes vele jatszadozni.

( Zahy v | 2016. 04. 21., cs – 07:43 )

Csak szólok, hogy ha naívan a PAM-LDAP-pal akarnál szórakozni, akkor kell mellé még valami (jellemzően NSS-LDAP) *is*. De valószínűleg valamelyik korábban emlegetett komplexebbnek látszóval jobban jársz.

( tompos v | 2016. 04. 21., cs – 08:10 )

Kizarolag akkor eri meg ldap (vagy barmi mas service) hasznalata, ha a rendszeren kivul mas (szinten service) usereket is akarsz authentikalni. Pl. apache, mail szerver).
Ha csak a rendszer usereket akarod kezelni, akkor generalod magadnak a problemat.

Kulonosen az IPA-val vigyaznek a helyedben a kerberos miatt, kulonbozo cifra hibakat produkalhat.

Az sssd tudja az IPA-t "natívan" ipa, és az ldap-szervert direktben kérdezgetve ldap backendként is használni. Ez utóbbi eset (natívan ldap-on keresztül megszólított IPA) van akkor is, ha például 5.3-nál újabb AIX-en akarsz az IPA-ból authentikálni: sssd 5.3 fölött már (még...) nincs.

Sajnos nem tudom, tompos milyen hibákra utalt kerberos kapcsán - remélem, megosztja velünk ezt az infót :-P

~4000 userrel gyakorlatilag(*) problémamentesen működik az IPA (két szerver aktív-aktív felállásban) - igaz, néhány dolgot kellett hozzá hangolni a rendszerben.
A kerberos nekem akkor produkált hibákat (#define hiba), ha el vala mászva az idő a gépek között, méghozzá nem kicsit, hanem nagyon.

Nem 100% hibamentes, de az ssh-s userek bejelentkezésével nincs probléma, illetve egy dokuwiki is (group alapon) onnan szedi, hogy ki írhatja a wikit.

Nekem is problemamentesen mukodik az IPA.

De neki nem 4000 user adminisztralja az 20 gepet, hanem 5(!).

Aztan valtottunk a redhat (ja igen, redhat kell neki, az ubuntu-s meg mindig ratyi - FIXME) 7.0-ban levore, aztan a a service idonkent elszallt, valoszinuleg terhelestol fuggoen. Majd talan vmikor mostanaban megprobaljuk ujra.

A fejlesztokkel neztuk, akkor epp megfoghatatlan volt.

A kerberost meg azert hoztam fel, mert egy rohadtul felesleges service oda. Nem is ertem, miert raktak be a kepbe, csak a komplexitast noveli. Legalabbis szamomra pluszt nem ad. Pl. sok sikert az ansible-vel tutujgatashoz.

Apropo, az megoldas is egy kalap szar, hogy az intranetrol elerheto legyen.
Pedig imadnam, rohadt jo cucc lenne, ha nem egetnek be az ilyen szarokat.

CentOS is príma alá, nem kell RHEL :-P Egyébként az a méretes userszám még a RHEL6-os verzión futó "régi" IPA-ban volt/van, és nem is várható migrálás - köszöni szépen, teljesen jól érzi magát ugyanis :-P
CentOS7-en futó IPA olyan 10-12 gép meg kb. 5-8 userre lett összerakva, és ott sem tapasztaltam elhasalásokat - igaz, mindkét esetben replikált, aktív-aktív felállásban működnek.
Ha nem érted, miért kell, miért jó a kerberos, akkor javaslom, nézz utána, mert elég alap technológia.

Az utolsó bekezdésedet nem tudom értelmezni, de gondolom, az is inkább "de gustibus..." mint szakmai alapon történő érvelés lenne.

Leirtam, hogy elszallt a service, nem eleg?:)
En leirtam, h nalam elesben elszallt, erre te irtad, hogy nalad par szerveren nem elesben nem szallt el. Nagyszeru.

En leirtam, h a kerberos szerintem felesleges, te belinkelted, hogy miert nem az.

En leirtam, hogy csak redhaten fut, ubuntu-n nem, te elkezdtel kapalozni, hogy centos-en is.

A OP leirta, hogy 5 user + 10-20 szerverre akarja hasznalni (jobb esetben virtualizalva, ami hivatalosan nem ajanlott az IPA eseten), te meg peldalozol 4000 userrel es egy banki rendszer szerverparkjaval.

Kerlek ne legy mar ENNYIRE korlatolt.

Ha van egy privat halozatod, azon ipa, mondjuk ipa1.corp.intra hoston, akkor kemenyen szenvedni kell, ha el akarod eri az internet iranyabol ipa.corp.com cimen.

Minden azert, mert olyanja van, hogy redirect-el allandoan az intra-s cimre. Van vmi megoldas, hogy turni kell az apache-ot meg meg talan mast is, de nem tudom mennyire mukodik, ill. hogy mennyire fenntarthato.

Arrol mar nem is beszelve, ha a kulso eleresre a sajat certificate-jet akarja hasznalni a user. Minden nyogvenyelos, ha egy picit el akar terni az ember az okosok altal megalmodott rendszertol.

Értem. Az IPA-t direktben két néven/címen elérni valóban nem egyszerű (sőt), és valóban, nem így lett kitalálva.
A megoldás egyébként nem olyan nyögvenyelős, de való igaz, hogy tervezni kell, és körülményektől függ, hogy hogy célszerű megoldani.
Az IPA-t direktben DMZ-s/külvilág lábbal "kinyitni" nem tartom jó ötletnek - belső hálózaton, egy interfész, és a dmz/nagyvilág felől proxyzva (haproxy, nginx, apache, ízlés szerint) a webes kapcsolat, ha nagyon kell (ssl-t végződtet/újracsomagol).
De mindezt az adott környezet ismeretében lehet _jól_ megcsinálni. (A két interfésze, két név nem jó megoldás, valóban)

( janoszen v | 2016. 04. 21., cs – 09:51 )

Sokaig az LDAP hivoje voltam, de miutan mostanaban eleg sok LDAP-os rendszert latok, szeretnem felhivni a figyelmedet egy problemara:

Ha LDAP autht hasznalsz jelszoval, akkor a jelszavad minden rendszeren keresztul fog menni, ahol bejelentkezel. Azaz ha van egy lukas webalkalmazasod, es abban be kell jelentkezni, akkor ott keresztul megy a jelszavad es elkaphato. Ha ugyanezt a jelszot hasznalod midnenhol, akkor ezzel az osszes rendszeredet meg tudjak nyomni. De ha a szarul megirt webes alkalmazas veletlenul kilogolja a jelszot fileba, maris valtoztatni kell a jelszon. Szal nem idealis.

Szerintem, nezz korul az SSO es kulcsos megoldasok teren. Ha kell, akkor Puppettel, Cheffel, vagy valamilyen masik konfiguracio-menedzsment rendszerrel rakj ki SSH kulcsokat a szerverekre es a jelszot idealis esetben maximum 1 helyen kelljen beadni.

SSO-ra vannak kulonbozo megoldasok, OAuthra vannak normalis open source implementaciok, SAML-ra kevesbe.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Na pont erre valasz a Kerberos :D (ami resze a freeIPA-nak).

De amugy nem teljesen igaz amit irsz. Alkalmazas fuggo, hogy a jelszot egy webes alkalmazas hogy kuldi a szervernek. Ugyanis az protokollon keresztul leszedheti a password algoritmust es hashelheti a kuldes elott (last a sima pam-ldap exop-jat). Igy nem fog clear text-ben kuldozgeti jelszavakat. A masik ugye, ha TLS-el van megtamogatva az egesz. Ebben az esetben sem utazik clear text jelszo a halozaton az ldap fele.

Amit te leirsz az egy nem jol beallitott ldap eseten egy rosszul megirt alkalmazassal (vagy az alkalmazas altal haszalt szar ldap lib-bel) tortenhet meg.

"Amit te leirsz az egy nem jol beallitott ldap eseten egy rosszul megirt alkalmazassal (vagy az alkalmazas altal haszalt szar ldap lib-bel) tortenhet meg."

Szerintem pont azt akarta mondani, hogy ha olyan stratégiát választasz, ahol ilyesmi nincs, akkor kissebb eséllyel szopat meg egy ldapot szarul implementáló jöttment alkalmazás.