Vlákno názorů k článku Protokol SCP mizí: proč je jednoduchý přenos souborů po SSH problém? od Radek Zajíc - I SFTP a rsync maji sve vlastni problemy,...

I SFTP a rsync maji sve vlastni problemy, viditelne v nekterych pripadech pouziti mimo LAN.

RSYNC protokol (tzn. rsync bez vyuziti SSH pro prenos dat) prenasi soubory nesifrovane; na lokalni siti to asi tolik nevadi, ale v Internetu uz to byva problem. Lze ho samozrejme obalit stunnelem, ale pak se ztrati nektere vyhody, napr. server misto IP adresy klienta vidi IP adresu stunnelu, nejcasteji localhost.

rsync over SSH zase ma klasicke nevyhody vzdaleneho pristupu po ssh - pro automatizovane prenosy musim resit specialni uzivatele v systemu, zajistovat, ze si uzivatele nebudou moci spustit cokoli chteji a pristupovat kam nesmeji, nemuzu zkontrolovat pokusy o MITM beznou kontrolou porovnanim server name z (platneho) serveroveho certifikatu s hostnamem, na ktery se pripojuju...

SFTP protokol ma naprosto tragicke rizeni rychlosti pri pouziti pres WAN linky a k tomu pomaly nabeh rychlosti. Rozdil je klidne i o dva rady oproti rsync (utilita) over RSYNC (protokol), v nasich testech napr. 600 kB/s vs. 60 MB/s. rsync utilita umi nastavit vetsi socketove buffery a tim tenhle problem castecne odstinit, utilita sftp ne.

Zrovna v techto dnech a tydnech resime problem prenosu souboru po Internetu "automatizovane, rychle, bezpecne a bezproblemove", a po prozkoumani moznych variant jsme skoncili u protokolu S3 (ma navic sirokou podporu v podobe existence knihoven pro mnoho programovacich jazyku, takze neni pri automatizaci potreba volat externi utilitu) a server-side softwaru MinIO v jednoserverovem rezimu.

Souhlas, je to přesně tak jak říkáte. Taky pokud to jde, tak používám nativní rsync protokol, i třeba přes tunel nebo site-to-site VPN.
Stejně tak s tím sftp, některé GUI klienty dokonce z tohoto důvodu mají možnost použít kombinace sftp a scp (pro samotné datové přenosy) kvůli rychlosti, někdy ten rozdíl opravdu může být velmi výrazný.
Bylo by skvělé, pokud by se před chystanou náhradou scp za sftp zaměřili i na tuhle oblast.

Obrovská výhoda sftp (resp. staršího scp) je v tom, že to je přítomné fakt v téměř jakémkoliv systému včetně macOSu i posledních Windows a s víceméně dobrou kompatibilitou napříč nejobvyklejšími implementacemi (OpenSSH, Dropbear, PuTTY, libssh2), takže je to velmi vhodné na jakékoliv ad-hoc vzdálené kopírování.
FTPS zmíněný v jiném příspěvku pro mě byl vždycky spíš problematický, vždycky mi to přišlo jako takový hybrid s veškerou komplexitou starého FTP a SSL. Často to neprochází přes NAT a firewally, které nemůžu žádným způsobem ovlivnit. Nezřídka se tam musí manuálně přidávat výjimky na neplatné serverové certifikáty atp.

SFTP je na delších trasách ukrutně pomalé, navíc je to rovnák na ohýbák. Ono by bylo nelepší, kdyby existoval nějaký protokol FTP(S)v2 podle moderních standardů, tj. pouze jedno spojení a nikoli dvě. Jenže k tomu bohužel asi už nikdy nedojde.

Čím je způsobena pomalost SFTP a proč by to jiný jednoduchý protokol neměl? Já si představoval, že se tohle všechno implementuje tak, že se otevře TCP spojení a do něj se zapisují data maximální rychlostí; zahlcení si řeší OS, a když k němu dojde, tak se write na socketu zablokuje.

Popisoval jsem to v článku High Performance SSH/SCP: rychlé přenosy souborů bezpečným kanálem. Ve zkratce: potíž je v tom, že SSH implementuje vlastní řízení toku (flow control) na aplikační úrovni. Zřejmě kvůli interaktivitě má nastavené malé buffery, které nemění dynamicky svou velikost podle linky.

Proto čím delší a rychlejší linka, tím narůstá režie do obrovských rozměrů, protože se víc času spotřebuje čekáním na potvrzení než přenášením samotným. Řešením je instalace patchů HPN-SSH, které ale bohužel nejsou součástí OpenSSH.

Na pouhý přenos souborů mi protokol S3 připadá zbytečně komplikovaný – zvažovali jste WebDAV? Je to také postavené nad HTTP a je to zamýšlené přímo jako konkurence protokolů FTP, SCP nebo SFTP. Tj. na rozdíl od S3 to zná koncept adresáře, umí to soubory přesouvat, měnit metadata, volitelně je tam i zamykání souborů. Můžete tam použít kterýkoli ze způsobů autentizace podporovaných HTTP (což je jednodušší, než autentizace v S3). Základní podpora WebDAVu je snad v každém HTTP serveru.

Mně u rsyncu vadí, že "kopíruj adresář" a "kopíruj vnitřek adresáře přímo do destinace" je odlišeno blbým lomítkem u prvního argumentu (které tam navíc podle situace doplní či nedoplní expanze shellu). Pravidelně takhle někam prsknu soubory i když jsem je chtěl zkopírovat i s adresářem.

Ty ostatní věci co píšeš jsou ale také validní - zejména to omezení "hej chci povolit jen kopírovat soubory do tohoto adresáře (klasický filesharing) a ne spouštět příkazy/sestavovat SSH tunely(!)" je celkem pain nastavit. Nedivím se, že to pořád občas lidi řeší instalací FTP serveru jako kdyby byl rok 1980.