Na serveru Tecmit vyšel krátký článek, jak zrychlit ssh spojení. První možností je zkusit používat IPv4 místo IPv6, které bývá někdy pomalejší. Jednoduše toho dosáhnete přepínačem -4.
Druhou možností je zrušit používání DNS na straně serveru, čemuž odpovídá volba UseDNS no. Pokud se připojujete k jednomu stroji vícekrát, může pomoci automaticky využívat jen jedno spojení. A posledním tipem je používání klíčů místo hesel, připojení je nejen bezpečnější, ale i rychlejší.
Záleží na tom, jak je v síti šestka zavedená. Pokud je tam nějaký tunel, může mít konektivita přes něj jiné vlastnosti než ta nativní. Ale to platí o jakémkoliv tunelování, u VPN to bude stejné.
Ale v běžném provozu není důvod, aby byl přenos pomocí jednoho protokolu rychlejší než pomocí jiného. Dnes je klidně možné čtyřku tunelovat čistě šestkovou sítí a taky to funguje stejně rychle.
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.
To je nesmysl. SSH v2 kompresi normálně podporuje. U SSH v1 se dá ještě ovládat "CompressionLevel", ale to neznamená, že u SSH v2 žádná není.
Viz man ssh:
-C
Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11, TCP and UNIX -domain connections). The compression algorithm is the same used by gzip(1), and the “level” can be controlled by the CompressionLevel option for protocol version 1. Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. The default value can be set on a host-by-host basis in the configuration files; see the Compression option.
(o tom, že by SSH v2 nepodporovala kompresi tam nic není)
a viz třeba tady:
https://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_05.htm#ch03-57773.html
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.
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/balancing 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.
měřil jsem rozdíl u infinibandu (od Mellanoxu) u IPoIB rozhranní a tam je u 56 Gb/s linky mezi servery ve stejném racku a rozdíl byl do 3 % ve prospěch ipv4. Redhat 7.3.
Poté mohu mluvit o reálném nasazení u několika klientů v ČR u interní sítě (desítky tisíc stanic) a tam ipv6 poskytuje lepší výkon, má průměrně o 1/3 méně hopů a ušetřilo se hodně díky absence NATu, opět ale rozdíl do 10 %.
Generické testy mi poskytuje v laboratorních podmínkách hodně podobné výsledky, většinou na 8000 Ciscách.
Mít naopak internet na ipv6 je i na velké služby často o dost pomalejší, Facebook a další velké obsahovky nemají asi dobré trasy pro ipv6, nevím, nejsem na takové síti.
Zkousel sem nekoli ruznych tras po netu (= nikoli lan) na 4/6 nekdy je vic hopu na 6 jindy na 4 (klidne dvojnasobek). Rozdil latence do max 30%, ale na obe strany. Ovsem pri zapocitani poctu hopu mi obecne vychazi to, ze 6ka ma per hop zhruba polovicni latenci. Coz bych pricet predevsim tomu, ze tam bude novejsi a vykonejsi HW.
Co se tyce prutoku dat ... vychazi to +- 1% => nemeritelne. Ale obecne se da rict, ze se na 6tce v mnoha pripadech dostanes vyrazne vejs - predevsim na p2p sitich ti mnohem rychlejs klient saturuje linku, a to i za situace, kdy tech peeru co maji 6tku je trebas jen kolem 20%. Pricemz mluvim o situaci, kdy ma klient jak verenou 6tku tak verejnou 4ku. Pokud by verejnou 4ku nemel, bude to pocitam rozdil jeste mnohem razantnejsi.
Trebas yt mi po nativni 6tce jede subjektivne trochu lip, v pripade tunelovany 6tky je to nastejno se 4kou - aby ne, kdyz ten tunel po ni jede - proste to obcas reaguje jak zpomalenej film, ale na 6tce se to deje mene casto.
na jednom jádře nedokážeš takovouhle konektivitu saturovat, ty servery potřebují desítky jader, multi-thread napi pro ethernet je samozřejmost.
Tohle je intra-rack komunikace, žádný L3 switching se nepoužívá, nepotřebuješ routovat podle IP adresy. A ano, ipv6 je udělaná právě takhle divně, aby se využila infrastruktura pro ipv4 a nebylo potřeba výrazněji měnit HW.
@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í.
"Pokud checksum pocita HW, tak chodne, protoze pokud HW nizsi vrstve nerozumi, tak ho nespocita."
1) Transportní vrstva není vyšší oproti síťové. Síťová vrstva je níže než transportní vrstvou. Znamená to tedy, že TCP/UDP datagramy jsou zabaleny v IP paketu. Z toho vyplývá, že pokud pošlu stejná data po IPv4 a IPv6, tak TCP/UDP datagramy budou v obou případech stejné. Lišit se budou teprve na L3 a níže.
HW tedy bude počítat checksum pro TCP/UPD datagram, který přišel přes IPv4 úplně stejně jako pro TCP/UDP datagram, který přišel po IPv6.
2) IPv6 packet má hlavičku pevné délky, což je pro zpracování na HW úplně lepší (jednodušší HW).
3) IPv6 packet je jednodušší. Úplně třeba zmizel checksum, který se u IPv4 musí počítat.
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.
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.
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 "IReallyKnowWhatImDoing", tak se rc4 nedostane do tabulky/seznamu/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
ja bych rekl ze patch neni integrovany v openssh, protoze v gentoo mame hpn use flag:
https://packages.gentoo.org/packages/net-misc/openssh
No nezjistoval jsem zrovna tyhle prepinace, ale uz roky pouzivam HPN-SSH:
https://www.psc.edu/index.php/hpn-ssh
takze pokud te zajima vykon, tak mrkni
ČLÁNKY DO MAILU