Jak nahradit FTP pomocí SFTP a zamknout uživatele

Petr Krčmář 22. 2. 2010

Všichni administrátoři vědí, že FTP je zastaralý a nebezpečný protokol. Přesto je to stále standard pro přenos souborů. Důvodem je především neznalost adminů, kteří se bojí, aby se jim po serveru nepotulovali uživatelé a nenahlíželi, kam nemají. Řešení ale existuje, není složité a my vám jej ukážeme.

FTP je snad posledním „starým“ protokolem, který k přenosu dat ani přihlašovacích informací nepoužívá šifrování. Navíc potřebuje ke svému provozu dva TCP porty, což způsobuje další problémy zejména na firewallech. Bohužel i přesto je FTP na mnoha hostingových službách stále standardem. Když řeknete znalejšímu uživateli, aby přenesl na server soubory, automaticky sáhne po FTP klientu.

Jedním z důvodů je i to, že uživatelé mají zmatek v terminologii a administrátoři mají strach pustit lidi přímo na SSH. Obojí je přitom zbytečné, protože pokud se o problematiku jen trochu zajímáte, brzy zjistíte, že tajemství neexistují a rizika jakbysmet. Tento článek vám odhalí obojí.

Anketa

Jak nejčastěji přenášíte soubory na server v internetu?

Terminologie

Stále pozoruji, že v oblasti přenosových protokolů panuje ohromný terminologický zmatek. Uživatelé tak raději zůstávají u osvědčeného FTP, kterému „rozumí“. Pokusím se tedy vysvětlit základní pojmy:

FTP

File Transfer Protocol. Původní a dnes již zastaralý protokol, jehož původní specifikace se objevila už v roce 1971. Nemá žádné zabezpečení, data i přihlašovací údaje procházejí zcela nešifrovaně. Využívá TCP porty 20 a 21.

FTPS

File Transfer Protocol SSL. Stejný protokol, doplněný o SSL vrstvu. V podstatě se jedná o tentýž princip, jaký využívá HTTPS (mnemotechnická pomůcka). Používá se poměrně zřídka.

FTP-over-SSH

FTP hnané skrze SSH tunel. Opět stejný protokol FTP, který je ale přenášen přes SSH tunel, který je sestaven speciálně pro tento účel. Problémem jsou zde dva různé porty a také složitá podpora. SSH klient musí o FTP vědět a celá činnost není příliš automatizovaná. Téměř se nepoužívá.

SCP

Secure Copy Protocol. Poměrně jednoduchý protokol, který dovoluje kopírovat soubory ze serveru a na server. Vše se automaticky přenáší pomocí standardní SSH komunikace. Všechny SSH servery dnes umějí modernější protokol SFTP, takže i když si uživatel myslí že používá SCP (třeba ve WinSCP), používá dnes obvykle SFTP.

SFTP

Secure File Transfer Protocol. Nemá nic společného s FTP, jen to, že se v překladu názvu jedná o „protokol pro přenos souborů“. Je to vlastně rozšíření myšlenky SCP do nového protokolu. Ten na rozdíl od SCP umí podstatně více věcí a dokáže plně spravovat data na serveru včetně práce s právy, adresáři a podobně.

Pro použití SFTP dnes stačí nainstalovat jen balíček OpenSSH. Tak, jako máte přístupnou vzdálenou konzoli, máte k dispozici také přenos souborů přes stejný tunel. Výhody jsou zcela zřejmé: kompletně šifrovaný přenos, jeden standardní port, velké množství klientů, možnost přihlašování pomocí klíčů a další.

Vzhledem k rozšířenosti protokolu SFTP, jeho široké podpoře a bezproblémové implementaci doporučuji právě tento protokol. Je jasné, že překážkou budou někteří uživatelé, kteří prostě nesmyslně odmítají používat jiný program než Total Commander. Bohužel ten protokoly založené na SSH neumí. V Linuxu doporučuji na klientské straně aplikaci gFTP či ještě lépe FileZilla. Na Windows pochopitelně vládne český produkt WinSCP.

Serverová strana

O implementaci na serveru už jsme se letmo zmínili, teď se na ni podíváme podrobně. Většina adminů zná FTP, ale už tolik nevěří SFTP. Důvodem je především to, že mají strach z SSH. Nechtějí dovolit uživatelům spouštět na serveru konzolové příkazy, potřebují jen přenos souborů a nic víc. Tento problém ale má velmi jednoduché řešení, které si podrobně popíšeme.

Jedním z řešení jsou speciální shelly jako scponly nebo rssh. Ty umožňují pouze přenos souborů pomocí SFTP případně SCP nebo rsync. Uživatelé jsou tak omezeni jen na určité úkoly.

Potíž nasazení těchto shellů je ale v tom, že standardně pustí uživatele mimo jeho adresář. S ohledem na práva se tak může teoreticky procházet po celém disku, prohlížet si konfiguraci serveru a podobně. To není vždy žádoucí, zejména na víceuživatelských systémech.

Tento problém se dříve řešil pomocí prostředí chroot, do kterého byl uživatel uzavřen. Problém ale je, že tento postup vyžaduje kopírování systémových souborů do domovského adresáře, udržování verzí knihoven, ruční konfiguraci a má další nevýhody. Problém se navíc zvětšuje, pokud máte na serveru řekněme stovky uživatelů. Existují skripty, které vytvoření chroot prostředí podstatně usnadňují, přesto se toto řešení adminům oprávněně nelíbí.

Existuje ale ještě jedna, velmi elegantní a velmi pohodlná varianta. Ta je k dispozici v OpenSSH od verze 4.8 (z roku 2008, aktuální verze je 5.3). Je pravděpodobné, že ji ve své distribuci najdete. Má dvě podstatné vlastnosti:

  1. umožňuje automatickou tvorbu chrootu dle potřeby
  2. obsahuje integrovaný SFTP server

První jmenovaná vlastnost vám umožní na chroot vlastně úplně zapomenout, protože po její aktivaci jsou uživatelé automaticky uzavíráni ve svých adresářích. Protože je SFTP server integrován přímo do serveru, není třeba kvůli němu spouštět žádný externí program a nemusíte tedy do chrootu kopírovat žádné soubory. Jdeme na praktickou ukázku.

SFTP jako náhrada FTP

Předpokládám, že máte nainstalovaný balíček OpenSSH (openssh-server) verze alespoň 4.8. Do jeho konfiguračního souboru /etc/ssh/sshd_config přidejte následující sekci:

Subsystem   sftp    internal-sftp

Match group sftpusers
    ChrootDirectory     /sftp/%u
    ForceCommand        internal-sftp
    X11Forwarding       no
    AllowTcpForwarding  no

Tím jsme nastavili, že pro komunikaci typu sftp bude využit interní SFTP server. V systému takový příkaz nehledejte, OpenSSH ví, že ho nemá hledat a nabídne rovnou své integrované funkce.

V další části pak říkáme, že uživatele ze skupiny sftpusers (může se samozřejmě jmenovat jakkoliv) uzavřeme v adresáři /sftp a podadresáři, který odpovídá uživatelskému jménu. Pokud chcete využít domovský adresář uživatele, můžete rovnou využít proměnnou %h, která jej obsahuje.

Dále uživateli vnutíme interní SFTP server. I kdyby požádal ručně o jiný shell, stejně mu bude spuštěn tento přednastavený. Není tedy možné ručně spustit například Bash. Nakonec vypneme některé další možnosti, abychom uživatele opět trochu omezili v možnostech.

Následně vytvoříme uživatele pomocí příkazu adduser a přidáme jej do skupiny sftpusers. Jako standardní shell mu nastavíme pro jistotu /bin/false a jako domovský adresář ten, který je v /sftp. Záznam v /etc/passwd  tedy bude vypadat následovně:

uzivatel:x:1000:100:,,,:/sftp/uzivatel:/bin/false

Jsme téměř u konce. Ještě nesmíme zapomenout nastavit adresáři uživatele jako vlastníka roota a zamezit zápis ostatním uživatelům.

# chown root /sftp/uzivatel
# chmod 700 /sftp/uzivatel

Teď ještě restartujeme SSH server a máme hotovo. Pokusíme se k našemu serveru přihlásit třeba z řádky:

$ sftp uzivatel@server
Connecting to server...
uzivatel@server's password:
sftp> ls
soubor.txt
sftp> pwd
Remote working directory: /
sftp> cd ..
sftp> ls
soubor.txt
sftp> pwd
Remote working directory: /

Vidíte, že uživatel je uzavřen ve svém adresáři, který se mu jeví jako nejvyšší. Není možné dostat se o úroveň výše, takže uživatel je uzavřen ve svém vlastním prostoru a nemůže se procházet po zbytku disku.

Jedinou nevýhodou je, že uživatel nemá právo zapisovat do svého adresáře. Bohužel pro postup je nutné, aby adresář vlastnil root a jako jediný do něj mohl zapisovat. Za vším stojí bezpečnost tohoto řešení, protože uživatel schopný zapisovat do chrootovaného / by se mohl poměrně snadno dostat ven, protože si může vytvořit vlastní /etc a stát se rootem.

widgety

Vyřeší to ale jednoduše vytvoření podadresáře(ů) s příslušnými právy. V případě webserveru tak můžeme založit adresář public_html a uživatele v něm nechat pracovat. Můžeme také klidně nechat chroot vytvořit o úroveň výše v /sftp  a uživatele oddělit pomocí práv na jejich domovské adresáře.

SFTP je lepší než FTP

Toto řešení vám umožní velmi jednoduše a plnohodnotně nahradit nebezpečné FTP na jakémkoliv serveru. Z hlediska uživatele jsou možnosti stejné, vše je ale šifrované a tudíž bezpečnější. Z hlediska uživatele ani administrátora nic nebrání v kompletním nahrazení FTP bezpečnějším protokolem pro přenos souborů.

Našli jste v článku chybu?
Vitalia.cz: Voda z Vltavy před a po úpravě na pitnou

Voda z Vltavy před a po úpravě na pitnou

Podnikatel.cz: Rohlik.cz testoval roboty pro rozvážku

Rohlik.cz testoval roboty pro rozvážku

Lupa.cz: Jak udělat formulář, aby ho vyplnil i negramotný?

Jak udělat formulář, aby ho vyplnil i negramotný?

Podnikatel.cz: I vám můžou vykrást značku. Braňte se

I vám můžou vykrást značku. Braňte se

Lupa.cz: Další Češi si nechali vložit do těla čip

Další Češi si nechali vložit do těla čip

Lupa.cz: Jak se prodává firma za miliardu?

Jak se prodává firma za miliardu?

DigiZone.cz: Nova opět stahuje „milionáře“

Nova opět stahuje „milionáře“

DigiZone.cz: Parlamentní listy: kde končí PR...

Parlamentní listy: kde končí PR...

Podnikatel.cz: ČSSZ posílá přehled o důchodovém kontě

ČSSZ posílá přehled o důchodovém kontě

Root.cz: Podívejte se na shořelé Samsung Note 7

Podívejte se na shořelé Samsung Note 7

DigiZone.cz: Budoucnost TV vysílání ve Visegrádu

Budoucnost TV vysílání ve Visegrádu

Vitalia.cz: Antibakteriální mýdla nepomáhají, spíš škodí

Antibakteriální mýdla nepomáhají, spíš škodí

Vitalia.cz: Tradiční čínská medicína a rakovina

Tradiční čínská medicína a rakovina

Lupa.cz: Blíží se konec Wi-Fi sítí bez hesla?

Blíží se konec Wi-Fi sítí bez hesla?

DigiZone.cz: DVB-T2 ověřeno: seznam TV zveřejněn

DVB-T2 ověřeno: seznam TV zveřejněn

Podnikatel.cz: Letáky? Lidi zuří, ale ony stále fungují

Letáky? Lidi zuří, ale ony stále fungují

Lupa.cz: Adblock Plus začal prodávat reklamy

Adblock Plus začal prodávat reklamy

Podnikatel.cz: Tyto pojmy k #EET byste měli znát

Tyto pojmy k #EET byste měli znát

Podnikatel.cz: Udělali jsme velkou chybu, napsal Čupr

Udělali jsme velkou chybu, napsal Čupr

Lupa.cz: Patička e-mailu závazná jako vlastnoruční podpis?

Patička e-mailu závazná jako vlastnoruční podpis?