Earlier quoted context omitted.
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
SSH3: Faster and rich secure shell using HTTP/3
151–160 of 276 posts
Re: SSH3: Faster and rich secure shell using HTTP/3
#152I 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…
Why not HSH, or HTTPS Shell.
Re: SSH3: Faster and rich secure shell using HTTP/3
#153Written in Go. Terrible name, already discussed in various other comments and author acknowledges. The secret path, otherwise giving 404 would need brute-force protection (on HTTPd level?). I think it is easier to run SSH on a non-standard port on IPv6, but it remains true that anyone with network read access between the endpoints can figure it out. What isn't explained is why would one care about 100 ms latency duri…
yes, but in NL sometimes I am just on the edge of a wifi network coverage and then mosh can be handy. it's an edge case though!
Re: SSH3: Faster and rich secure shell using HTTP/3
#154Earlier quoted context omitted.
AIUI connection migration (as well as multipath handling) is a QUIC feature. And how would that roaming feature differ from "built-in tmux"? I'm not sure the built-in part there would really be an advantage…
Mosh connections don't drop from merely wifi flipping around; you get replies back to the address and port the last uplink packet came from. You can just continue typing and a switch between Wi-Fi and mobile data (for example on a phone while sitting on public transit) shows as merely a lag spike during which typed characters will be predictive echoed by underlining them after an initial delay that serves to avoid fl…
I'm not sure why you're explaining mosh (I know what it is and have used it before), I was asking what there is other than migration (= handled by QUIC) and resumption (= tmux).
Local line editing, I guess. Forgot about that.
Re: SSH3: Faster and rich secure shell using HTTP/3
#155> 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…
> 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.
Re: SSH3: Faster and rich secure shell using HTTP/3
#156given last commit was 1+ year ago, anyone know what the status of the project is?
Re: SSH3: Faster and rich secure shell using HTTP/3
#157> 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.
Re: SSH3: Faster and rich secure shell using HTTP/3
#158It's cool that SSH is getting some love but I'm a little sad they're not being a little more ambitious with regard to new features, considering it seems like they're more or less creating a new thing. Looks like they're going to support connection migration but it would be cool (to me anyway) if they supported some of the roaming/intermittent connectivity of Mosh[1]. 1: https://mosh.org/
One of the things I really like about Mosh is the responsiveness - there's no lag when typing text, if feels like you're really working on a local shell.
I'm guessing SSH3 doesn't do anything to improve that aspect? (although I guess QUIC will help a bit, but isn't quite the same as Mosh is it?)
Re: SSH3: Faster and rich secure shell using HTTP/3
#159Earlier quoted context omitted.
I hate that web-enshittification of SSH is considered the solution to this problem, and many other modern application-level problems. It's done because the web stack exists and is understood by the web/infrastructure folks, not because it represents any kind of local design optima in the non-web space. Using the web stack draws in a huge number of dependencies on protocols and standards that are not just very complex…
I see your point, but I think you're missing the broader picture here. Web protocols are not just used because they are there, but because the stack is very elegantly layered and extensible, well understood and tested, and offer strong security guarantees. It's not like encryption hasn't been tacked onto HTTP retroactively, but at least that happened using proper staples instead of a bunch of duct tape and hope as wi…
> the stack is very elegantly layered and extensible
I have to disagree pretty strongly on this one. Case in point: WebSockets. That protocol switch is "nifty" but breaks fundamental assumptions about HTTP and to this day causes headaches in some types of server deployments.
Re: SSH3: Faster and rich secure shell using HTTP/3
#160I like the idea, especially if it can be proxied by a regular H3 proxy.
If it also solved connection multipath/migration and fixes for TCP-related blocking issues, that'd already be amazing.