Názory k článku
Jak zrychlit ssh

ale copak, že by ipv6 nakonec nebylo tak dokonalý jak se místní honiči snaží pořád tvrdit? ;)

IPv6 ma kvoli dlhsim adresam o trochu vacsi overhead (pomer hlavicky paketu k celkovemu mnozstvu prenasanych data), takze prenos bude urcite o nieco pomalsi ako IPv4. Prejavit sa to moze specialne pri aplikaciach ako SSH, kde sa kvoli interaktivite prenasaju relativne kratke pakety.
Takisto implementacia IPv6 stacku nemusi byt az tak optimalizovana, ako pri IPv4 stacku, kde sa vyvoju venoval dlhsi cas. Pri IPv6 je castokrat skor prioritou "aby to aspon fungovalo" a na performance optimalizaciu uz neostava cas a peniaze.
Z praktickeho hladiska bude ale, hlavne pri interaktivnom pouziti ssh (teda nie scp, sftp alebo sshfs), rozdiel minimalny.

Z praktickyho hlediska se mi jeste nestalo, ze by pri tahani souboru byla omezujici sit, vzdycky byl bottleneck CPU.

A efektivita CPU pri sietovych operaciach zavisi aj od toho, ako efektivne je implementovany IP stack.

mne ipv6 pride stale rychlejsi, kvoli znizenej rezii na NAToch a routovacich tabulkach :)

IPv4 je rychlejsi, protoze HW je na ni optimalizovan. Vsechno od TCP/UDP checksumu az po to, aby TCP ramce jednoho spojeni skoncili v L2 cache stejneho jadra, bude mnohem casteji implementovano pro IPv4 a jeste jsem nevidel HW, ktery by to umel pro IPv6 a pro IPv4 ne. Tvrdit, ze budou funguvat stejne rychle, je celkem zavadejici.

a dokážeš ten rozdíl vyčíslit?

Zalezi na zatezi, na in-house HW/SW mame pri ocekavane zatezi o ~20% vetsi propustnost pokud se dorucuji ramce jednoho TCP spojeni na jedno jadro a ve spravnem poradi oproti tomu, pokud se to nedela. Samozrejme rozdil temer zmizi, pokud je tolik spojeni, ze se navzajem vystrkaji z cache.

Pokud se dela routovani/QOS/ba­lancing v HW na L7, tak je to radove uplne jinde, nez pokud se na ramec musi divat SW, protoze rozhodujici data byla v ramci moc daleko na to, aby se HW mohl rozhodnout, co udelat.

@tom

"Vsechno od TCP/UDP checksumu az po to, aby TCP ramce jednoho spojeni skoncili v L2 cache stejneho jadra"
TPC/UDP jsou ale úplně jiné vrstvy. Co má společného poćítaní checksumTCP/UDP s nižší IP vrstvou?

"Tvrdit, ze budou funguvat stejne rychle, je celkem zavadejici."
A to si jenom myslíš, nebo jsi to měřil?

IPv6 má sice delší hlavičku, ale zato pevné velikosti, což usnadňuje zpracování.

" Co má společného poćítaní checksumTCP/UDP s nižší IP vrstvou?"

Pokud checksum pocita HW, tak chodne, protoze pokud HW nizsi vrstve nerozumi, tak ho nespocita.

Ono to může být klidně tím, že na IPv4 jsou reverzní záznamy nastavené, na IPv6 ne. Potom nezdržuje IPv6, ale DNS, i když připojení přes IPv4 je okamžité, ale přes IPv6 si člověk počká. Když nebudete mít nastavené reverzní záznamy u IPv4, ale u IPv6 ano, situace se obrátí.

Tunely jsou taky kapitola sama pro sebe. Pokud potřebuju někam často rychlé spojení, ale k dispozici je pouze připojení přes HE, dělám si raději sit tunel - nemusím tlačit data přes půl světa. Tohle ale není problém IPv6, ale neschopného ISP.

Velmi často používám na IPv6 ipsec. U ipsec nebývá spojení k dispozici neustále, při prvním spojení se může provoz občas trochu zdržet. Na IPv4 by se dalo šifrování mezi dvěma IP zapnout taky, ale jednu stranu obvykle není možné nikam napojit (NAT). Tady už by bylo srovnání rychlosti IPv4 a IPv6 vyloženě nefér, protože na IPv4 ipsec asi nikdo nepoužívá.

Tj, to je zase blabol ... bych chtel videt toho uzivatele, kterej pozna ze ma sshcko o 10, 20 nebo 30ms pomalejsi odezvu, protoze to je tak jediny, v cem muze bejt rozdil.

Jeste vetsi blabol je to s tema klicema ... protoze jak heslo tak klic se pouzije jen jednou - pri zahajeni session. Nehlede na to, ze v odkazovanym clanku je uplne neco jinyho nez v newsce, je tam ze se ma sshcku RICT jakej zpusob autentizace se pouzije (protoze jinak se bude dohadovat = cekat) coz opet povede tak maximalne k par ms pri loginu. Rozhodne tam NENI ze pouziti klice je rychlejsi, protoze ani byt nemuze.

Nejde o to ci to pozna interaktivny uzivatel. Skus si urobit 30 spojeni na 60 serverov cez nejaky automatizacny framework, ktory ssh vyuziva (povedzme ansible, atd) a ten rozdiel bude viac ako podstatny. V pripade CI, ked musis otestovat kvantum moznosti deploymentu na kvantum masinach, tak to dava zmysel optimalizovat. To iste plati pre dohadovanie sa o autentizacii.

Jo, a asi tak o 2 rady efektivnejsi bude drzet pripojeni na to kvantum masin otevreny ...

Resit tohle je asi tak stejny, jako kdyz budes resit, jestli by ta lopata nemela bejt o cm sirsi, nebo o cm uzsi ... a jak afektivne s ni vykopes tu diru, kdyz soused ma bagr.

ked robis paralelne ssh na 1000 masin, tak sa ti prave tento zisk rychlosti rozdeli na 1/1000 realneho zisku :) ale ano ak sa pouziva centralny jump a proxy cez neho, tak control master dokaze zrychlit toto pripajanie.

v tom případě ale nebudu číst návody na tecmint.com a naslepo něco upravovat, ale půjdu na jistotu a budu hledat bottleneck, teda já bych to tak udělal, lidé jsou ale asi různí.

ono uplne staci mit UseDNS yes a pak pri spatne (ne)nastavenych PTR trva i nekolik desitek sekund nez se otevre spojeni
a to uz je sakra znat, jestli se spojeni otevre za 0,5 s nebo za 20s

Mě by spíš zajímalo, kdy vrátí možnost nastavení úrovně ssh komprese tak, jak to bylo u ssh1.
Pro úroveň 1-2 by to přineslo znatelné zrychlení přenosu dat oproti současné pevné volbě 6.
Odebrání šifrování arcfour, které jsem používal pro místní zálohování, rychlosti taky napřidalo.
Taky by mne zajímalo, jestli už je defaultně integrovaný HPN-SSH patch.
V odkazovaném článku byla volba UseDNS no dříve defaultní a po změně na "yes" si řada uživatelů začala stěžovat na pomalé připojení, snad to zase vrátí zpět.

arcfour jsem pouzival taky, po tom, co ji odebrali, jsem ji nahradil blowfish-cbc.

chacha20-poly1305

Meh. Je možný, že tvůj use case to rozbíjí, ale uvědom si, že podporování takovýho bordelu jako je RC4 znamená zhoršení auditovatelnosti kriticky důležitýho SW pro všechny. Nehledě na to, že v SW, který má být bezpečný nemá slabá šifra z principu co dělat.
Slabý šifry mají zmizet do propadliště dějin a ty si trhni nohou.
https://xkcd.com/1172/

Můžu se zeptat v čem konkrétně v rozumně navrženém softu zhorší auditovatelnost podpora další (byť slabé) stream šifry? Napadají mě dvě místa:
- Implementace samotné šifry - těch (doslova) pár desítek řádek nepředstavuje nějak velký problém, zejména když to porovnám s korektní implementací eliptickych křivek.
- Kontrola inicializace, že dokud se nevyskytne v configu parametr typu "IReallyKnowWha­tImDoing", tak se rc4 nedostane do tabulky/sezna­mu/kýhovýra podporovaných šifer taky není zase taková překážka.

O tom že v ideálním světě kde jsou všechna zařízení pod supportem, výrobce jim dodává bezpečnostní aktualizace po celou dobu životnosti HW atd. je třeba slabé šifry vyházet co nejrychleji žádná. Ale třeba zdravotnické nebo průmyslové přístroje, nověji třeba IoT nám dokazují že v ideálním světě rozhodně nejsme a občas je nějaký ústupek potřeba.

V průmyslu, či zdravotnictví to SSH neměl co updatovat. Tam se na nic nemá šahat dokud neověřím, že to funguje. Krom toho existují virtuální počítače... Druhá možnost je, že ten, kdo chce mít možnost komunikovat se zařízením po dávno prolomené šifře, nechť má možnost používat SW zbuildovaný proti nějakému openssl-old. (takový SW nechť je jasně označen a umístěn tak, aby si ho nikdo nestáhl omylem, a rozhodně se nesmí nikde instalovat defaultně) Zbytek světa nechť jede na openssl-safe, což bude milá knihovna, která se bude vyznačovat jediným rozdílem oproti openssl-old. A to tím rozdílem, že bude mít o PÁR SET TISÍC řádků kódu
méně. (!!!)

Auditovatelnost OpenSSL se zvýší tím, že naprostou většinu kódu (90%) sioučasného OpenSSL označíme jako "NEAUDITOVAT", protože už není relevantní, přesuneme ho někam daleko od normálního kódu Openssl-safe, a bude od něj pokoj. Tím pádem každý další audit všechen ten nezajímavý kód bude moct přeskočit, což se teď neděje.

OpenSSL má půl milionu řádků kódu, z toho na zpracování TLS se podílí 70000. Amazonu na základní podporu TLS stačilo 6000 řádků kódu, a je otázka, zda vadí, že něco z TLS případně nepodporují.

https://www.theregister.co.uk/2015/07/01/amazon_s2n_tls_library/

Teď jsem si uvědomil, že jsem vlastně neodpověděl na vaši otázku. Podle mě by IT svět měl být nastavený tak, že v kryptografii se staré věci z principu nepodporují. Tím bychom řekli, že OpenSSL, či její náhrada nemusejí umět všechno, ale stačí, aby uměly jen to, co je state-of-the-art. Což jednak vytvoří příležitost většinu openssl zahodit (protože se tím najednou bude dát něco získat), a druhak případně vytvoří možnost ji nahradit něčím jiným, protože i v openssh to bude znamenat mnojhem menší úpravy

Mně by spíš zajímalo, jestli se dá nějak zrychlit přenos dat pomocí SFTP. Protože z mojí zkušenosti je SFTP na libovolné lince vždy zhruba o polovinu pomalejší než FTP(S).

Zeby to bylo trebas tim, ze ftp je primarne urceny k prenaseni souboru, ktezto sftp je spis takova z nouze cnost na tema "taky to de"? Ostatne, kdyz zacnes tlacit soubory pres RDP, dopadnes jeste o poznani hur.

Možno ešte skúsiť mosh

pouzivam jenom mosh

nám neprošel v bankách security oddělením.

Jen bacha, mosh na přenášení velkých souborů také není, umí ztrácet data na nekvalitní lince, musí se konzistence kontrolovat jinak.

To je zpravicka jak stehno.

plny souhlas .. odkaz na Lame clane plny blbosti a nepouztelnych veci