SSH3: Faster and rich secure shell using HTTP/3

Post by doubled112 » Sat, Sep 27, 2025, 4:13 PM UTC

finaard wrote: post #27

she46BiOmUerPVj wrote: post #8

So with HTTP requests you can see the domain name in the header and forward it to the correct host. That was never a thing you could do with SSH, does this allow that to work?

But that wasn't really a thing that was an issue with SSH. Host *.internal.example.com ProxyCommand ssh -q -W %h:%p hop.internal.example.com in the SSH client config would make everything in that domain hop over that hop server. It's one extra connection - but with everything correctly configured that should be barely noticeable. Auth is also proxied through.

    Host *.internal.example.com
      ProxyJump hop.internal.example.com

Post by fanf2 » Sat, Sep 27, 2025, 4:16 PM UTC

notepad0x90 wrote: post #13

Zambyte wrote: post #2

I was skeptical of the claim that it's faster than traditional SSH, but the README specifies that it is faster at establishing a connection, and that active connections are the same speed. That makes a lot of sense and seems like a reasonable claim to make.

Although, dollars-to-donuts my bet is that this tool/protocol is much faster than SSH over high-latency links, simply by virtue of using UDP. Not waiting for ack's before sending more data might be a significant boost for things like scp'ing large files from part of the world to the another.

Post by singpolyma3 » Sat, Sep 27, 2025, 4:18 PM UTC

xg15 wrote: post #14

temp0826 wrote: post #5

I don't know why it makes me a little sad that every application layer protocol is being absorbed into http.

If this were really the case, it would indeed be sad, as the standard HTTP request/response model is both too restrictive and too overengineered for many usecases. But both HTTP/2 and QUIC (the "transport layer" of HTTP/3) are so general-purpose that I'm not sure the HTTP part really has a lot of meaning anymore. At least QUIC is relatively openly promoted as an alternative to TCP, with HTTP its primary usecase.

Post by fanf2 » Sat, Sep 27, 2025, 4:21 PM UTC

nh2 wrote: post #29

notepad0x90 wrote: post #13

Earlier quoted context omitted.

Although, dollars-to-donuts my bet is that this tool/protocol is much faster than SSH over high-latency links, simply by virtue of using UDP. Not waiting for ack's before sending more data might be a significant boost for things like scp'ing large files from part of the world to the another.

SSH has low throughput on high latency links, but not because it uses TCP. It is because SSH hardcodes a too-small maximum window size in its protocol, in addition to the one of TCP. This SSH window size limit is per ssh "stream", so it could be overcome by many parallel streams, but most programs do not make use of that (scp, rsync, piping data through the ssh command), so they are much slower than plain TCP as meas…

Post by bcrl » Sat, Sep 27, 2025, 4:26 PM UTC

notepad0x90 wrote: post #13

Zambyte wrote: post #2

I was skeptical of the claim that it's faster than traditional SSH, but the README specifies that it is faster at establishing a connection, and that active connections are the same speed. That makes a lot of sense and seems like a reasonable claim to make.

Although, dollars-to-donuts my bet is that this tool/protocol is much faster than SSH over high-latency links, simply by virtue of using UDP. Not waiting for ack's before sending more data might be a significant boost for things like scp'ing large files from part of the world to the another.