Fórum Root.cz
Hlavní témata => Server => Téma založeno: hknmtt 21. 03. 2025, 14:57:12
-
Mam dedikovaneho pouzivatela, ktory sa ako jediny moze SSHnut na server. Nasledne sa pouzivatel musi prehlasit do roota(schvalne nemam sudo pouzivatelov). Chcel by som tohto "ssh" pouzivatela obmedzit v tom, ze nemoze na serveri nic realne robit. Je to nejak mozne? Pozeral som, ze by mozno bolo mozne obmedzit pouzivatela aby nemohol vyjst zo svojej domacej zlozky, pripadne upravit bash config, ale neviem ktory postup je najvhodnejsi. Prakticky uloha tohto pouzivatela je len spominany ssh login + moznost nahravat subory do svojej home slozky, ktore potom root moze prekopirovat kam je potreba.
-
Je to popsané v článku Jak nahradit FTP pomocí SFTP a zamknout uživatele (https://www.root.cz/clanky/jak-nahradit-ftp-pomoci-sftp-a-zamknout-uzivatele/).
-
To je iba obmedzenie pre sftp zlozky, mne ide skor o to ked sa pouzivatel sshne do systemu, aby realne jedine co mohol urobit, okrem uploadu suboru, sa mohol prakticky iba prehlasit cez su do roota. Cize nechcem aby sa prechadzal po systeme alebo spustal akekolvek prikazy. Ratam ze asi najvhodnejsie je upravit jeho bash skript a povolit len nejake prikazy, tzn. nemoze napriklad cd / alebo rm /foo/bar
-
https://serverfault.com/questions/149673/how-to-prevent-a-user-from-login-in-but-allow-su-user-in-linux
-
Já bych začal provedením "mozkového přemýšlení". Ty chceš, aby mohl su do roota, takže mu dáváš admina, ale chceš, aby ten admin nemohl nic dělat. To mi nějako nevychádza.
To je iba obmedzenie pre sftp zlozky, mne ide skor o to ked sa pouzivatel sshne do systemu, aby realne jedine co mohol urobit, okrem uploadu suboru, sa mohol prakticky iba prehlasit cez su do roota. Cize nechcem aby sa prechadzal po systeme alebo spustal akekolvek prikazy. Ratam ze asi najvhodnejsie je upravit jeho bash skript a povolit len nejake prikazy, tzn. nemoze napriklad cd / alebo rm /foo/bar
-
Já bych začal provedením "mozkového přemýšlení". Ty chceš, aby mohl su do roota, takže mu dáváš admina, ale chceš, aby ten admin nemohl nic dělat. To mi nějako nevychádza.
Ale vychadza, v podstate se snazi vybudovat jump host, resp. jump ucet ktery nemuze vubec nic. (su na roota chce heslo/2FA pokud tam ma nejaky ten pam_radius apod.)
Na prvni pohled mi to prijde jako netrivialni, urcite neco jde udelat pres openssh (zakazat vsechny mozne forwardingy) a pres iptables -m owner, z chrootu by se su-ckovalo blbe, takze spis neco jako forced firejail mozna, urcite by toho slo dosahnout pres selinux, ale tam bych (pokud uz nekdo reseni nema hotove) to jako moc trivialni nevidel.
-
Účet který "nemůže nic", jen změnit na roota (tedy vlastně může všechno)? K čemu to je?
Možná jsme to špatně pochopili a nejde o stejného uživatele?
-
command="/bin/su -" na zacatek radku v authorized_keys jsi zkusil?
-
Takže by se to celé neobešlo bez plného admina, který může všechno?
Já bych začal provedením "mozkového přemýšlení". Ty chceš, aby mohl su do roota, takže mu dáváš admina, ale chceš, aby ten admin nemohl nic dělat. To mi nějako nevychádza.
Ale vychadza, v podstate se snazi vybudovat jump host, resp. jump ucet ktery nemuze vubec nic. (su na roota chce heslo/2FA pokud tam ma nejaky ten pam_radius apod.)
Na prvni pohled mi to prijde jako netrivialni, urcite neco jde udelat pres openssh (zakazat vsechny mozne forwardingy) a pres iptables -m owner, z chrootu by se su-ckovalo blbe, takze spis neco jako forced firejail mozna, urcite by toho slo dosahnout pres selinux, ale tam bych (pokud uz nekdo reseni nema hotove) to jako moc trivialni nevidel.
-
Este raz teda:
- system nema ziadnych sudo pouzivatelov
- existuje iba jeden pouzivatel, nazvime ho ssh-user, ktory sa moze sshnut do systemu, iba s klucom(tzn. nie heslo alebo ina forma autentifikacie)
- tento pouzivatel moze neobmedzene nahratvat subory do svojej home zlozky
- tento ssh-user by nemal mat moznost inak robit nic v systeme, okrem "su root", cize nemoze mutovat system alebo subory mimo svojej home zlozky, taktiez by nemal mat moznost vypisovat obsah zloziek mimo svojej home zlozky
jedinym ucelom tohto ssh-user pouzivatela je pristup do systemu, povedzme len do "predsiene" ale nie to celeho domu, a moznost nahrat do povolenej zlozky(/home/ssh-user) subory(sftp).
pre objasnenie, tieto subory su aplikacia + konfiguracne subory, ktora na serveri bezi ako hlavny ucel serveru. v pripade ze unikne ssh kluc von, utocnik sa dostane len do home zlozky tohto pouzivatela a nemoze robit nic co by ovplyvnilo system pretoze by musel bruteforcnut roota.
normalne by sa po nahrati suborov mal pouzivatel prehlasit na roota a ako root potom premiestnit nahrane subory, nova verzia aplikacie, na pozadovane miesto a vykona pozadovane ukony(restart sluby a podobne).
-
chroot?
-
- tento ssh-user by nemal mat moznost inak robit nic v systeme, okrem "su root", cize nemoze mutovat system alebo subory mimo svojej home zlozky, taktiez by nemal mat moznost vypisovat obsah zloziek mimo svojej home zlozky
Hmmm, tak normálně uživatel v Linuxu může mutovat jenom soubory v $HOME a v /tmp. Proč by nemohl vypisovat obsah jiných adresářů? Třeba když zakážete vypisovat (RX) /usr/bin/ tak to nebude fungovat.
Zase lehko zakážete přístup do /home/tajny_user, jestli šlo v první řadě o toto. Většina distribucí má práva tak, že si uživatelé navzájem nevidí soubory. Pokud bude znát heslo na su, tak se tam dostane.
-
Este raz teda:
- system nema ziadnych sudo pouzivatelov
- existuje iba jeden pouzivatel, nazvime ho ssh-user, ktory sa moze sshnut do systemu, iba s klucom(tzn. nie heslo alebo ina forma autentifikacie)
- tento pouzivatel moze neobmedzene nahratvat subory do svojej home zlozky
- tento ssh-user by nemal mat moznost inak robit nic v systeme, okrem "su root", cize nemoze mutovat system alebo subory mimo svojej home zlozky, taktiez by nemal mat moznost vypisovat obsah zloziek mimo svojej home zlozky
jedinym ucelom tohto ssh-user pouzivatela je pristup do systemu, povedzme len do "predsiene" ale nie to celeho domu, a moznost nahrat do povolenej zlozky(/home/ssh-user) subory(sftp).
pre objasnenie, tieto subory su aplikacia + konfiguracne subory, ktora na serveri bezi ako hlavny ucel serveru. v pripade ze unikne ssh kluc von, utocnik sa dostane len do home zlozky tohto pouzivatela a nemoze robit nic co by ovplyvnilo system pretoze by musel bruteforcnut roota.
normalne by sa po nahrati suborov mal pouzivatel prehlasit na roota a ako root potom premiestnit nahrane subory, nova verzia aplikacie, na pozadovane miesto a vykona pozadovane ukony(restart sluby a podobne).
Pořád se to snažím pochopit, ale vlastně mi moc nedává smysl nepoužít sudo, polkit nebo doas, kde si můžu vcelku rozumně nakonfigurovat, co může daný uživatel spouštět. Hlavně na rozdíl od příkazu su pak se může vyžadovat heslo toho uživatele a ne roota.
Další věc co mě pak napadá. Je opravdu na správu té aplikace nějakým externím adminem potřeba kopírovat soubory přes scp, někam pak rozbalovat archivy a hrabat se v systému s nejvyššími právy?
Pro řešení aktualizací (resp. lifecycle a deploymentu) aplikací je spousta popsaných a ozkoušených řešení počínaje kontejnerizace s Kubernetes, přes hostování nějakého vlastního docker registry, spousty nějakých dalších relativně sofistikovaných orchestrací až po třeba po relativně jednoduchá řešení na bázi pevných aktualizačních skriptů.
Ty mi pak například můžou udělat pull z nějaké specifické větve git repozitáře, odkud se to také předtím otestovalo, zastavit služby, spustit připravené migrační skripty, znovu služby nahodit a zalogovat někam výsledek.
Celé tohle může být v jednom bash skriptu, který pak bude moct být spouštěný tím sudem pod jiným uživatelem.
Navíc se to výrazně zjednoduší, pokud byste dělal tenhle proces na víc než na jednom serveru - i když počítám minimálně testovací a produkční.
-
- tento ssh-user by nemal mat moznost inak robit nic v systeme, okrem "su root", cize nemoze mutovat system alebo subory mimo svojej home zlozky, taktiez by nemal mat moznost vypisovat obsah zloziek mimo svojej home zlozky
Hmmm, tak normálně uživatel v Linuxu může mutovat jenom soubory v $HOME a v /tmp. Proč by nemohl vypisovat obsah jiných adresářů? Třeba když zakážete vypisovat (RX) /usr/bin/ tak to nebude fungovat.
Zase lehko zakážete přístup do /home/tajny_user, jestli šlo v první řadě o toto. Většina distribucí má práva tak, že si uživatelé navzájem nevidí soubory. Pokud bude znát heslo na su, tak se tam dostane.
Je mozne, ze to zbytocne komplikujem. Na druhu stranu, ak je pouzivatela mozne takto obmedzit, nejakou jednouchou formou, tak preco nie.
-
Napísať vlastný shell.
P. S.: /usr/sbin/nologin
-
Pokud chcete, aby ten přihlášený uživatel nemohl udělat nic, jen se mohl přihlásit na roota, zakažte tomu uživatelskému účtu přihlašování (nebo jej úplně zrušte) a tomu uživateli (člověku) dejte klíč k uživateli root. Bude se tedy přihlašovat přímo na roota. Ten krok navíc s přihlášením jako jiný uživatel je tam zbytečný, nic nepřináší – a pokud vám z nějakého důvodu vadí, prostě jej zrušte.
Jinak ten váš požadavek je od základu nesmyslný. Jako root má ten uživatel nejsilnější možná oprávnění, může úplně všechno. Takže bránit mu, aby před tím něco neudělal jako běžný uživatel, je naprosto zbytečné. Když to bude chtít udělat, tak se přepne na roota a prostě to udělá. Jakékoli opatření, které uděláte, může jako root obejít nebo zrušit.
Pokud řešíte nějaký reálný problém a potřebujete s ním poradit, popište ten reálný problém. Vy jste popsal jen své řešení (zakázat něco uživateli ale povolit mu přepnutí na roota), které nedává žádný smysl.
-
Ještě by asi šel chroot jail, jak někdo navrhoval.
Třeba tady: https://www.tecmint.com/restrict-ssh-user-to-directory-using-chrooted-jail/
Ale stejně prostě ty klíče nenechat uniknout, časem je měnit, pokud uniknou, tak změnit hned. Taky jich může být víc, když unikne jeden, ten zakážu a ostatní budou fungovat.
-
Jako root má ten uživatel nejsilnější možná oprávnění, může úplně všechno. Takže bránit mu, aby před tím něco neudělal jako běžný uživatel, je naprosto zbytečné. Když to bude chtít udělat, tak se přepne na roota a prostě to udělá.
Já to pochopil tak, že je to pokus o jakousi "bezpečnost". Prvně se přihlásí jako uživatel co nic nemůže (nevím jestli heslem nebo klíčem) a pak se přes su (zadáním hesla root) přepne na roota.
-
A to je přesně tak blbost. Nemá cenu, někomu s právy roota v čemkoli bránit.
Jako root má ten uživatel nejsilnější možná oprávnění, může úplně všechno. Takže bránit mu, aby před tím něco neudělal jako běžný uživatel, je naprosto zbytečné. Když to bude chtít udělat, tak se přepne na roota a prostě to udělá.
Já to pochopil tak, že je to pokus o jakousi "bezpečnost". Prvně se přihlásí jako uživatel co nic nemůže (nevím jestli heslem nebo klíčem) a pak se přes su (zadáním hesla root) přepne na roota.
-
Mimochodem ty ssh klíče jde navíc zabezpečit passphrase, takže i když se "ztratí", tak bez passphrase je útočníkovi na nic.
Akorát se musí pokaždé dávat passphrase. V Linuxu to jde hezky nakešovat, ptá se jen jednou. Používám pro to keychain. Dá se do .bashrc a hotové. Po přihlášení se jednou zeptá a pak už si to pamatuje.
-
Jen pro kontext. Myslím, že to v podstatě jen navazuje na předchozí vlákno klíče vs hesla od stejného tazatele..
https://forum.root.cz/index.php?topic=30413.0
Mimochodem ty ssh klíče jde navíc zabezpečit passphrase, takže i když se "ztratí", tak bez passphrase je útočníkovi na nic.
Ta obava pravděpodobně vychází z toho, co tam zaznělo na konci toho vlákna, a v určitém kontextu může být oprávněná námitka proti klíčům. Tzn. pokud se na server přihlašují další lidé, co mají povolený přístup přes své privátní klíče, tak je nelze žádným způsobem (ze serveru) donutit, aby je měli nebo udrželi zaheslované.
Tzn. prakticky, pokud si třeba někdo vypne heslo na privátním klíči pomocí ssh-keygen (nebo puttygen), aby ho to neotravovalo, a pak mu někdo vyluxuje home adresář.
Podobně určité typy útoků, když pak používá ssh-agenta.
Do jaké míry tohle řešit (i třeba nějakými obskurnostmi, které můžou přinést jiné problémy) v rámci daného pracovního týmu, a jestli to je fakt reálný problém, je samozřejmě otázka.
Systémové řešení tohohle je pak přes další faktor, OTP.. ale zas každá věc má své.
Jak jsem zmiňoval, mě tohle spíš přijde jednotlivost v rámci správy a "devops" na tom systému, systémech.
Pokud je tam jediný člověk nebo opravdu úzký tým, co to řeší vlastně všechno a měl by trvale používat tuhle "předsíň" a pak dělat dál všechno pod rootem, tak je to s odpuštěním kravina.
Naopak pokud jsou to nějací další lidé, co mají spravovat svou appku, tak jim nikdy nedám plného roota. Při představě, manuálních úprav, kdy tam bude při změně verze někdo blbnout s kopírováním, rozbalováním archivů, co si tam nasype. Následné blbnutí s právy (chmod, chown), restartem systémových služeb, kdy může rozbít cokoliv dalšího... když jim nevěřím ohledně klíčů, proč bych jim měl dát tuhle možnost.
Proto jsem mluvil spíš o rozdělení těch činností, kontejnerech, automatizaci nebo byť i třeba jednoduchém povoleném (sudo) aktualizačním skriptu, který bude připravený dopředu a prostě si stáhne a zaktualizuje, co je potřeba. Můžou se s tím v souvislosti s tím prozkoumat třeba i Ansible playbooky atd.
-
Akorát se musí pokaždé dávat passphrase. V Linuxu to jde hezky nakešovat, ptá se jen jednou. Používám pro to keychain. Dá se do .bashrc a hotové. Po přihlášení se jednou zeptá a pak už si to pamatuje.
Ano, pod Windows umí to samé Pageant (součást PuTTy). Ale jinak je podle dotazu a diskuse lepší vynalézat rovnák na ohejbák. ::)
-
Ta obava pravděpodobně vychází z toho, co tam zaznělo na konci toho vlákna, a v určitém kontextu může být oprávněná námitka proti klíčům. Tzn. pokud se na server přihlašují další lidé, co mají povolený přístup přes své privátní klíče, tak je nelze žádným způsobem (ze serveru) donutit, aby je měli nebo udrželi zaheslované.
Tzn. prakticky, pokud si třeba někdo vypne heslo na privátním klíči pomocí ssh-keygen (nebo puttygen), aby ho to neotravovalo, a pak mu někdo vyluxuje home adresář.
Podobně určité typy útoků, když pak používá ssh-agenta.
O vynucení přihlašování heslem kvůli vynucení politiky hesel a zabránění používaná klíče bez hesla si myslím své, ale jakási logika v tom je.
To, co se řeší tady – tedy povolení uživateli su na roota, ale pokus co nejvíc omezit původního uživatele – žádnou logiku nemá.
-
To, co se řeší tady – tedy povolení uživateli su na roota, ale pokus co nejvíc omezit původního uživatele – žádnou logiku nemá.
Taky mi to moc smysl nedává, zvlášť v popsaném užití.
I technicky je to celé problém.
Ono zmíněné omezení příkazů v shellu se dá sice udělat relativně jednoduše.
Např. když se nastaví restricted bash (rbash) jako login shell, přerazí se proměnná PATH a udělají se symlinky na vybrané příkazy do home adresáře, včetně třeba su.
Popsáno třeba tady (snad to bude čitelné bez přihlášení):
https://access.redhat.com/solutions/65822
Jsou pak i speciální shelly, kde se to dají vybrané příkazy explicitně deklarovat v konfiguraci namátkou třeba lshell.
Potíž je ale pak v tom, že tazatel chce vlastně zároveň ssh chroot, aby se uživatel nedostal nikam jinam než do domácího adresáře, ať už příkazy z shellu nebo přes sftp.
Což se sice také dá, ale žádné symlinky, knihovny a přístupy do základních devnodů mimo chroot pak nemůžou fungovat. Jde tam sice v omezeném množství přímo něco manuálně nakopírovat, vytvořit devnody pro nějaké elementární používání.
Nicméně programy jako su nebo sudo jsou setuid aplikace a mívají spousty vazeb na další subsystémy jako pam, selinux, apparmor atp. a hlavně potřebují přístup do hesel, skupin atp.
Což je naprosto proti smyslu chrootu/jailu a většinou to logicky nejde.
-
..
no, asi dost ze zadání zůstalo nevyřčeno, ale kdybych to řešil, tak pro roota rozjedu ssh server na třeba 2222 s autentizací klíči nebo certifikáty, a pro ty kejkle se soubory rozjedu jinou instanci ssh na p22, třeba jen v rootless kontejneru pod tím dedikovaným uživatelem s namapovaným volume a se všemi těmi omezeními. Vůbec bych ty dva přístupy nekombinoval.
-
no, asi dost ze zadání zůstalo nevyřčeno, ale kdybych to řešil, tak pro roota rozjedu ssh server na třeba 2222 s autentizací klíči nebo certifikáty, a pro ty kejkle se soubory rozjedu jinou instanci ssh na p22, třeba jen v rootless kontejneru pod tím dedikovaným uživatelem s namapovaným volume a se všemi těmi omezeními. Vůbec bych ty dva přístupy nekombinoval.
Jasně, ale on tam taky nejspíš chtěl mít ten mezikrok s dalším přihlašováním (nejdřív klíč, pak heslo pro jiného uživatele).
Jako normálně se podobné věci třeba v určitých situacích řeší tak, že je tam nějaká forma bastionu resp. jump hosta.
Třeba VPN na bastion, pak ssh. Nebo dva ssh servery za sebou. Zároveň pak taky záleží na segmentaci a struktuře sítě.
Technicky vzato, tohle by bylo schůdnější, než trvat na příkazu su, a dalo by se to nejspíš vyřešit i v rámci jednoho stroje, klidně bez kontejnerů a s jednou instancí sshd.
Subsystem sftp internal-sftp
PasswordAuthentication no
Match User localuser, Host 127.0.0.1
PasswordAuthentication yes
Match User root, Host 127.0.0.1
PermitRootLogin yes
PasswordAuthentication yes
Match User remoteuser
ChrootDirectory %h
# home adresar musi byt vlastnen rootem, nadelane podslozky pak tim userem, aby mohl zapisovat
AllowTCPForwarding local
X11Forwarding no
ForceCommand internal-sftp
Tohle by zařídilo to, že remoteuser nebude mít interaktivní přihlášení, ale jen sftp a bude v chrootu.
Lokální forwardování u něj bohužel musí být povoleno, aby přes něj fungovalo tunelování portu na lokální ssh.
Také mají všichni uživatelé zvenku vynucené přihlašování klíčem, mimo localusera resp. roota.
Na tohle by se pak dalo připojit třeba takhle:
ssh -i ~/muj_klic -J remoteuser@server localuser@127.0.0.1
resp.
ssh -i ~/muj_klic -J remoteuser@server root@127.0.0.1
První připojení se ověřuje klíčem na účtem remoteuser, druhé (tunelované) pak na loopback a zeptá se na heslo.
Samozřejmě pokud by těch stejných serverů s adresou 127.0.0.1 bylo víc, tak aby se to nepletlo, použil bych volbu HostKeyAlias pro unikátní záznamy v known_hosts.
Podobně se nechá pak připojovat i v PuTTY, tak je ten jump host v sekci Proxy.
Tohle by bylo funkčně asi nejblíž tomu, co tazatel chtěl.
Ale samozřejmě, jak už jsem psal, daleko víc než na tohle bych se koncentroval, proč tam má někdo další lézt a řádit pod uživatelem root a jestli by se to celé nedalo udělat líp.