Názory k článku High Performance SSH/SCP: rychlé přenosy souborů bezpečným kanálem
-
Mio (neregistrovaný)
„Přenos souborů po síti je starý ... léta se k tomu používal výhradně protokol FTP ... Co ale použít místo něj? Aby to bylo bezpečné, šifrované, široce podporované a všude dostupné. ... Nabízí se SSH, které splňuje všechny tyto podmínky ...“
„... Autoři uvádějí výsledky svých měření, při kterých se s klasickým OpenSSH dostali jen na 0,69 MB/s, zatímco HPN-SSH dosáhlo na 37 MB/s a s vypnutým šifrováním přenášených dat dokonce na 52 MB/s. ...“
„... HPN-SSH je distribuován ve formě velkého patche, který musíte aplikovat na zdrojové kódy ...“
„... vývojářům OpenSSH nejde tolik o výkon, takže se takto složitým a velkým patchem jednoduše nechtějí zabývat ...“Mám to chápat tak, že když se zde píše o „Uživatelé chtějí používat bezpečný a dobře podporovaný kanál pro přenos souborů.“, tak je tím myšlen GNU/LInuxový odborník s mnoha-letou praxí, ne Linuxový začátečník a už vůbec ne BFU?
-
No já na ftp kdysi používal sftp s komerčním certifikátem a v rychlosti nikdy nebyl problém. už v roce 2010 a myslím že i v roce 2001 to existovalo ve windovs u nepřekonané serverové aplikace od gene6.
Letmým pohledem na "gene6" bych si s dovolením dovolil tvrdit, že si pletete protokoly SFTP a FTPS. To co jste používal by, bylo to druhé, neboli FTP s SSL. Kdežto SFTP je protokol právě nad SSH.
-
NN (neregistrovaný)
To vypada, ze stunnel je na tom lepe. Kdo taha velke objemy po SSH?
-
. . (neregistrovaný)
kvůli požadavkům na zabezpečení často zůstává jako jediná možnost sftp. V korporátech se integrace mezi databázemi dělají běžně přes text files (aka csv), které se přenášejí právě přes sftp. Bohužel.
Další velká věc je ssh forward, u cloudu často samotné servery nemají přístup na internet, distribuce aplikací a balíčků se opět často dělá přes ssh, proč, protože jednotná bezpečnostní vrstva, možnost to opřít od ldap, časově omezený přístup atd. atd.
Osobně neznám plnohodnotnou náhradu.
-
. . (neregistrovaný)
kde to je průchodné, ipsec je jasná volba, všechny ty korporátní nesmysly to podporují velice dobře. Horší to je s FW, je často na to potřeba vlastní razítko a pokud přenos není v jedné síti, je dost problém hledat, na kterým uzlu to umřelo.
V praxi bývá i problém s ochotou takovou věci nastavovat, nikomu se do toho nechce, blbě se jim to udržuje a dělají interní admini jen problémy, to se bavím třeba o bankách, které jsou dost vlastní iniciativou nesmyslně svázány.
-
. . (neregistrovaný)
onehdá jsem to testoval na čerstvě vydaném freebsd 11.0 s openssh 7.2 (možná 7.3), s aes256-gcm jsem byl na přibližně polovině (7 Gb/s) oproti netcatu (15 Gb/s). Co je zajímavé, aes gcm jede na aes-ni je to opravdu hodně rychlé, brzda je mac, i umac-64 je dost pomalý, pokud se v openssl vypne úplně, hpn se dostává k rychlostem netcatu.
Konkrétní čísla už nemám, berte to jako poznámky z hlavy :)
Spíš to porovnávej s čistým netcatem, zabalovat tcp do tcp s sebou nese další konsekvence a můžeš si zbytečně rozbít měření. U openSSH není špatné povypínat všechny ciphery a macy a můžeš referenčně porovnat s nc, rychlostně by to mělo být plus mínus pár procentních bodů, tím dokážeš ověřit jaký vliv má hpn.
-
Lolek (neregistrovaný)
1Gbps sa da saturovat, problemom je, ak je latencia vyssia. Kazda ms naviac znizuje rychlost prenosu. 1Gbps server s latenciou >50ms mi uz nedokazal ist viac ako 100Mbps....pricom pri priamom spojeni na lokalnej sieti s latenciou <1ms to ide cca 900Mbps. Je to len moje pozorovanie. Mozno robim nieco zle....rsync ide ale podstatne rychlejsie.
-
> a kolik dat se vejde do bufferu proxy?
Podle toho, co by kdo použil, jak by si to nastavil atd. Možná by se takováto jednoduchá proxyna dala vyrobit i z nc, ale netuším moc, jak se tento nástroj chová.
> Pokud se vše nepovede doručit na první dobrou, kdo se bude starat o retrans?
Ta proxy, aspoň na úrovni TCP. Pokud ale například umře spojení, je nutné udělat novou session, s tím proxyna už nic nenadělá.
-
. . (neregistrovaný)
mně připadá, že to je škrábání se špatnou nohou za špatným uchem.
To raději to ssh co nejdříve ukončit a na dané "proxy" si mountnout FS vhodnějším protokolem, což mimochodem se také často dělá.
Z těhle obcházení limitů vznikají hodně zákeřné problémy a je lepší ty technologie používat tak, jak jsou testované.
-
Uznávám, že je to ohack, ale proxyna na této vrstvě nemá jiné možnosti než útočník. Ten taky může poslat falešný ACK po TCP a mělo by to způsobit přinejhorším DoS. Stejnětak tento hack.
Jinak řečeno, budou-li problémy s tímto hackem, máme něco špatně zabezpečeno.
Co se týče použití jiného protokolu, je to samozřejmě taky cesta, otázkou ale zůstává, který protokol použít, abychom dostali odpovídající zabezpečení, stejnou funkcionalitu a podporu na druhé straně. To záleží na situaci.
-
. . (neregistrovaný)
tenhle hack může zlobit tehdy, když síť má příliš vysoké latence nebo se vnější vinou sníží propustnost, proxy nebude mít neomezený buffer a jednou jí dojde, client bude mít falešné informace o tom co je již posláno a může dojít ke ztrátě dat, v zajištění integrity bych viděl velký problém. Pokud mi někdo posílá falešná ACK, neměl bych to řešit na téhle úrovni, ale o trochu níže.
nfsv4 se používá se kerberosem, iscsi s ipsecem, pokud data tečou přímo na pásky, je tady několik nativní rozšíření pro iscsi (v praxi jsem potkal t10 s ibm storage system).
Podpora na druhé straně je problém, pokdu se jedná o nějaký enterprise storage system, moc na výběr často není, vždy je možnost to protlouct hrubou silou a multiplikovat ssh spojení tak abych měl odpovídající průtok. Rozhodně bych se ale nepouštět do tebou navrhnovaného hacku, raději bych zajistit integrační server, který na jedné straně bude mít blízké ssh klienty a na druhé nějaký vhodnější protokol, viz odstavec hore.
-
Opakuju, pokud falešné ACKy mohou způsobit problém jako ztrátu integrity, je to zranitelnost, protože totéž může udělat útočník na síti. Neznám všechny detaily SSH, ale není to úplně noname záležitost, a předpokládám, že se TCP ACK bere jen jako taková první aproximace. Tzn. pokud ACK dorazí, víme, že data nemusíme posílat znovu, ale nevíme, co vlastně dorazilo druhé straně.
Spoléhání se na ACK mimochodem není dobré ani pokud síti věřím. Pokud na druhé straně třeba spadne aplikace, dojde místo nebo něco podobného, ACK nejspíš dorazí, ale data se nezpracují, jak bych chtěl. Takže stejně nemohu na aplikační vrstvě rozhodnout o provedení akce jen podle ACKu, ale potřebuju i něco jako ACK na aplikační vrstvě. Tedy na vyšší vrstvě, ne na nižší.
Ad co se stane, když se proxyně zaplní buffer: Pak by měla přestat posílat další ACKy zpátky.
-
Filip JirsákStříbrný podporovatelZpůsob ověření serveru je ale není věc protokolu, pouze otázka implementace – i v HTTPS klidně můžete důvěřovat jenom jednomu konkrétnímu certifikátu. Stejně tak i v HTTPS může server ověřovat klienta, několika různými způsoby, stejně jako u SSH – jménem a heslem, výzvou a odpovědí, certifikátem nebo nestandardními prostředky třeba přes Kerberos.
-
Používat SSL tak, že ověřím pouze, že certifikát podepsala nějaká veřejná CA. V lepším případě, že sedí doménové jméno, to je docela hloupé použití na cokoliv jiného než na veřejné služby. To (předem domluvená) výměna souborů mezi dvěma firmami typicky není. A už vůbec to není případ kopírování souborů uvnitř firmy. Takže ano, pokud neumíš použít správně HTTPS nebo jiné SSL spojení, tak je SSH lepší. Ale ve skutečnosti je SSH jen o malý chlup lepší, protože málokdo kontroluje, že host key je správný při prvním připojení. Dokonce naopak vidím často vypnutou striktní kontrolu host key, kvůli občasné reinstalaci serverů. Takže vás SSH v běžném použití prakticky nechrání před přihlášením se na podvržený počítač. To už to SSL alespoň teoreticky zkontroluje, že se připojujete k serveru majitele domény.
Pokud se pak přihlašujete jménem a heslem, (protože třeba hloupě napojený LDAP), tak jste právě jméno a heslo vyzradil útočníkovi. Pokud se přihlašujete soukromým klíčem tak jste na tom trochu lépe, útočník neudělá MITM, ale to v SSL teoreticky také neudělá (i když z jiného důvodu).
Podle mne je správná cesta určit jakou úroveň zabezpečení požadujete a podle toho vybrat CA kterým budete důvěřovat. Udělat si vlastní CA, která bude ověřovat interní služby je jednoduché a je to v SSL velmi vhodné. A dokonce to lze udělat i v SSH, čímž může odpadnout otravné ověřování host_keys!
-
Filip JirsákStříbrný podporovatel
Na začátku byla řeč o standardizaci nového protokolu. Pro nový protokol by bylo nutné psát nové klienty, takže můžeme předpokládat nové klienty nebo upravení těch stávajících i u WebDAVu. Přihlášení klientským certifikátem je podle mne běžnou vlastností WebDAV klientů, ten seznam důvěryhodných certifikátů nezávislý na systému bude větší problém. Ale problém je v klientských WebDAV aplikacích, nikoli v HTTP knihovnách, ty to podporují běžně. Průchodnost všude platí, síťové prvky nijak nezjistí, jakým způsobem klient ověřuje serverový certifikát. Že je vyžadováno přihlášení klientským certifikátem může proxy zjistit, ale nikdy jsem neslyšel o tom, že by to nějaká blokovala (jedině pokud dělá MitM). Pořád bude HTTPS průchozí mnohem častěji, než SSH.
-
RUM (neregistrovaný)
Dik za clanek. S timhle taky neustale bojujeme. Linky predimenzovane ale pri desitkach hopu, pres ktere to jde to na konci jenom ukapava. Pozitivni je ze je tady perspektiva to nasadit jen na jednom konci, protoze u klienta odkud ty data musime dolovat jakakoliv zmena neprojde urcite. Ted mi zbyva vyresit tu krucialni otazku. Projde to alespon pres nase IT oddeleni? :D
