Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH3: Faster and rich secure shell using HTTP/3

github.com

Post reply on HN
Print view View original

241–250 of 276 posts

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

#241

Post by rollcat »

lxgr wrote: post #228
kelnos wrote: post #94

> Establishing a new session with SSHv2 can take 5 to 7 network round-trip times, which can easily be noticed by the user. SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged. Bummer. From a user perspective, I don't see the appeal. Connection setup time has never been an annoyance for me. SSH is battle-tested. This feels risky to trust, even whenever they end up declaring it p…

Yes, and those that have fought in these battles know its limitations. Head-of-line blocking when using multiplexing is definitely one of them. This is a very reasonable incremental improvement. Importantly, it does not seem to switch out any security mechanisms and is both an implementation and a specification draft, which means that OpenSSH could eventually pick it up too so that people don't have to trust a differ…

> [...] which means that OpenSSH could eventually pick it up too [...]

Remember OpenSSH = OpenBSD. They have an opinionated & conservative approach towards adopting certain technologies, especially if it involves a complex stack, like QUIC.

"It has to be simple to understand, otherwise someone will get confused into doing the wrong thing."

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

#242

Post by rollcat »

pancsta wrote: post #157
kelnos wrote: post #94

> Establishing a new session with SSHv2 can take 5 to 7 network round-trip times, which can easily be noticed by the user. SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged. Bummer. From a user perspective, I don't see the appeal. Connection setup time has never been an annoyance for me. SSH is battle-tested. This feels risky to trust, even whenever they end up declaring it p…

UDP tunnels are the main feature, way lighter than wireguard, also OpenID auth.

Wireguard (and certainly every VPN protocol worth your attention) runs on UDP. TCP-over-TCP is a disaster, no sane person does that.

And what's "lighter" than Wireguard? It's about as simple as it can get (certainly simpler than QUIC).

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

#243

Post by zielmicha »

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.

SSH is actually really slow on high latency high bandwidth links (this is what HPN-SSH patches fix: https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq). It's very apparent if you try running rsync between two datacenters on different contients.

HTTP/3 (and hopefully this project) does not have this problem.

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

#246

Post by [deleted] »

inetknght wrote: post #211
s-macke wrote: post #23

Earlier quoted context omitted.

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.

Fun fact: SSH also supports multiple streams. It's called multiplexing.

[deleted]

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

#247

Post by [deleted] »

oarsinsync wrote: post #216
oezi wrote: post #215

Earlier quoted context omitted.

Why isn't this the default behavior to use this UDS? How to enable this?

> Why isn't this the default behavior to use this UDS? Because it’s insecure to use on multiuser systems, as it presents an opportunistic access to remote systems for root users on your local system: root can read and write into your UDS too. As a user, you have to explicitly opt into this scenario if you deem it acceptable.

[deleted]

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

#248

Post by nh2 »

jlokier wrote: post #198
nh2 wrote: post #29

Earlier quoted context omitted.

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…

> I think it's silly that this exists. They should just let TCP handle this. No, unfortunately it'snecessary so that the SSH proocol can multiplex streams independently over a single established connection. If one of the multiplexed streams stalls because its receiver is blocked or slow, and the receive buffer (for that stream) fills up, then without window-based flow control, that causes head-of-line blocking of all…

Then:

* Give users a config options so I can adjust it to my use case, like I can for TCP. Don't just hardcode some 2 MB (which was even raised to this in the past, showing how futile it is to hardcode it because it clearly needs adjustments to people's networks and and ever-increasing speeds). It is extremely silly that within my own networks, controlling both endpoints, I cannot achieve TCP speeds over SSH, but I can with nc and a symmetric encryption piped in. It is silly that any TCP/HTTP transfer is reliably faster than SSH.

* Implement data dropping and retransmissions to handle blocking -- like TCP does. It seems obviously asking for trouble to want to implement multiplexing, but then only implement half of the features needed to make it work well.

When one designs a network protocol, shouldn't one of the first sanity checks be "if my connection becomes 1000x faster, does it scale"?

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

#249

Post by nh2 »

Operyl wrote: post #40
nh2 wrote: post #29

Earlier quoted context omitted.

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…

Off the top of your head do you know of any file transfer tools that do utilize multiple streams?

Yes, I wrote down some that do and don't support it here:

https://github.com/libfuse/sshfs/issues/300

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

#250

Post by espadrine »

bcrl wrote: post #39
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.

That's why mosh exists, as it is purpose built for terminals over high latency / high packet loss links.

mosh is hard to get into. There are many subtle bugs; a random sample that I ran into is that it fails to connect when the LC_ALL variables diverge between the client and the server[0]. On top of it, development seems abandoned. Finally, when running a terminal multiplexer, the predictive system breaks the panes, which is distracting.

[0]: https://github.com/mobile-shell/mosh/issues/98

Post reply on HN