Dotaz: Hesla pro NFS/NIS bez přístupu na konzolu serveru ?

[psm]

Následující model : ve škole v PC učebně je mimo stanic umístěn i server.

Řeším problém, jak zařídit, aby se pomocí NIS/NFS mohl přihlásit běžný uživatel na některé stanici ke své složce na serveru, která je pomocí NFS namapována v tu chvíli na stanici, ALE ABY SE NEMOHL fyzicky přihlašovat přímo na serveru (z jeho klávesnice). Jde to nějak ?

Dříve se uživatelé přihlašovali pouze přes SAMBU a hesla do SAMBY (v roli PDC) umožňovala pouze přihlášení vzdálené (lokální přístup měl uživatel zakázán - ani tehdy neměl heslo v SHADOW).

Teď při dodatečně aktivované možnosti NFS (aby se mohl user přihlásit i na linuxové stanici) se asi musí uživateli povolit heslo v SHADOW a povolit mu přístup. Hesla jsou pak distribuovaná přes NIS na stanice. Ale každý se tudíž může svým heslem zalogovat ke konzole serveru.

Jde s tím něco udělat ? Aby si DĚTI NEHRÁLY SE SERVEREM ...

Odpovědi

[stybla]

strelim od boku - na serveru v /etc/nsswitch.conf nastavit pro shadow pouze lokalni uzivatele(files). a ssh poresit pres netgroups.
snad jsem moc neprestrelil, a kdyz, tak rad se poucim.

[VSi]

Řešil jsem podobnou situaci, sice s LDAP, ale v principu to bude fungovat i s NIS.

Uživatelům, kteří nemají mít povoleno přihlášení na konzoli serveru jsem nastavil shell např. /bin/restricted_shell a na serveru jsem udělal symlink /bin/restricted_shell -> /bin/false (tj. není možné přihlášení), na stanicích, kde má být umožněno přihlášení pak /bin/restricted_shell -> /bin/sh.

Další možností je využít PAM modul, který bude řídit oprávnění k přihlášení podle příslušnosti k určité skupině, myslím že se jmenoval pam_group. Tím jde ošetřit i rozdílná oprávnění k přihlášení na konzoli, přes ssh nebo třeba v gdm.

[stybla]

a neni efektivnejsi ponechat uzivatele ve "virtualnim" stavu(NIS/LDAP/...) a povolit prihlaseni pouze lokalnim uzivatelum nebo uzivatelum skupiny XYZ napr. sysadmin? tim samozrejme navrhovane reseni neshazuji, take to jde.

[VSi]

Pokud jsou uživatelé "virtuální", tj. v LDAP, pak je potřeba mít na serveru v nsswitch - passwd jako zdroj i LDAP (kvůli NFS a UID/GID). Přihlašování heslem probíhá přes PAM, takže na serveru je možné nechat v PAM jen unix modul. V případě NIS je to komplikovanější v tom, že všichni uživatelé jsou aA serveru v /etc/passwd a /etc/shadow a nelze snadno rozlišit ty lokální a "virtuální", ale tady si nejsem jistý, budu rád když mě někdo opraví.

Nevím, jak máte na mysli "povolit prihlaseni pouze lokalnim uzivatelum nebo uzivatelum skupiny XYZ napr. sysadmin", ale mě napadá jedině řešení - pomocí nějakého PAM modulu.

Když jsem to řešil, byl jsem rád, že jsem zprovoznil PAM s LDAP a unix účty a to řešení s shellem mi přišlo v dané situaci nejschůdnější.

[stybla]

Ad virtualni - ano, presne tak to bylo mysleno. Cokoliv co neni v /etc/passwd, /etc/shadow/, ... etc.

Ad PAM/nsswitch - jsou (z meho pohledu) dve rozdilne veci resp. obe jsou od stejne firmy, poskytuji to same, ale jinak(nsswitch resi pouze pristup k informacim). Za nsswitch jsem osobne vice nez vdecny, protoze Slackware nema PAM rad :)

Ad netgroups - musim citovat z knizky(O'Reilly LDAP System Administrator):

Netgroups have become a daily staple for NIS administrators. They allow machines and/or users to be collected together for various administrative tasks such as grouping machines together for use in the tcp_wrappers files /etc/hosts.allow and /etc/hosts.deny.

jinak modul pro PAM se jmenuje pam_groupdn, v nsswitch netgroup. Ted uz je to asi jasne. Myslim, ze jsem se jenom spatne vyjadril.

Ad NIS - ze ma NIS informace v lokalnich souborech, to jsem nevedel. Potom je PAM/nsswitch zbytecna kombinace. Nicmene, netgroups by melo fungovat take.

[VSi]

Jen bych doplnil, že o nsswitch a PAM neposkytují úplně to samé, už se to tu několikrát řešilo. Ale je pravda, že pro základní použití by se tak dalo brát.

Ve Slackware je trochu specifická situace, protože nepoužívá PAM. Jinak všechny moderní distribuce PAM mají a pak to funguje asi takhle (jen shrnutí):

nsswitch - se používá pro jmenné služby, tj. třeba překlad UID > login, nebo získání informací o uživateli, tj. taková abstrakční vrstva nad /etc/passwd, /etc/groups, /etc/hosts a někdy dalšími. Informace může získávat z klasických souborů, NIS, LDAP ...

PAM - se používá pro řízení přístupu, tedy např. ověřování heslem. PAM tedy "nahrazuje" klasický /etc/shadow. Aplikace, která požaduje ověření heslem, pak nepoužije čtení shadow, ale PAM. Pravda je, že většinou je v PAM použit modul unix, který stejně nakonec používá soubor /etc/shadow.

Výhoda PAM je v tom, že lze použít různé moduly pro omezení přístupu, čtečky otisků prstů ap. a hlavně lze použít různé zdroje ověření pro různé aplikace (třeba ssh jen z /etc/passwd a mailserser podle LDAP).

Je pravda, že nsswitch může poskytovat i hesla, ve formě abstrakce dat z /etc/shadow (právě třeba z NIS), ale není to tak mocné jako PAM.

O NIS toho moc nevím. Chtěl jsem ho nasadit, ale většina návodů zmiňovala LDAP jako modernéjší a flexibilnější metodu, tak jsem se do něj pustil. NIS je určitě starší a zavedenější, hlavně mimo čistě linux prostředí (třeba SUN).

[psm]

Díky neboli jestli dobře chápu : i když se obsah passwd přenese přes NIS na stanici a tudíž by tam bylo u související položky
/bin/bash de fakto povolení přístupu. Ale když si tam místo toho dám restricted_shell, tak ten si na serveru načte hodnotu třeba
/bin/bash a na stanice /bin/false ? A ještě jeden dotaz : musí tam být v souboru NISu - MAKEFILE u položky "all" taky "shadow" ? trochu nerozumím, zda to načítání shadow do passwd se provádí až na stanici (podle nsswitch) NEBO zda to musí být už v těch připravených databázích NIS na serveru.

[VSi]

Trik spočívá v tom, že jako shell dáte třeba ten /bin/restricted_shell (v /etc/passwd) a pak vytvoříte symlinky:

# ln -s /bin/false /bin/restricted_shell -- na serveru, zabrání přihlášení

# ln -s /bin/sh /bin/restricted_shell -- na klientech, umožní přihlášení

Jinak s NIS nemám zkušenosti, podle mě je dnes lepší LDAP, i když je možná trochu složitější na pochopení. Nedávno tady ale byl pěkný seriál, jak zprovoznit právě sdílení uživatelských účtů přes OpenLDAP.

Nastavení NIS bych nechal, jak je teď. Jen je potřeba daným uživatelům změnit shell a pak vytvořit ty symlinky, viz výše.

[psm]

Díky - předpokládám, že :

a) ty pomocné soubory se mohou jmenovat jakkoli - třeba xxx s délkou nula (?)

b) a pak :

ln -s /bin/false /bin/xxx #server
ln -s /bin/bash /bin/xxx #klient

Umístění jak souboru xxx i příslušného Já totiž koukal na rbash (resctricted bash) a ten má konkrétní funkční omezení všeho možného ... ... předpokládám, že tady o to nejde, protože se vždy volá skutečná substituce toho xxx nebo se pletu a ten pomocný bash musí být skutečný shell ?

[VSi]

Přesně tak, ten název byl jen jako příklad. Nevím, jestli přesně chápete, jak funguje symlink - je to vlastně takový odkaz na souborovém systému.

Na sereru tedy v konzoli spustíte tenhle příkaz:

ln -s /bin/false /bin/xxx -- tím se vytvoří symlink tj. soubor /bin/xxx, který bude "odkazovat" na již existující soubor /bin/false.

Na klientech spustíte analogicky ten druhý příkaz.

A nakonec na serveru v /etc/passwd (nebo přes nějaký nástroj, třeba usermod) nastavíte patřičným uživateům shell /bin/xxx - no a soubor /bin/xxx je ten odkaz - symlink, který jste vytvořil příkazem ln. Doufám, že už je to jasnější, jinak doporučuji si přečíst Wikipedia: Symbolický_odkaz

Rbash je něco trochu jiného, v tomto případě není potřeba.

[vencas]

Co třeba

man pam_listfile

A v sekci examples druhý příklad ("To allow login access only for certain users, you can use a /etc/pam.d/login entry like this:")

[JardaK]

Následující model : ve škole v PC učebně je mimo stanic umístěn i server.
...Aby si DĚTI NEHRÁLY SE SERVEREM ...

Nezlobte se, ale řešíte naprosté zbytečnosti. Pokud mají žáci fyzický přístup k serveru, tak jejich přihlášení coby obyčejný uživatel, je to nejmenší.

Zajistíte, aby vám žáci pomocí šroubováku nezačali server rozebírat? Aby nevytahovali napájecí a síťové kabely? Aby nerestartovali a nevypínali server? Aby do severu nekopali? Pokud tohle zajistíte, již nemusíte řešit jejich fyzické přihlašování na server.

Také jsem před několika lety měl server v učebně. Nyní jsou oba servery u mě v kabinetě (serverovně). Prostě vyličte řediteli děj katastrofického filmu Server v učebně. Tak jako ředitel má ředitelnu, učitelé kabinety a sborovnu, server musí mít serverovnu.

P.S.: Na mail vám ještě dnes odpovím

[psm]

Díky - počkám na mail - ještě bych si rád vyjasnil, jak je to s tou podporou SHADOW hesel v NIS.

a) má být na serveru v konfiguračním souboru.

/var/yp/Makefile

v řádku all: povoleno shadow nebo ne ?.

b) a co je pak tedy na stanici v souboru.

nsswitch.conf

v řádku shadow ? Pouze "shadow files" nebo "shadow nis files" ?.

Jinými slovy : všude se píše o tom, že se pro potřeby NIS slučují údaje z passwd a shadow do souboru passwd ....
A že distribuce shadow přes NIS je bezpečnostní díra..

Jak je tedy správná konfigurace pro verzi NIS, pokud jde o položku shadow (nemluvím o NIS+) ?

[psm]

Tak aspoň na tohle si odpovím sám - po nějakých testech jsem zjistil, že v této verzi Mandrivy (2008 Spring) už NIS distribuuje i SHADOW, merging PASSWD+SHADOW se dá zapnout (default OFF), ale není to třeba, protože NONROOT user se sice zaloguje na stanici pomocí NIS loginu a hesla, příkazem YPCAT ani jinak si ale nevypíše obsah PASSWD.BYNAME apod.

[Zdeněk Štěpánek]

Naopak ja mam server primo v ucebne a schvalne je nakonfigurocanej stejne, takze se zaci vklidu muzou prihlasit i na nej.

Nevidim v tom absolutne zadny problem. Pokud se prihlasi na klienta, tak je to stejne jako by sedel u serveru, jen ma mezi klavesnici a serverem kus transparentniho ethernetu.

Naopak jsem rad ze sit ja zatizena o jednoho klienta min.

S tim ze si zaci hrajou s kabelama zasadni problem nemam. Obcas ho nekdo v nevedomosti vypnul coz jsem vyresil papirem s textem: "Jeste jednou nekdo tenhle server vypne tak budu sekat pazoury!" Od te doby je klid.

Zdenek