> 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.
I'm really puzzled by that statement.
RFC 4253(SSH Transport Layer Protocol)[1] says:
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
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).
> 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.)
If you want keystroke latency to feel faster check out Mosh shell: https://github.com/mobile-shell/mosh
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.
> [...] 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."
Head-of-line blocking is likely fully addressed by ssh3 where multiplexing several ports/connections over a single physical ssh3 connection should be faster.
Calling anything here "physical" is strange and confusing to me. Surely you don't mean the physical layer?
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.
> 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 inactivity. Huge huge speed boost over repeated fresh TCP connections.
Why isn't this the default behavior to use this UDS?
How to enable this?
Look for documentation on the ControlMaster / ControlPath / ControlPersist options for OpenSSH.
> 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.
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.
If you are looking for a smoother UX: https://mosh.org/
Sadly this project looks dead.
still works great though, there's a lot great software I use that hasn't had an update in years or even decades
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)
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
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.
i was pointing out that saying the package is unmaintained is likely to be false. to add my comment to your comment, i would imagine that distros are not keeping important patches like security to themselves.
i.e. this package being somehow abandoned and therefore should not be trusted is likely to be false
The above has all been in reference to the mosh project, not any individual distro packaging. E.g. if you "brew install mosh" on macOS right now you will indeed get an official-but 3-year-old-release without any patches Fedora (or others) may have applied since https://formulae.brew.sh/api/formula/mosh.json. The same is true if one goes to the project's GitHub to download it manually.
> i would imagine that distros are not keeping important patches like security to themselves.
I'm not 100% sure what "keeping to themselves" means in context of GPL 3 code, but one can verify with the mosh GitHub link to see the upstream project has not had a single commit on any branch for the last 2.5 years.
The project is dead, it's up to your trust+verification of any specific downstream packaging as to how much of a problem that is for the binary you may be using. Some maintainers may not have noticed/cared enough yet, some maintainers may only carry security fixes of known CVEs, some maintainers may be managing a full fork. The average reader probably wants to note that for their specific binary rather than note Fedora still packages a downstream version (which may be completely different).