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

211–220 of 276 posts

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

#211

Post by inetknght »

s-macke wrote: post #23
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.

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

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

#212

Post by esjeon »

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…

I'm really puzzled by that statement.

RFC 4253(SSH Transport Layer Protocol)[1] says:

   It is expected that in most environments, only 2 round-trips will be needed for full key exchange, server authentication, service request, and acceptance notification of service request.  The worst case is 3 round-trips.
I've never experienced any issues w/ session initialization time. It should be affected by the configuration of both server and client.

[1]: https://datatracker.ietf.org/doc/html/rfc4253

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

#213

Post by Aachen »

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.

Doesn't it run over a single TCP connection in all cases, unless you manually launch multiple and manually load-balance your clients across is? As in, it won't/can't open a new TCP connection when you open a new connection in the SOCKS proxy or port forward. They'll all share one head-of-line and block each other

Not that I've ever noticed this being an issue (no matter how much we complain, internet here is pretty decent)

Edit: seeing as someone downvoted your hour-old comment just as I was adding this first reply, I guess maybe they 'voted to disagree'... Would be nice if the person would comment. It wasn't me anyway

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

#215

Post by oezi »

E39M5S62 wrote: post #155
Levitating wrote: post #150

Earlier quoted context omitted.

> Connection setup time has never been an annoyance for me. It has always bothered me somewhat. I sometimes use ssh to directly execute a command on a remote host.

If you're doing repeated connections to the same host to run one-off commands, SSH multiplexing would be helpful for you. SSH in and it'll open up a local unix domain socket. Point additional client connections to the UDS and they'll just go over the existing connection with out requiring round trips or remote authentication. The socket can be configured to keep itself alive for a while and then close after inactivit…

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

How to enable this?

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

#216

Post by oarsinsync »

oezi wrote: post #215
E39M5S62 wrote: post #155

Earlier quoted context omitted.

If you're doing repeated connections to the same host to run one-off commands, SSH multiplexing would be helpful for you. SSH in and it'll open up a local unix domain socket. Point additional client connections to the UDS and they'll just go over the existing connection with out requiring round trips or remote authentication. The socket can be configured to keep itself alive for a while and then close after inactivit…

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.

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

#217

Post by rurban »

zamadatix wrote: post #184
voxadam wrote: post #177

Earlier quoted context omitted.

Is it dead or just mature?

Mature should still be fixing bugs, which something like mosh is bound to always run into. From that perspective, it doesn't seem like it's just mature. There doesn't seem to be a clear all-in-one successor fork taking the reins either. E.g. https://github.com/mobile-shell/mosh/issues/1339 , as a random sample.

There is https://github.com/jdrouhard/mosh/ for the uniwidth problems. (but could be optimized much more)

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

#218

Post by nasretdinov »

Arch-TK wrote: post #179

SSH is slow, but in my experience the primary cause of slowdown is session setup. Be it PAM, or whatever OpenBSD is doing, the session setup kills performance, whether you're re-using the SSH connection or not, every time you start something within that connection. Now obviously for long running stuff, that doesn't matter as much as the total overhead. But if you're doing long running ssh you're probably using SSH fo…

To speed up Ansible it's sufficient to enable ControlMaster with a short timeout tbh
Post reply on HN