To vypada, ze stunnel je na tom lepe. Kdo taha velke objemy po SSH?
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.
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.
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.