Názory k článku
SSH3: experimentální vzdálený shell využívající HTTP/3

Clanek mi prijde umyslne manipulativni, protoze zatajuje, ze stavajici implementace OpenSSH jiz dlouho dobu umi socks proxy, coz je mnohem obecnejsi mechanismus nez presmerovani portu a k presmerovani UDP lze samozrejme pouzit. Dale OpenSSH umoznuje k overeni uzivatele vyuzit PAM, ktery umi pouzit google auth, takze ani zde se o zadnou novinku nejedna.

Uměl bys ukázat, jak to SSH3 těmi existujícími prostředky nahradit nebo simulovat?

> socks proxy, coz je mnohem obecnejsi mechanismus nez presmerovani portu a k presmerovani UDP lze samozrejme pouzit

No, ale IIUC pak půjde UDP přes TCP. U HTTP/3 by snad mohlo jít vše přes UDP. Ale neznám všechny detaily, a jestli tam QUIC někde z toho UDP neudělá tak trochu TCP.

K využití socks proxy potřebujete, aby to podporovala aplikace, jejíž komunikaci chcete tunelovat. Samozřejmě můžete použít ještě jinou aplikaci, která bude pro přesměrování UDP používat socks proxy. Pak ale taky můžete tvrdit, že OpenSSH podporuje protokol HTTP, protože ten také můžete tunelovat skrze socks proxy…

Nepotrebujete, protoze snad od pocatku existence socks proxy existuje knihovna, ktera se preloaduje k libc a prida podporu pro vsechny aplikace pouzivajici sockety pres libc. To je take duvod, proc jen par aplikaci podporuje socks proxy primo - pro vetsinu aplikaci to je totiz zbytecnost.

SSH standard přenosy UDP paketů žádným způsobem neřeší.
A pokud mi neutekla nějaká nedávná změna v OpenSSH, tak UDP spojení přes vestavěnou SOCKS 5 proxy (-D) rozhodně nenavážete. Vůbec totiž nepodporuje příkaz UDP associate, kterým se v SOCKS komunikaci přiřadí socket, co server otevře, a na který pak klient posílá UDP data.
A samozřejmě, aby tohle fungovalo na zamýšlené tunelování, musel by v OpenSSH také být mechanismus na přenos UDP paketů přes TCP spojení.

Asi byste přes OpenSSH TCP forwarding ručně nastavil nějaký statický UDP->TCP->UDP tunel s využitím vhodné utility na klientu i serveru (pamatuji si udptunnel), ale to je řešení pro jedno konkrétní spojení resp. aplikaci narozdíl od dynamického SOCKSu. Navíc tam budou všechny obecné nevýhody posílání bezstavového UDP přes TCP.

Přes SOCKS to sice nepůjde, ale OpenSSH už nějakou dobu umí vytvořit klasické tun zařízení (parametrem -w nebo konfigurační volbou Tunnel) jak v režimu L3, tak i L2. Takže v obou případech přes to protlačíte libovolný IP provoz (tedy samozřejmě i UDP) bez nutnosti jakékoli speciální podpory na straně tunelované aplikace. V druhém případě tím můžete klidně bridgovat Ethernet, když budete opravdu chtít.

Je to tedy úplně generický nástroj, i když to má samozřejmě daleko k plnotučné VPN stylu OpenVPN, protože SSH za vás nezařídí přiřazování adres, nastavení routování a další všemožnou autokonfiguraci. Nevýhody tunelování UDP skrz TCP samozřejmě zůstávají. (I když bych se nedivil, kdyby SSH3 také tunelovaný UDP provoz serializovalo do jednoho toku spolu se vší ostatní komunikací v dané relaci. Detaily jsem ale nezkoumal.)

Ano, je to tak, díky za doplnění. Routování provozu přes tun rozhraní jsem pro nějaké ad-hoc věci také už párkrát využil. Reagoval jsem spíš na první post ohledně SOCKS proxy.

Jak to mají s posíláním UDP technicky provedené v SSH3 jsem také zatím nestudoval. Doufám, že se k ozkoušení této první implementace dostanu mezi svátky ;) Pro QUIC sice existuje i draft https://datatracker.ietf.org/doc/html/draft-piraux-quic-tunnel-02 pro obecné tunelování protokolů v TLV struktuře přes streamy a vím, že existuje i třeba SMB over QUIC, ale v SSH3 paperu píšou, že se rozhodli pro implementaci nad HTTP/3, kvůli možnému používání HTTP/3 proxy příp. mapování serverů pod různé URL.
Musím to ještě dost prozkoumat, netuším, jaké poskytuje HTTP/3 standard všechny možnosti.

Tak pokud chci neco obecnejsiho, nez jen jedno konkretni spojeni, muzu pouzit TUN tunelovani, ktere SSH tez podporuje. Resit problemy prenosu bezstavoveho UDP pres TCP u reseni, ktere bezi pres SSH, mi prijde zbytecne, protoze je jasne, ze to nikdo nepouzije u neceho, kde mu zalezi na vykonu, kdyz tu mame WireGuard, kterej je trivialni na nastaveni a vpodstate ve vsem lepsi.

TUN virt. síť rozhraní samozřejmě použít můžete, stejně jako některé z dalších řešení společně s SSH, přičemž každé z nich bude mít své výhody i nevýhody. Třeba u TUN musím mít na klientu práva na incializaci toho síť. rozhraní, manipulovat s routovací tabulkou a oproti SOCKS tam budu obtížně řešit, pokud bych chtěl komunikovat jen z jedné aplikace. Pokud nebudu mít přesný výčet adres/podsíti, s kterými chci přes ten tunel komunikovat, tak přes něj musím hrnout všechno a ze všech aplikací (def. gw), pokud si to nechci dál komplikovat třeba přes cgroups, ale i to je zas vázané jen na Linux. Což samozřejmě někdy nemusí, ale také může vadit. atd. atd.

Ale já spíš reagoval na to, jak jste v tom prvním postu víceméně psal, že UDP přes stávající SSH no problem, a co tady kdo řeší, když tu máme SOCKS (nebo rovnou nějakou separátní VPNku). S čímž úplně nesouhlasím.

Mě ta snaha o nějaký čerstvou diskuzi ohledně budoucí varianty SSH s použitím výhod QUICu resp. HTTP/3 smysl dává. A přestože to je v podstatě zatím jen výkop k tématu a tahle jejich Go implementace je Proof of Concept, tak ty zmíněné výhody (nižší latence, lepší odezva, jednodušší transport UDP paketů, flexibilní ověřování s použitím standardních JWT v hlavičce) bych ocenil.
Ale uvidíme, jaká na to bude obecná odezva, a jestli to vůbec dojde k nějaké standardizaci. Rozhodně si nemyslím, že by se teď všichni vrhli na nahrazování SSH-2 :)

Podle me jste popletl cgroups a jmenne prostory, protoze cgroups controlery ze sitovych veci umi ridit jen klasifikaci a prioritu. Pokud bych chtel nektere aplikace routovat pres TUN zarizeni, je potreba pro toto zarizeni vytvorit defaultni routovaci zaznam ve jmennem prostoru pomoci:
ip netns exec $VPNNS ip route add default dev $TUN
a pak aplikace poustet
ip netns exec $VPNNS firefox
cgroups ani nemusi byt v kernelu zapnute.

Provozoval jsem pres socks proxy Firefox s WebRTC aplikaci, proto jsem se domnival, ze UDP SSH SOCKS serverem podporovano je, ale nejsem sitar, takze je mozne, ze WebRTC se bez UDP obejde. Moje kritika clanku je hlavne o tom, ze clanek zamlcuje existujici schopnosti aby navrhovane reseni vypadalo vice pokrokove, nez ve skutecnosti je.

Řekl bych, že pokud mi něco na tom vadí, tak je to zanášení HTTP do shellové komunikace. Na můj vkus je tam těch protokolů už nějak moc.

Zase to bude mít výhodu, že se na nějaký stroj uvnitř sítě bude dát dostat přes jednu HTTP proxy, to na jaký stroj se chci připojit bude určovat jeho doménové jméno a vše půjde propašovat přes jeden port 443. Už teď "téhle výhody" využívám u SSTP nebo OpenVPN s nakonfigurovaným port-share, kde je možné se přes 443 probojovat z různých států, kde je internet cenzurován a filtrován.

To lze samozřejmě už teď, dá se na to krásně použít utilita wstunnel a klidně se to dá schovat za běžný webový server. Popisoval jsem to v článku WebSocket jako cesta k úniku z příliš restriktivní sítě. SSH je pak tunelováno pomocí HTTPS ve WebSocketu a na druhé straně se vybalí. Z hlediska sítě se to chová jako běžný webový provoz.

...a funguje to přesně do okamžiku, kdy ta restriktivní síť začne přebalovat komunikaci vlastním certifikátem - kterému stejně nevěříte, takže se to celé rozpadne. ;o(

S takovým zásahem v síti se nedá nic dělat. Jedinou ochranou je důsledná kontrola podpisů a odmítnutí takto uneseného spojení. Ovšem to je problém každého protokolu, včetně čistého SSH.

Ano dá, ale je to stejné jako o vlákno výš, že SSH2 přeci umí SOCKS proxy, tak co bychom ještě chtěli... :-)

Moc se mi líbí především možnost snadného nasazení ověření přes openid nebo tokeny.

Už si to někdo troufl rozjet? :)

Láká mě to, ale nasazovat to na všech firemních serverech se mi zatím asi nechce.

Tj, to bude uzasny ... jeden jim vsem vladne ...