5 ms·

> 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. T

by kelnos 1y ago

> 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 production-ready.

thethimble 1y ago
Head-of-line blocking is likely fully addressed by ssh3 where multiplexing several ports/connections over a single physical ssh3 connection should be faster.
- john01dav 1y ago
  Calling anything here "physical" is strange and confusing to me. Surely you don't mean the physical layer?
  - zamadatix 1y ago
    I've seen it a lot with communication protocols for some reason, I guess it's just relatively clear it means "the non virtualized" even though it's clearly a misnomer. E.g. with VRRP a ton of people just say "the physical IP" when talking about the address that's not the VIP, even though the RFC refers to it as "the primary" IP. Arguably "primary IP" is more confusing as to which is being referred to, even though it's more technically accurate. Of course, maybe there's a perfectly obvious word which can apply to all of those kinds of situations just as clearly without being a misnomer I've just never thought to mention in reply :D.
athrowaway3z 1y ago
If you are looking for a smoother UX: https://mosh.org/ https://mosh.org/
- gdevenyi 1y ago
  Sadly this project looks dead.
  - fsiefken 1y ago
    still works great though, there's a lot great software I use that hasn't had an update in years or even decades
  - voxadam 1y ago
    Is it dead or just mature?
    - zamadatix 1y ago
      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 https://github.com/mobile-shell/mosh/issues/1339, as a random sample.
      - rurban 1y ago
        There is https://github.com/jdrouhard/mosh/ https://github.com/jdrouhard/mosh/ for the uniwidth problems. (but could be optimized much more)
      - fsckboy 1y ago
        mosh is still included in the Fedora repository (and probably others, I didn't check) major distros are maintained, and they wouldn't be shipping it if it had bugs and/or was being used as an exploit
        zamadatix 1y ago
        Each distro package maintainer is always welcome to maintain patches in their forks for as long as they like, but the quality and life of each will be per distro as these efforts are coordinated with an upstream.
Levitating 1y ago
> 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.
- E39M5S62 1y ago
  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 inactivity. Huge huge speed boost over repeated fresh TCP connections.
  - oezi 1y ago
    Why isn't this the default behavior to use this UDS? How to enable this?
    - oarsinsync 1y ago
      > 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 1y ago
        [deleted]
      - immibis 1y ago
        I don't think that's the reason. root can theoretically do everything and not much is protected from root. root can su to your account and make a new SSH connection. root can replace the ssh command with one that copies their public key before opening a shell.
    - 1y ago
pancsta 1y ago
UDP tunnels are the main feature, way lighter than wireguard, also OpenID auth.
- otabdeveloper4 1y ago
  > also OpenID auth Wait, what? Does it actually work? If yes, this is a huge deal. This potentially solves the ungodly clusterfuck of SSH key/certificate management. (I don't know how OpenID is supposed to interact with private keys here.)
- rollcat 1y ago
  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).
  - pancsta 1y ago
    SSH is always deployed, wireguard needs to be (additionally) deployed. Wireguard gives a network address, SSH gives you a network port.
varenc 1y ago
If you want keystroke latency to feel faster check out Mosh shell: https://github.com/mobile-shell/mosh https://github.com/mobile-shell/mosh
esjeon 1y ago
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 https://datatracker.ietf.org/doc/html/rfc4253
lxgr 1y ago
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 different implementing party.
- rollcat 1y ago
  > [...] 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."

by kelnos 1y ago

thethimble 1y ago

Head-of-line blocking is likely fully addressed by ssh3 where multiplexing several ports/connections over a single physical ssh3 connection should be faster.

john01dav 1y ago
Calling anything here "physical" is strange and confusing to me. Surely you don't mean the physical layer?
- zamadatix 1y ago
  I've seen it a lot with communication protocols for some reason, I guess it's just relatively clear it means "the non virtualized" even though it's clearly a misnomer. E.g. with VRRP a ton of people just say "the physical IP" when talking about the address that's not the VIP, even though the RFC refers to it as "the primary" IP. Arguably "primary IP" is more confusing as to which is being referred to, even though it's more technically accurate. Of course, maybe there's a perfectly obvious word which can apply to all of those kinds of situations just as clearly without being a misnomer I've just never thought to mention in reply :D.

athrowaway3z 1y ago

If you are looking for a smoother UX: https://mosh.org/ https://mosh.org/

gdevenyi 1y ago
Sadly this project looks dead.
- fsiefken 1y ago
  still works great though, there's a lot great software I use that hasn't had an update in years or even decades
- voxadam 1y ago
  Is it dead or just mature?
  - zamadatix 1y ago
    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 https://github.com/mobile-shell/mosh/issues/1339, as a random sample.
    - rurban 1y ago
      There is https://github.com/jdrouhard/mosh/ https://github.com/jdrouhard/mosh/ for the uniwidth problems. (but could be optimized much more)
    - fsckboy 1y ago
      mosh is still included in the Fedora repository (and probably others, I didn't check) major distros are maintained, and they wouldn't be shipping it if it had bugs and/or was being used as an exploit
      - zamadatix 1y ago
        Each distro package maintainer is always welcome to maintain patches in their forks for as long as they like, but the quality and life of each will be per distro as these efforts are coordinated with an upstream.

Levitating 1y ago

> 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.

E39M5S62 1y ago
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 inactivity. Huge huge speed boost over repeated fresh TCP connections.
- oezi 1y ago
  Why isn't this the default behavior to use this UDS? How to enable this?
  - oarsinsync 1y ago
    > 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 1y ago
      [deleted]
    - immibis 1y ago
      I don't think that's the reason. root can theoretically do everything and not much is protected from root. root can su to your account and make a new SSH connection. root can replace the ssh command with one that copies their public key before opening a shell.
  - 1y ago

pancsta 1y ago

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

otabdeveloper4 1y ago
> also OpenID auth Wait, what? Does it actually work? If yes, this is a huge deal. This potentially solves the ungodly clusterfuck of SSH key/certificate management. (I don't know how OpenID is supposed to interact with private keys here.)
rollcat 1y ago
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).
- pancsta 1y ago
  SSH is always deployed, wireguard needs to be (additionally) deployed. Wireguard gives a network address, SSH gives you a network port.

varenc 1y ago

If you want keystroke latency to feel faster check out Mosh shell: https://github.com/mobile-shell/mosh https://github.com/mobile-shell/mosh

esjeon 1y ago

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 https://datatracker.ietf.org/doc/html/rfc4253

lxgr 1y ago

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 different implementing party.

rollcat 1y ago
> [...] 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."