Názory k článku Protokol SCP mizí: proč je jednoduchý přenos souborů po SSH problém?

Díky za podrobné vysvětlení, ale přiznám se, že ten poslední odstaveček asi úplně nechápu. Našel jsem následující, podobně nejasné vyjádření v release notes OpenSSH:

A near-future release of OpenSSH will switch scp(1) from using the
legacy scp/rcp protocol to using SFTP by default.

Ale co to znamená - patche jsou ve stavu review, ví se, ve které verzi to vyjde? Nebo se ještě dolaďují nějaké implementační detaily nebo interface příkazu?

Asi poměrně brzy, RHEL9 již přepl a hnedle mě uvítala taková drobná změna oproti SCP: https://bugzilla.redhat.com/show_bug.cgi?id=2056884

pro zajimavost, proc kopirujes pres scp lokalni soubor do lokalniho souboru? a navic ve stejne ceste? :-)

tohle člověk většinou nedělá vědomě, ale řada nástrojů, které se starají o synchronizaci pro určité testy a varianty umožňují zacílit i na lokální endpoint a strčí tam třeba localhost, implementaci nechají stejnou a neřeší, že to je malá domů.

Nějakou dobu to tak dělal i ansible v synchronize modulu, kdy jsem mu podstrčil přes with_items: groops['all'] a ručně nevyloučil aktuální stroj, pak to také kopíroval do zdrojové složky.

Za mě je dost nešťastné chování, kdy to data smaže, místo aby to aspoň napsalo nějakou chybu, je to hlavně rozdíl proti předchozímu chování, ať už to bylo jakkoliv divné. To je i to o čem Petr, scp nemá RFC a není dokumentované.

Mně se občas stává, že omylem napíšu "scp file.txt host" (bez dvojtečky) a pak mám po filesystému náhodně zkopírované soubory co se jmenují jako hostname. Je nějaký důvod proč se scp bez dvojtečky chová jako cp, nemohlo by třeba vyhlásit chybu?

To, že se "chybný" vstup projeví nepříjemným výsledkem, není chyba aplikace.
Obdobné chování jako cp má scp už v názvu a je imho očekávatelné.

> To, že se "chybný" vstup projeví nepříjemným výsledkem, není chyba aplikace.

Je, protože uživatelé dělají chyby. Ale uznávám že to tady není nějak extra závažné. crontab -e vs. crontab -r (ještě k tomu jsou ta písmenka na normálních klávesnicích hned vedle sebe) je horší :)

#!/bin/bash
isOK=false
for i in "$@"; do
    if [[ "$i" == *":"* ]]; then
        isOK=true
        break
    fi
done
if [[ $isOK == "true" ]]; then
    scp "$@"
else
    echo "CHYBA: Ziadny parameter neobsahuje dvojbodku"
fi

10. 3. 2022, 08:18 editováno autorem komentáře

To je sice dobré řešení pro lokální stroj, ale už to bohužel neškáluje s jinými "náhodnými" stroji, se kterými pracuješ a potenciálně na nich to scp můžeš spustit.

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.

U rsync je fajn že umí kompresi při přenosu a přenášet jen změny.
SFTP jsem používal pro vzdálené web servery. Na Windows je super klient na SFTP i FTPS winSCP. Chovalo se to tak že to udržovalo spojení a zbytečně se to beodpjovalo i na FTP na rozdíl třeba od FileZilla klienta.

A jak je na tom FTPS? Připadá mi že by byly fajn testy a zároveň vím že záleží i na implementaci a konfiguraci..
Nevím jaký protokol používá třeba synthing?
Máme možnosti SSHFS, NFS..
:-)
Ale někdy je FTP(S) jediná možnost (starší routery s uzavřeným FW).

Pokud se FileZilla odpojuje (respektive se odpojuje server), tak je v nastavení volba, která to aktivně řeší (tuším posílá pravidelně NOOP).

ja dost casto pouzivam konstrukci
tar czvplO . | ssh nekdo@nekde '(cd /kam_to_chci && tar xzpf - )'
Casto to pouzivam na klonovani celeho disku.
Nektere parametry jsou mozna obsoletni a vim, ze na prepnuti do adresare pred rozbalovanim existuje nejaka option, ale tu si nepamatuju :-)

asi mas rozbitej "man", toz z meho "man tar" ;-)

-C, --directory=DIR
  Change to DIR before performing any operations.
  This option is order-sensitive, i.e. it affects all options that follow.

Chtěl bych se zeptat na mírně související věc, nerozbilo se vám nedávno u scp bash-completion? Když napíšu "scp host:f<TAB>" tak se "f" expanduje třeba na "file.txt" (což je dobře) ale zmizí to "host:", takže mi v terminálu zůstane "scp file.txt" což je samozřejmě blbost.

V článku jsou popisovány nevýhody, ovšem např. při přenosu souborů mezi dvěma VMWare systémy (typicky přenos virtuálního stroje) jsou výhody, řekněme, přímo zdrcující - jde o přímý přenos dat disk-disk, bez jakékoliv WebDAV režie, proces běží na pozadí a přenese celou složku. Utilita scp je v prostředí VMWare běžně dostupná, takže stačí jen klient putty. Rychlost přenosu je kolem 50 MB/s. Nevadí přitom, že na obou stranách jsou různé verze VMWare.

Není to přímý přenos disk-disk, pořád se to musí šifrovat a na druhém konci dešifrovat.

Ano, jediná nevýhoda, zvyšující režii přenosu. Ale výhody jasně převažují, hlavně jednoduchost. A otázka bezpečnosti je, při přenosu v lokální síti, nepodstatná.

Nešlo mi vůbec o bezpečnost. Šlo mi o to, že protokoly FTPS, WebDAV nebo čisté HTTPS, prostě cpou data co to dá do TLS tunelu vytvořeného uvnitř TCP/IP spojení, takže jediná reálná režie je to šifrování. U spousty malých souborů pak režii ještě můžou zvyšovat informace posílané s jednotlivými soubory – HTTP (a WebDAV) má takřka neomezené možnosti toho, co vše můžete do hlaviček nacpat, takže s jedním souborem můžete navíc poslat pár bajtů, ale i mnohem víc. Na druhou stranu, u scp se zase kvůli malým paketům pošle mnohem víc TCP/IP hlaviček.

scp, které běží přes SSH, je naproti tomu svázané řízením toku SSH, které je optimalizované pro interaktivní práci. Na síti s nízkou latencí to nepoznáte a scp bude stejně rychlé, jako FTPS, WebDAV/HTTP či rsync, na síti s velkou latencí (nebo dokonce s asymetrickou rychlostí) už bude o dost pomalejší, protože se musí čekat na potvrzovací pakety.

Díky za skvělý článek, a pěkná vysvětlení. Po pravdě řečeno, já už 10 let ve scriptech používám jen rsync (když to jde ven tak over ssh) a má to spoustu dalších výhod, protože rsync umí víc věcí, než scp a syntax má stejně jednoduchou.

Pro mě za mě, ať se packety třeba posílají Českou Poštou, ale ať příkaz "scp" funguje tak, jak fungoval posledních 30 let...

Posledních 5 let je tolik novinek že než si prsty naučí na jednu věc už zase mám problém s jinou...

Achjo. :)