Šta je novo?

Predlog za autenfikacioni server

morbius

Čuven
VIP član
Učlanjen(a)
08.03.2003
Poruke
6,385
Poena
985
Nova velika firma, došao verujući da ću naučiti dosta novog od iskusnijih kolega, samo da bih utvrdio da zapravo niko nema više iskustva od mene. :S: Nakon što sam im sredio niz stvari koje su radili naopako, došao je red da sredim malo i pristup serverima.

Trenutno se na firmine CentOS 5 servere svi loguju kao root. Želeo bih da ovo malo dovedem u red i napravim jedan centralni server za autentifikaciju, pa kad se uloguju kao običan korisnik, neka uzmu root po potrebi. Problem je što nemam iskustva sa ovim stvarima. Šta biste preporučili kao rešenje, LDAP, Kerberos, NIS, nešto drugo? Uslovi su pouzdanost i relativna jednostavnost za korišćenje i konfiguraciju. Takođe saveti i uputstva za postavljanje su dobrodošli.
 
Sve ima svoje prednosti i mane. Koliko je velika firma, koliko ima servera, a koliko klijenata? Sta jos ima osim CentOS servera tamo? Jesu li svi u okviru jedne fizicke jedinice (npr. zgrade)?

Ako se svi loguju na servere kao root (tako si napisao), onda je mozda najbolje da se podigne jedan centralni RADIUS server (npr. FreeRADIUS). NIS je zastarela i suvise busna tehnologija, to zaboravi u startu. LDAP je laksi da se nabudzi od Kerberosa, ali ima puno sigurnosnih nedostataka. LDAP moze, ali ne mora, da se koristi u kombinaciji sa Kerberos-om (tada se jedan koristi za "jedno", a drugi za "drugo").

Imas li mozda Windows servere ili klijente na mrezi? Jedna od opcija ti je i Windows AD (Active Directory) Server + Samba (veza izmedju *nix i windows masina). U zavisnosti od velicine i sastava mreze, ovo je cesto i najbolje resenje.
 
Poslednja izmena:
Nedelju dana kasnije i ja sam se u velikoj meri ohladio od od ove ideje. Postavio sam LDAP server u laboratoriji, na drugi sam instalirao LDAP klijent koji uredno vidi server i njegovu bazu, ali getent ne vidi kreirane korisnike i ne dozvoljava im da se uloguju. Dva dana neuspešno pokušavam da provalim zašto. Ovo je komplikovano i delikatno do bola. Još gore, zbog nekih bitnih skripti ne mogu da zabranim ssh root login na glavnim računarima, tako da autentifikacioni server ne bi mogao da preuzme sav posao oko autentifikacije na sebe.
 
I taman kad sam hteo da odustanem, provalim da korisnički nalozi da bi se ulogovali moraju da imaju klasu posixAccount i šest njenih obaveznih atributa definisano, što nije pisalo u nijednom uputstvu. LDAP server radi, sad nek šef odluči hoćemo li da ga uvodimo ili ne.
 
Ah, pa to je redovan problem sa Linux-om, kad nesto krene naopako, snalazi se kako znas i umes... :D Inace, nemoj da zaboravis da LDAP po default-u sve salje neenkriptovano, pa bi valjalo da se odmah ukljuci i TLS (procackaj malo conf file)...
 
Da, treba da napravim i sertifikat kako bi TLS radio, to mi je sledeći korak. Onda da vidim komandu kako da korisnici promene svoju šifru. Taman da imam sa čim da se zezam na poslu, impresioniram koleginice, brže prolazi vreme. :d
 
Teško je raditi osnovni security i hardening ako se godinama radilo na divlje :). Možda da prvo napraviš analizu šta je moguće pa sastaviš okvirnu security politiku, ukoliko je firma već nema.

Pristup root-a za skripte možeš donekle ograničiti kroz sshd(AllowUsers, DenyUsers, AllowGroups, DenyGroups) ili TCP wrappers. Npr. dopuštaš da se spoji root samo sa specifične IP adrese.

Takođe možeš podesiti sudo na svim strojevima.

Za LDAP passworde bi dobro došao neki self-service-password alat, npr. jedan od jednostavnijih:
http://ltb-project.org/wiki/documentation/self-service-password
Naravno, to obavezno staviti na https. Selfsigned certifikat ili dižeš CA.

Ako imaš AD, onda tamo možeš otvoriti administrativne linux korisnike kao što je netko predložio i eventualno dignuti enterprise CA rolu. Linux strojeve vežeš na AD putem sambe/winbind-a. (mogu ti poslati quick howto).

Kompleksnija opcija bi bila dizanje Linux domena / IPA servera (FreeIPA ili Red Hat IdM, ovisno dal je CentOS ili RHEL). To opet povlači za sobom high availability i backup procedure.
 
Poslednja izmena:
Teško je raditi osnovni security i hardening ako se godinama radilo na divlje :). Možda da prvo napraviš analizu šta je moguće pa sastaviš okvirnu security politiku, ukoliko je firma već nema.

Eh, programeri ljudi u ekipi, nemaju mnogo veze s Linux administracijom. Stvar je u tome što ni ja nisam security expert, a nemam želju da im nezvanično postajem šef obezbeđenja, pa da me cimaju za sve i svašta. Recimo, šef se tek sad setio da ne možemo da koristimo autentifikacioni server zbog firewall filtriranja na nekim lokacijama. Htedoh da mu kažem da možemo da tunelujemo sve kroz SSH, ali se ujedoh za jezik, lakše mi da sedim i kuliram. :D

Pristup root-a za skripte možeš donekle ograničiti kroz sshd(AllowUsers, DenyUsers, AllowGroups, DenyGroups) ili TCP wrappers. Npr. dopuštaš da se spoji root samo sa specifične IP adrese.

Da, gledao sam to. Problem je što ako upotrebim AllowUsers, onda će svi korisnici koji ne budu navedeni biti implicitno blokirani. Otkud znam, možda će želeti da dodaju nove korisnike kasnije. Umesto toga gledam da ubacim match blokove u sshd i preko njih ograničim root login na samo određeni IP opseg. Problem je što match zahteva openssh 5.1 ili noviji, dok prastari Centos 5 ima 4.3. Iskompajlirao sam pakete i poslao šefu na instalaciju, iz iskustva znam da šefovi vole da ih uključiš u proces, pod uslovom da im pružiš prosta uputsva koja ne uključuju više od tri koraka.
 
SSH tunelovanje kroz firewall je jako los sigurnosni potez. Neces biti u prilici da na vreme saznas ako ti neko "uleti" na server. Neces moci da pratis sta je taj "neko" radio na doticnoj masini, pogotovo ako uzme pa u startu linkuje history fajlove ka null. Znaci to da neko moze da ostvari direktnu, enkriptovanu vezu sa serverom bas i nije najbolje "resenje". Funkcija firewall-a se u tom slucaju maltene u potpunosti anulira.

Inace, gore si napisao da si podigao LDAP server (jednina), kao i da se radi o velikoj firmi. Obavezno podigni jos barem jedan LDAP server kao backup i load balancing. Ako sef ipak bude presao na LDAP, a redundancy ti je trenutno nula, kad ti padne taj server (ne ako, nego kada) iz bilo kojeg razloga, niko u celoj firmi vise nece moci da se loguje... :mad: Znaci najmanje tri stvari uvek imaj na umu: sigurnost, skalabilnost, redundantnost, a redosled prethodno pomenutih sam biraj. Koliko vidim, ti trenutno od ovoga nemas nista, osim podignutog LDAP servera. I sve stavljaj na papir, nikada jos nisam cuo da je velika firma izvodila IT radove ovako ad-hoc, pre prethodne izrade i overe projekta.
 
Taj LDAP server koji sam pominjao je čisto za testiranje i nikad ne bi bio uključen u glavnu mrežu. Produkcioni LDAP bi imao i rezervu, ali ionako nisam planirao da LDAP bude jedini način za autentifikaciju, lokalni login bi i dalje bio moguć. LDAP bi bio više tu radi uvođenja stvari u red, da se ne deli root lozinka zaposlenima koji realno mogu i bez root-a, već da se napravi jedna centralna baza korisnika sa koje bi svaki host mogao da "povuče" korisnike. Bezbednost mi nije glavna briga, firmina mreža ima nekoliko VPN slojeva. Ali kažem, na kraju verovatno ništa od centralne autentifikacije.
 
A koji je broj korisnika kojima treba ssh pristup, ako ih ima malo, onda ti je LDAP pointless samo zbog ssh. Umesto pristupa root lozinkom, autorizuj samo pubkey svakog korisnika kojem je potreban root pristup. Kada ne treba root, ako te mrzi da pravis user za svakog posebno, napravi jedan standardni user i korisnike za tog usera takodje autorizuj samo putem pojedinacnih kljuceva. Ne znam kako ih ne mrzi da se smaraju sa lozinkama.
 
A koji je broj korisnika kojima treba ssh pristup, ako ih ima malo, onda ti je LDAP pointless samo zbog ssh. Umesto pristupa root lozinkom, autorizuj samo pubkey svakog korisnika kojem je potreban root pristup. Kada ne treba root, ako te mrzi da pravis user za svakog posebno, napravi jedan standardni user i korisnike za tog usera takodje autorizuj samo putem pojedinacnih kljuceva. Ne znam kako ih ne mrzi da se smaraju sa lozinkama.

Razmišljao sam i o tome, problem je u nekim laptopima koje korisnici nose. Ako bi neko to maznuo, a mi imali autentifikaciju samo ključevima, mogao bi lopov ladno da ušeta na servere ako probije Windows domen lozinku. Naravno, mogao bih da stavim passphrase, ali opet mu to dođe na isto - lozinka. Prvo moram da proguram polise da se na te laptope stavi BIOS lozinka, a te laptope pružaju drugi vendori, ne firma, pa će da bude mnogo veselo ubeđivanje s njima.
 
...

Trenutno se na firmine CentOS 5 servere svi loguju kao root. Želeo bih da ovo malo dovedem u red i napravim jedan centralni server za autentifikaciju, pa kad se uloguju kao običan korisnik, neka uzmu root po potrebi. Problem je što nemam iskustva sa ovim stvarima. .

1) CentOS 5 je problematican https://wiki.centos.org/Download
<!> ** Please note Red Hat's policy on Production Phase 3 for EL5 in the above support policy. Only those security updates deemed crucial are now being released upstream for EL5 (so also for CentOS-5) Please read this Mailing List post for more details. The CentOS team recommends that you start moving workloads from CentOS-5 to CentOS-6 or CentOS-7.
CentOS 6 je klasika, CentOS 7 je sa systemd.

2) OpenSSH http://www.openssh.com/ je jednostavan, ali ipak trazi malo citanja i razmisljanja. SSH Mastery by Michael Lucas https://www.michaelwlucas.com/nonfiction/ssh-mastery

Root SSH login je neophodno onemoguciti. SSH (authorized user) login se preporucuje preko kljuceva, a ne i preko password. Root password se ne sme deliti, to je mogao da smisli samo k*eten, deb*l ili i*iot, a onaj sysadmin koji to tolerise nije daleko od toga. Kreiraj novu grupu i podeli kljuceve za SSH login kao unprivileged user toj grupi. Kreiraj odredjeni broj (privileged) user-a koje dodaj u grupu wheel. SSH login samo kao unprivileged user, pa onda
Kod:
 $ su -l privileged_user 
Password:**********
$ (loged_in_as_privilegd_user)
$ sudo su
.

Sa OpenSSH je moguce praviti neku vrstu VPN. http://www.kernel-panic.it/openbsd/vpn/vpn5.html

Iz linkova ces zakljuciti (ako budes razmisljao) da se OpenSSH razvija na OpenBSD http://openbsd.com (imaju dobar FAQ). Vise o tom OS od istog Michael Lucas-a http://www.amazon.co.uk/Absolute-Op...anoid/dp/1593274769?tag=duckduckgo-ffsb-uk-21

3) Za central login management mozes Active directory sa Kerberos, ili YP, ili LDAP. Kerberos jos uvek podrzava FreeBSD http://freebsd.org (handbook, http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ odlican je). OpenBSD ga je izbacio kao nedovoljno sigurnog i koristi http://www.openiked.org/ (za komunikaciju sa Window$ koristi isakpmd).

Prerequisite je SSL implementacija. Evo dobre literature za OpenSSL (by Ivan Ristic) https://www.feistyduck.com/books/openssl-cookbook/ imas free download najvaznijeg odeljka. FreeBSD je jos na OpenSSL, OpenBSD je pokrenuo http://libressl.org.

4) Stosta ce ti biti jasnije sa http://www.amazon.com/Linux-System-...-Edition/dp/0131480057?tag=duckduckgo-ffsb-20 Nadji, procitaj, drzi blizu sebe za ponovno brzo citanje odgovarajuceg dela kad zatreba.

5) Ako ostajes na Linux, drzi se CentOS (sto je RHEL za nas sirotirnju), ili eventualno idi na Slackware. Izbegavaj sve Debian-based. Citaj dokumentaciju Linux distribucije preko ove osnovne literature. ArchLinux je takodje opcija, ali sam samo u jednom slucaju cuo da neko ozbiljan vozi servere na njemu.

6) Imas na http://edx.org (free) Linux (UNIX) tutorial od 18 lekcija. Odradi.

7) Procenjeno potrebno vreme minimun 3-6 meseci da pohvatas konce.

Srecno.


Razmišljao sam i o tome,...Naravno, mogao bih da stavim passphrase, ali opet mu to dođe na isto - lozinka.....

P.S.

Ne dodje mu na isto. Nije isto. Nisi dovoljno razmisljao. Donosis zakljucke na osnovu pogreskih pretpostavki.

Razmisli ponovo.
 
Poslednja izmena od urednika:
Hvala za knjige, pročitaću ih sigurno čim završim sadašnju knjigu o Python-u, ostalo mi još samo 1200 strana, :)

Danas smo baš imali sastanak gde je utanačeno šta i kako će se raditi po ovom pitanju. Moraće da ostane jedna mreža sa koje će serveri moći da pristupe jedan drugom kao root (ne pitaj zašto), svi ostali korisnici će dobiti lokalne naloge preko kojih će se logovati lozinkom ili ključem, videću već. I onda sve to treba da pismeno obrazložim dovoljno detaljno da bi Fujitsu odobrio izmene i dovoljno prosto da nam ne unište sistem pri implementaciji.

Samo jedno pitanje na brzaka, ako ti nije teško. Filtriranje adresa ću da izvedem kroz Match, ali da li je moguće koristeći AllowUsers (ili Deny, Groups, w/e) dozvoliti/blokirati više od jedne IP adrese ili opsega adresa? Recimo AllowUsers [email protected],5.6.7.8,192.168.1.0/24 ?
 
Hvala za knjige,

Kojesta imam na google drive u elektronskom formatu, delim ko mi trazi.


...
Danas smo baš imali sastanak gde je utanačeno šta i kako će se raditi po ovom pitanju. Moraće da ostane jedna mreža sa koje će serveri moći da pristupe jedan drugom kao root (ne pitaj zašto), svi ostali korisnici će dobiti lokalne naloge preko kojih će se logovati lozinkom ili ključem, videću već. I onda sve to treba da pismeno obrazložim dovoljno detaljno da bi Fujitsu odobrio izmene i dovoljno prosto da nam ne unište sistem pri implementaciji.

Da sam na tvom mestu, ostavio bih pismeni trag da sam ja protiv takvog resenja, ali da ga "predlazem" po nalogu pretpostavljenih, but that's just me.

...
Samo jedno pitanje na brzaka, ako ti nije teško. Filtriranje adresa ću da izvedem kroz Match, ali da li je moguće koristeći AllowUsers (ili Deny, Groups, w/e) dozvoliti/blokirati više od jedne IP adrese ili opsega adresa? Recimo AllowUsers [email protected],5.6.7.8,192.168.1.0/24 ?

Ja ne vidim da je to moguce (ali uvek volim da naucim nesto novo, pa podeli znanje ako budes uspeo). https://wiki.centos.org/HowTos/Network/IPTables?highlight=(iptables)
https://wiki.centos.org/HowTos/Network/SecuringSSH?highlight=(iptables)

Firewall filtrira po paketima, on je user anagnostic. OpenSSH Allow/Deny users autentifikuje lokalne korisnike, a ne korisnike drugih sistema, pa ne moze da autentifikuje [email protected].

Alternativa (losa, jer je setup idi*tski) je /etc/nologin (man ssh), da se onemoguci SSH login svima osim root-u. (kljucevi+passphrase).
 
A razlog je? Ne vidim nikakvu logiku.

Krajnje subjektivno, moje licno misljenje.

... ali da li je moguće koristeći AllowUsers (ili Deny, Groups, w/e) dozvoliti/blokirati više od jedne IP adrese ili opsega adresa? Recimo AllowUsers [email protected],5.6.7.8,192.168.1.0/24 ?

Zaboravih juce - ako hoces da dozvoljavas pristup i root-u i korisnicima, mozes da postavljas i proxy ssh server, pa da se prvo na njega loguju, a onda da razdvajas korisnike i usmeravas na jedan ssh server, a root na drugi server, s tim da na tim serverima firewall dozvoljava pristup samo sa odredjene (pozeljno javne) IP adrese. Jedino sto ovo trazi hardware. Ovo je dodatno ogradjivanje slabe tacke loseg setup-a i ne znam koliko ti to vrsi pos'o i koliko je uopste racionalno.
 
Poslednja izmena:
Krajnje subjektivno, moje licno misljenje.

Naravno da jeste, nego mene zanima da obrazložiš razlog za takvo mišljenje. Ako treba da izbegavam Debian, hteo bih da znam zašto. Ja mogu da navedem zašto treba izbegavati Slackware.

1) Slackware obično kasni za popularnijim distribucijama kada je u pitanju krpljenje pronađenih sigurnosnih propusta u softverskim paketima. Distribucije iza kojih stoje velike kompanije mnogo bolje stoje na tom polju.

2) Ograničena dostupnost binarnih paketa u repozitorijumu. Ko god je koristio Slackware, morao je tu i tamo da kompajlira neki softverski paket. Problem nastaje kada na serveru postoji veći broj softverskih paketa koji je ručno kompajliran. Situacija je takva da se praktično svakodnevno pronalaze sigurnosni propusti u softverskim paketima nakon čega se objavljuju zakrpe. Sve to iziskuje ponovno kompajliranje paketa uz eventualno back portovanje zakrpe na stariju verziju programskog paketa koji je u upotrebi. U ozbiljnim uslovima i sa većim brojem servera, samostalno ažuriranje paketa postaje nemoguća misija. Da bi ovo bilo održivo, potrebno je razviti nekakav automatizovan paket build sistem. Zašto bi se neko upuštao u tako nešto kad popularnije distribucije to već nude (i armiju ljudi koji stoje iza toga na izvolte)?

Slackware na kućnoj mašini za nekoga ko voli na tenane da šteluje sistem je OK. Donekle je i OK za servere koji su izolovani od pristupa spolja ali za servere koji su na izvolte svakome, definitivno ne. Jedan moj kolega, zagriženi korisnik Slackware-a svoje servere drži na poprilično matorim verzijama Slackware-a. Naravno serveri su bušni ko sito. Svi oni famozni propusti od novijeg vremena (Heartblead, Shellshock itd.) su ostali nezakrpljeni. On se teši činjenicom da za sve ove godine niko mu nije upao u sistem. Naravno kad niko nije ni probao... a da jeste, bilo bi veselo... :).

Arch sa druge strane takođe nije pogodan za servere. Zbog svoje rolling-release prirode, rizik je za stabilnost sistema na serverima. Pri svakom većem update-u treba sa razlogom strahovati od problema. Čak i trivijalni problemi koji se mogu rešiti su nedopustivi na mestima gde je visoka dostupnost (availability) neophodna.

Da ne bude skroz off topic:

Što se tiče centralizovanog sistema autentifikacije uz pomoć LDAP-a, on ima smisla samo u sledećim slučajevima:

1) Postoji veliki broj korisnika sistema i manji broj servera. Pričamo o desetinama i stotinama korisnika pa na više. U takvim uslovima često dolazi do slučajeva da neko promeni lozinku što onda treba propagirati na sve servere. Što je veći broj korisnika, to je učestanost promena lozinki (i eventualno drugih informacija/parametara) veća a time i više posla ako se propagiranje izmena obavlja ručno. Centralizovana autentifikacija tu onda rešava stvar.

2) Postoji manji broj korisnika ali veliki broj servera. Isto kao gore. U nedostatku centralizovane autentifikacije, pri promeni lozinke korisnika, potrebno je propagirati izmene na veliki broj servera što je velik posao.

3) Kombinacija 1) i 2).

Ako ništa od gore navedenog nije slučaj, postojanje centralizovanog sistema autentifikacije je poprilično besmisleno - iziskuje dodatno angažovanje oko održavanja i donosi svoje probleme i nedostatke, jednom rečju overkill. Pošto OP reče da on u stvari pokušava da dotera u red druge administratore (čitaj manji broj korisnika), mislim da nema potrebe za takav sistem osim ako nije u pitanju sličaj pod 2).

Ovde je bilo priče i o korišćenju javnih ključeva umesto lozinki za logovanje preko SSH. Ako privatni ključ držite na svom računaru, npr. standardno u ~/.ssh/, to vam je kao da ste u tekstualni fajl zapisali lozinku. Nivo sigurnosti je isti. Svako ko bi na bilo koji način došao do fajlova, imao bi otvorena vrata za dalje. Nivo sigurnosti može da se poveća ako privatne ključeve nosite sa sobom, npr. na flash-u, ali ni to nije sigurno rešenje jer je podložno krađi. Lozinka u glavi je i dalje mnogo sigurnija stvar. Ako se već koriste javni ključevi, nikad, ali NIKAD ne treba dozvoliti logovanje na root-a preko njih. Rizik je prevelik. Može da se koristi za neprivilegovane korisnike koji onda mogu da koriste "sudo" ili "su" da bi podigli svoje privilegije za šta im opet treba lozinka. U tom slučaju, čak i kada bi došlo do krađe privatnog ključa, lopov ne bi mogao da podigne svoje privilegije na sistemu bez poznavanja lozinke.

Inače, korišćenje javnih ključeva za logovanje preko SSH se ne preporučuje za interaktivno logovanje. U praksi se ovaj način logovanja treba isključivo koristiti za automatizovano logovanje gde određeni softverski paketi treba da se uloguju preko SSH i odrade nešto, npr. upload-uju backup. Olakšanje u vidu odsustva gnjavaže oko kucanja lozinke pri korišćenju javnih ključeva je zamka u koju se mnogi administratori, nažalost, upecaju.
 
...

Ovde je bilo priče i o korišćenju javnih ključeva umesto lozinki za logovanje preko SSH. Ako privatni ključ držite na svom računaru, npr. standardno u ~/.ssh/, to vam je kao da ste u tekstualni fajl zapisali lozinku. Nivo sigurnosti je isti. ... Ako se već koriste javni ključevi, nikad, ali NIKAD ne treba dozvoliti logovanje na root-a preko njih

U guzvi sam, samo kratko:

$HOME/.ssh/identity, $HOME/ssh/authorized_keys i kljucevi u /etc/ssh/ nisu isto.

Nisi nikad koristio passphrase za podizanje svog user key za logovanje na ssh server.

SSH Mastery, Michael W. Lucas, must read.

O ostalom kasnije.
 
Poslednja izmena:
Naravno da jeste, nego mene zanima da ...

Sve si lepo rek'o za Slackware i ArchLinux, ali:

1) Krivulja znanja koje sticu korisnici ova dva sistema je neuporedivo brza od korisnika Debian/Ubuntu, a vidim da je OP Ubuntu korisnik i da posle 12 godina na ovom forumu dobija savete da SSH uvija u TCPwrapper. Mislim da se i iz moje poruke vidi da su Slackware i ArchLinux predlozeni kao poligon za ucenje, a ne kao nesto sto je bolje od CentOS u produkciji, jer nisu, slabiji su, ali su najmanje jednaki za ucenje (ali su slabiji za ucenje od FreeBSD, OpenBSD, NetBSD).

2) Za cisti ssh server, bez drugih servisa, Slackware update bio bi podnosljiv (update OpenSSH + eventualni update OS) s obzirom na security track record OpenSSH, mada ne sporim nista sto si rek'o u vezi azuriranja Slackware. Opet, matf.bg.ac.rs ima javni ssh server na slackware bez problema, godinama.

3) Rolling release ustrojstvo ArchLinux je svakako minus za njegovo razmatranje kao javnog servera. Medjutim, njegov track record govori upravo suprotno, a priznajem da sam bio iznenadjen kada sam od jednog americkog PhD studenta kompjuterske sigurnosti (nije na faksu medju top5) cuo da oni na univerzitetskim serverima njihove katedre voze ArchLinux. Na jednom desktopu imam ArchLinux u dual-boot sa OpenBSD cca 2 godine i update je lagan, jedino sto stoji osecaj da cu biti bespomocan ako nesto krene naopako.

U vezi Debian

1) https://www.debian.org/security/2008/dsa-1571

2) Prosecan Debian korisnik prepoznaje se decenijama po prici o slobodi, zajednici, itd., a onda im dodje https://wiki.debian.org/systemd kao mandatory. Dakle, to je odlican sistem za one koji zele da vezbaju romantiku, retoriku, marketing, PR, masovnu hipnozu, ali ne i za one koji bi da nauce sysadmin job.

3) Sasvim licno - ne mogu da prezalim prvih 4-5 godina koje sam na Linuxu proveo na Debian/Ubuntu. Sreca moja pa je neki update na Ubuntu sjeb'o Grub, a na njihovom centralnom forumu su mi dali resenje, ali nisu hteli da mi objasne sta se desilo, vec su mi ponavljali da oni nisu 'technical user oriented' (nego prave distro za win korisnika). Posto sam u to vreme instalirao na nekom muzejskom P1 home firewall (tada aktuelni) OpenBSD 4.3, gde sam za mesec dana naucio vise o *nix i kompjuterima generalno nego za prethodnih 4-5 godina, oter'o sam ih u materinu (doslovce, uz ban na forumu) i presao na OpenBSD i na desktopu.

U vezi OpenLDAP/YPLDAP/AD

Kome god treba centralni menadzment korisnika, a ima resurse i energiju, on ce to sebi priustiti. No, ne vidim da se ovde sporimo o bilo cemu. To treba da vidi OP, ja mu nista nisam savetovao ni u prilog ni protiv toga.

Ostao sam jos duzan o OpenSSH, o tome kasnije.
 
Poslednja izmena:
U vezi OpenSSH

Kod:
$ man ssh-keygen

DESCRIPTION
...
     There is no way to recover a lost passphrase.  If the passphrase is lost
     or forgotten, a new key must be generated and the corresponding public
     key copied to other machines.
...

User key je neupotrebljiv bez passphrase (ako nije setovana empty prilikom kreiranja, sto je default). User password se teoretski i prakticno moze razbiti ako se ima pristup fajlu u kome se nalazi, za passphrase jos uvek ne postoji proof of concept razbijanja za koji sam cuo.

Public (part of) user key $HOME/.ssh/identity udaljenog korisnika smesti se u $HOME/.ssh/authorized_keys servera, odnosno (u ovom slucaju root)korisnika servera koji trazi login. U $HOME/.ssh/authorzed_keys (servera) moze biti vise razlicith kljuceva. Host_key i authorized_keys nisu isto. Privatni deo user key $HOME/.ssh/identity je samo kod korisnika i on ne moze dovesti kljuc u radno stanje bez passphrase, ako je kljuc kreiran sa passphrase. Admin servera cak (ako remote korisnik pristane) moze kreirati $HOME/.ssh/identity za udaljenog korisnika (s tim sto ovde $HOME nije root servera, samo se kljuc stavi u /root/.ssh/authorized_keys servera) i setovati jak passphrase, pa korisniku dati kljuc i saopstiti passphrase. Korisnik neka sam bira da li ce kucati passphrase uvek kada se loguje na server, ili ce napisati skriptu koja ce mu traziti passphrase svaki put kada podize racunar (ili podize X) sa kojeg se loguje na ssh server. Ovo resava remote backup/rsync root pristup.

Ako treba da biram izmedju toga da nekom dam root lozinku, ili da mu dam ssh root login (sa kljucevima) bez root lozinke, ja biram ovo potonje. (A ogranicavam fajrevalom sa koje javne ip adrese moze pristupiti ssh servisu).

Ako remote korisnik ne zeli passphrase za svoje kljuceve (kod njega identity, na serveru authorized_keys), admin servera malo sta moze da uradi.
 
Poslednja izmena:
@vix

Sve se plasim da administratori znaju kompleksne root lozinke (mnozina) napamet, da ih ne cuvaju ko zna gde (copy/paste), i da ih ne dele izmedju sebe na ko zna koje nacine. Mislim da je zbog toga i otvorena tema i da su zato kljucevi bolja opcija.
 
U vezi OpenSSH

Kod:
$ man ssh-keygen

DESCRIPTION
...
     There is no way to recover a lost passphrase.  If the passphrase is lost
     or forgotten, a new key must be generated and the corresponding public
     key copied to other machines.
...

...

Ne sporim ništa što si rekao. Kao što je neko već pomenuo, sa stanovišta korisnika (pogotovo običnih), kucanje lozinke ili passphrase za ključ dođe na isto. Većina korisnika, a tu spadaju i slabije potkovani administratori, koji posežu za korišćenjem ključeva rade to upravo iz razloga što žele da u potpunosti uklone potrebu za pamćenjem i kucanjem lozinke tj. koriste ključeve sa praznim passphrase-om. To treba sankcionisati.
 
krastavac, nije isto, private key passphrase je jedna lozinka koju korisnik treba da zna napamet, i zna je samo on.
 
Što se mene kao pokretača teme tiče, slobodno možete da raspravljate o svim aspektima sigurnosti, samo se nemojte prepucavati. Znam da proradi nama lako sujeta, admini se i pozdravljaju sa: "Bolji sam od tebe!" :D

Danas konačno izvedem promene na proof of concept serveru i ukapiram da OpenSSH 5.2 Match blok ne može da primi opseg adresa, samo pojedinačne adrese, trebalo je noviji da stavim. Sutra ću videti koji mu je limit, ako može osam adresa, biće dovoljno. Sistem potpuno pravljen da se administrira kao root, više korisnika mi se ceo dan žali na probleme. A upravi porasli apetiti, pa bi sad da se potpuno reše root-a. Šta, treba da pravim sudoers za preko 100 računara i ni sami ne znaju koliko korisnika i sa kakvim zadacima koji se stalno menjaju? Tačno onaj najgori scenario, da postanem nezvanični security guy koga će stalno da cimaju, a nisam ni doveden da administriram te servere, već aplikacioni softver na njima.
 
Čak i ako budeš morao da radiš taj najgori scenario rešenje postoji - puppet, ansible, fabric da se to automatizuje i ne boli glava (toliko).
 
...

Danas konačno izvedem promene na proof of concept serveru i ukapiram da OpenSSH 5.2 Match blok ne može da primi opseg adresa, samo pojedinačne adrese, trebalo je noviji da stavim. Sutra ću videti koji mu je limit, ako može osam adresa, biće dovoljno. Sistem potpuno pravljen da se administrira kao root, ,,,.

Proveri man sshd_config, sekcija PermitRootLogin, opcija 'forced-commands-only'. Zvuci interesantno, mozda ti resava nesto. Do sada na to nisam obracao paznju, ali razmena misljenja zna trgne iz kolotecine i laznog samozadovoljstva i da covek nauci nesto. Ne vidim da se ovde neko prepucava, bas lepo i korisno diskutujemo.
 
Sve si lepo rek'o za Slackware i ArchLinux, ali:

U vezi Debian

1) https://www.debian.org/security/2008/dsa-1571

Zao mi je sto ranije nisam video ovu diskusiju, a mogao sam da pomognem obzirom da se 10+ godina borim i sa LDAP-om i radiusom, ali bitno je da je kolega morbius dosao do resenja koje mu, jelte, radi posao.

Ali ovaj link gore me je ponukao da odgovorim, jednostavno moram.

Centos i RH konkretno nemaju ovaj propust, niti ima sanse da ga imaju, obzirom da je svaki skok sa jedne na drugu krupnu verziju povlacio totalnu reinstalaciju sistema. Takodje nigde se ne pominje ozloglaseni rpm-hell koji je ne jednog sistem administratora doveo do nervnog sloma.

Ali da se vratimo na nekadasnje nepostojanje on-line update sa jedne na drugu verziju RH-a, sto je predstavljao ubedljivo najgori aspekt ove linux familije. Nemam ja vremena da svojih sada vec 100+ servera na svakih 3,4,5 godina instaliram od nule, bilo to fizicki, bilo virtuelizovani serveri. U ranim danima karijere preferirao sam slack, ali cim je broj odrzavanih servera presao ono sto moze da se prebroji na prstima obe ruke, stvari su poceli da izmicu kontroli a administracija je postala teska i zamorna.

Istini za volju ovo ne vazi za najnoviji RH i Centos, gde je online update moguc, ali za mene je to too little too late.... nema nikakve teorije da tolike servere migriram na bilo sta drugo.

Kolega 555 je takodje zaboravio da spomene da centos konkretno jeste na zlom glasu zbog prilicno tromog pracenja RH-a i sporog reagovanja na neke propuste u proslosti, pa su neke prilicno ozbiljne rupe zvrjale otvorenima mesecima iako su u upstream-u, odnosno u RH-u, bile zapusene.

Generalno u vec vise od decenijski dugoj praksi debian mi se pokazao najzahvalnijim za administraciju. Par puta desilo mi se da godinama zaboravljeni server na debianu 3 ili 4 bez nekih vecih trzavica dovedem na najmoderniju verziju. To ni na jednom distrou nikada nije bio slucaj.
 
Само бих желео да напишем ово
CentOS 5 у 2015? o_O
 
Nazad
Vrh Dno