Jak omezit uživatele SSH?

[Filip Jirsák]

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.

[Reklama]

[Jan Fikar]

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.

[Bugsa]

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.

[veskotskujehnusne]

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.

[Jan Fikar]

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.

[Reklama]

[Michal Šmucr]

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.

[LolPhirae]

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. 

[Filip Jirsá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á.

[Michal Šmucr]

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.

[Jose D]

..

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.

[Michal Šmucr]

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.

Kód: [Vybrat]

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.