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.
