Řešení 1:
Jak již uvedli ostatní, deaktivace sftp není ani zdaleka dostačující – uživatel s neomezeným ssh přístup může zobrazit jakýkoli soubor, k jehož zobrazení má jejich účet oprávnění, může upravit vše, co má oprávnění k úpravě, a může snadno stáhnout vše, co může číst, do svého počítače. Jediný způsob, jak jim v tom zabránit, je skutečně omezit jejich přístup. Také není ideální spoléhat se na .profile omezit uživatele, protože k tomu to není (Edit:Jak zmiňuje Aleksi ve své odpovědi, je ve skutečnosti triviální obejít .profile; věc o .profile je, že je to pro pohodlí, nikoli pro bezpečnost, takže není určen k omezení uživatele. K zajištění bezpečnosti používejte věci navržené pro zabezpečení, jako jsou věci níže).
Existují dva základní způsoby, jak toho dosáhnout:můžete je omezit prostřednictvím oprávnění k souboru nebo je přinutit, aby spouštěly pouze vaši konzolovou aplikaci. Druhý způsob je lepší:Přiřadit uživatele, kteří by měli být omezeni na konzolovou aplikaci, do skupiny (např. customers ); poté v sshd_config , přidejte následující řádky:
Match Group customers
ForceCommand /path/to/app
To znamená, že všechna připojení od uživatelů v této skupině otevírají aplikaci konzoly; nemohou spustit nic jiného, včetně sftp serverový nástroj. To jim také zabrání dělat cokoli jiného se systémem a na rozdíl od .profile , dělá to pomocí samotného serveru SSH (.profile omezuje je na shell, ForceCommand také zabraňuje provádění dalších věcí, které nezahrnují spuštění shellu). Také na rozdíl od .profile , toto je navrženo jako bezpečnostní věc; je speciálně vyroben tak, aby odolal tomu, aby se mu uživatel se zlými úmysly vyhýbal.
(pravděpodobně horší) alternativa by zahrnovala vytvoření nového uživatele pro spuštění konzolové aplikace. Poté byste omezili datové adresáře na tohoto uživatele, nastavili konzolovou aplikaci vlastněnou tímto uživatelem a nastavili u+s na programu. Toto je setuid bit; to znamená, že někdo, kdo spouští program konzoly, tak činí s oprávněními vlastníka programu. Tímto způsobem uživatel sám nemá přístup k adresářům, získá jej pouze prostřednictvím programu. Pravděpodobně byste však měli použít pouze ForceCommand , protože to omezuje vše přístup k „stačí spustit tento program“.
Řešení 2:
Upravit:
V případě, že to není zřejmé, není následující odpověď zamýšlena jako zabezpečená způsob, jak zabránit tomu, aby SFTP používal kdokoli s přístupem k serveru. Je to jen odpověď, která vysvětluje, jak jej zakázat z vnější viditelnosti. Diskusi o zabezpečení na uživatelské úrovni naleznete v odpovědích od @cpast a @Aleksi Torhamo. Pokud se zaměřujete na bezpečnost, tato odpověď není správná. Pokud se zaměřujete na jednoduchou viditelnost služeb, pak je toto vaše odpověď.
Nyní pokračujeme k původní odpovědi:
Zakomentujte podporu sftp v sshd_config (a samozřejmě restartujte sshd ):
#Subsystem sftp /usr/lib/openssh/sftp-server
Řešení 3:
Nepokoušejte se to provést pomocí .profile protože neposkytuje žádné zabezpečení a přesně nic neomezuje!
Nezáleží na tom, co vložíte do .profile , protože to můžete obejít jednoduše zadáním příkazu ke spuštění na příkazovém řádku ssh, jako je tento:ssh [email protected] command . Stále můžete získat normální přístup k shellu provedením ssh -t [email protected] bash .
Zakázání subsystému sftp, jak je uvedeno v jiné odpovědi, vůbec nepomáhá. Subsystémy jsou v podstatě jen aliasy příkazů a stále můžete normálně používat sftp provedením sftp -s /path/to/sftp-executable [email protected] .
Jak řekl cpast a někteří komentátoři, měli byste použít správné mechanismy pro omezení přístupu. Tedy
- Použijte
ForceCommandvsshd_config - Používejte přihlašování bez hesla a
command="..."v.ssh/authorized_keys - Změňte uživatelské prostředí na něco, co omezuje možnosti uživatele
Poznámky:
command="..."platí pouze pro jeden klíč, takže neomezuje přihlášení uživatele ssh pomocí hesla nebo jiného klíče- Mohli byste také omezit přesměrování portů atd. (přesměrování portů, přesměrování x11, přesměrování agentů a přidělování pty jsou ty, o kterých jsem slyšel)
AllowTcpForwardingatd. vsshd_configno-port-forwardingatd. v.ssh/authorized_keys
- Pokud máte spuštěné jiné démony (např. FTP), měli byste ověřit, že nepouštějí uživatele dovnitř (Někteří démoni se rozhodují na základě uživatelského prostředí, takže pokud to změníte, možná budete chtít znovu zkontrolujte toto)
- Můžete změnit uživatelské prostředí na skript, který dělá, co chcete; je buď spuštěn bez argumentů, nebo jako
script -c 'command-the-user-wanted-to-run' - Obě
ForceCommandacommand="..."spustit příkaz přes uživatelský shell, takže nefungují, pokud je uživatelský shell nastaven např./bin/falsenebo/sbin/nologin
Prohlášení:Nejsem v žádném případě odborník na tuto záležitost, takže i když mohu říci, že .profile věc není bezpečná, nemohu slíbit, že s ostatními metodami nedojde k nějakému „problému“, o kterém nevím. Pokud vím, jsou v bezpečí, ale nebyl bych první, kdo se na internetu mýlil.