SSH3: Faster and rich secure shell using HTTP/3 • Hacker News Board

Re: SSH3: Faster and rich secure shell using HTTP/3

#21

Post by finaard » Sat, Sep 27, 2025, 3:52 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.

Not really that relevant - anybody regularly using SSH over high latency links is using SSH+mosh already anyway.

Re: SSH3: Faster and rich secure shell using HTTP/3

#22

Post by zdw » Sat, Sep 27, 2025, 3:56 PM UTC

psanford wrote: post #19

I do hate the name ssh3. I was glad to see this at the top of the repo: > SSH3 is probably going to change its name. It is still the SSH Connection Protocol (RFC4254) running on top of HTTP/3 Extended connect, but the required changes are heavy and too distant from the philosophy of popular SSH implementations to be considered for integration. The specification draft has already been renamed ("Remote Terminals over H…

Same - this feels equivalent of some rando making a repo called "Windows 12" or "Linux 7".

Re: SSH3: Faster and rich secure shell using HTTP/3

#23

Post by s-macke » Sat, Sep 27, 2025, 3:57 PM UTC

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.

It is not faster in this sense. However, an SSH connection can have multiple substreams, especially for port forwarding. Over a single classical connection, this can lead to head-of-line blocking, where an issue in one stream slows everything down. QUIC/HTTP3 protocol can solve this.

Re: SSH3: Faster and rich secure shell using HTTP/3

#24

Post by MrDarcy » Sat, Sep 27, 2025, 3:57 PM UTC

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.

It’s a necessary evil resulting from misguided corporate security teams blocking and intercepting everything else.

Looking at you, teams who run Zscaler with tls man in the middle attack mode enabled.

Re: SSH3: Faster and rich secure shell using HTTP/3

#25

Post by IOT_Apprentice » Sat, Sep 27, 2025, 3:57 PM UTC

xorcist wrote: post #20

IshKebab wrote: post #17

Earlier quoted context omitted.

He said not waiting for ACKs.

That makes even less sense, unless we are talking about XMODEM every protocol uses windowing to avoid getting stuck waiting for ACKs. Of course you need to wait for ACKs at some point though, otherwise they would be useless. That's how we detect, and potentially recover from, broken links. They are a feature . And HTTP3 has that feature. Is it better implemented than the various TCP algorithms we use underneath regul…

Well, you could peruse the code. Then see what it does and explain it.

Re: SSH3: Faster and rich secure shell using HTTP/3

#26

Post by zenmac » Sat, Sep 27, 2025, 3:59 PM UTC

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.

Yeah we got those good old network ppl or their corporate (don't knows much about tech) overlord to thank for that.

If you ever using wifi in the airport or even some hotel with work suite unit around the world, you will notice that Apple Mail can't send or receive emails. It is probably some company wide policy to first block port 25 (that is even the case with some hosting providers) all in the name of fighting SPAM. Pretty soon, 143, 587, 993, 995.... are all blocked. Guess 80 and 443 are the only ones that can go through any firewalls now days. It is a shame really. Hopefully v6 will do better.

So there you go. And know EU wants to do ChatControl!!!! Please stop this none-sense, listen to the people who actually knows tech.

Re: SSH3: Faster and rich secure shell using HTTP/3

#27

Post by finaard » Sat, Sep 27, 2025, 4:00 PM UTC

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.

Re: SSH3: Faster and rich secure shell using HTTP/3

#28

Post by conradludgate » Sat, Sep 27, 2025, 4:06 PM UTC

xg15 wrote: post #12

chrisfosterelli wrote: post #10

Earlier quoted context omitted.

It feels a little like a kludge as long as we keep calling it http. The premise makes sense -- best practices for connection initialization have become very complex and a lot of protocols need the same building blocks, so its beneficial to piggyback on the approach taken by one of the most battle tested protocols -- but it's not really hypertext we're using it to transfer anymore so it feels funny.

Yeah, building it on top of QUIC is reasonable, but trying to shoehorn SSH into HTTP semantics feels silly.

It's on top of HTTP CONNECT, which is intended for converting an existing request (QUIC stream) into a transparent byte stream. This removes the need to deal with request/response semantics.

The reasons states to use http3 and not QUIC directly makes sense with littlest downside - you can run it behind any standard http3 reverse proxy, under some subdomain or path of your choosing, without standing out to port scanners. While security through obscurity is not security, there's no doubt that it reduces the CPU overhead that many scanners might incur if they discover your SSH server and try a bunch of login attempts.

Running over HTTP3 has an additional benefit. It becomes harder to block. If your ssh traffic just looks like you're on some website with lots of network traffic, eg google meet, then it becomes a lot harder to block it without blocking all web traffic over http3. Even if you do that, you could likely still get a working but suboptimal emulation over http1 CONNECT

Re: SSH3: Faster and rich secure shell using HTTP/3

#29

Post by nh2 » Sat, Sep 27, 2025, 4:09 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.

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 measured eg by iperf3.

I think it's silly that this exists. They should just let TCP handle this.

Re: SSH3: Faster and rich secure shell using HTTP/3

#30

Post by Telemakhos » Sat, Sep 27, 2025, 4:12 PM UTC

zenmac wrote: post #26

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.

Yeah we got those good old network ppl or their corporate (don't knows much about tech) overlord to thank for that. If you ever using wifi in the airport or even some hotel with work suite unit around the world, you will notice that Apple Mail can't send or receive emails. It is probably some company wide policy to first block port 25 (that is even the case with some hosting providers) all in the name of fighting SPA…

Port 25 is insecure and unencrypted; EU doesn't even need ChatControl to hoover up that data, and you'd better believe anything going through an airport wifi router unencrypted is being hoovered by someone no matter what jurisdiction you're in. Apple mail prefers 587 for secure SMTP and 993 for secure IMAP.

People were (wisely) blocking port 25 twenty years ago.