171–180 of 276 posts
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.
Earlier quoted context omitted.
The huge downside of mosh is it handles its own rendering and destroys the scrollback buffer. (Yes I know I can add tmux for a middle ground.) But it's still irrelevant here; specifically called out in README: > The keystroke latency in a running session is unchanged.
"huge downside" (completely mitigated by using tmux) The YouTube and social media eras made everyone so damn dramatic. :/ Mosh solves a problem. tmux provides a "solution" for some that resolves a design decision that can impact some user workflows. I guess what I'm saying here, is it you NEED mosh, then running tmux is not even a hard ask.
1. High latency, maybe even packet-dropping connections;
2. You’re roaming and don’t want to get disconnected all the time.
For 2, sure tmux is mostly okay, it’s not as versatile as the native buffer if you use a good terminal emulator but whatever. For 1, using tmux in mosh gives you an awful, high latency scrollback buffer compared to the local one you get with regular ssh. And you were specifically taking about 1.
For read-heavy, reconnectable workloads over high latency connections I definitely choose ssh over mosh or mosh+tmux and live with the keystroke latency. So saying it’s a huge downside is not an exaggeration at all.
> 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.
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.)
Please don't give short abbreviated names. Useful full names for commands. Teach full names. When you present something, show full names. If this project used a full name like `remote-terminals-over-http3`, we would not be having this debate about ssh3.
Of course, end users and system administrators and even package managers/distributions are free to add abbreviations but we should be teaching people to use full names.
Prefer things like Set-Location over cd. Prefer npm install --global over npm i -g. Prefer remote-terminals-over-http3 over ssh3.
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…
Earlier quoted context omitted.
Maybe SSH/3 instead ( SSH + HTTP /3 )?
Doesn't /3 mean v3? I mean, for HTTP itself, doesn't the HTTP/3 == HTTPv3? If so, I don't see how this is any better than SSH3 - both SSH3 and SSH/3 read to me like "SSH v3"
I've seen very little do that. Probably just HTTP, and it's using a slash specifically to emphasize a big change.
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 for its remote terminal purposes and you don't care if it takes 0.5 seconds or 1 second before you can do anything. And if you want file transfer, we already had a HTTP/3 version of that - it's called HTTP/3.
Ansible, for example, performs really poorly in my experience precisely because of this overhead.
Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost.
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…
Secure Hypertext Interactive TTY