You get TCP on both sides of the connection and QUIC in the middle, which will be acting as a single stream protocol, not getting to use all of its advantages.
But both TCP connections are to localhost so, you get 64K MTU unlike 1500/9000 over a network connection. Also, blocking / polling will be much quicker locally (in the order of microseconds not milliseconds minimum for over the Internet).
And lastly you can host it on port 443 so it will look similar to a HTTP connection externally.
It is every bit as bad. QUIC streams could map nicely to the SSH model of discrete channels. Sure, you can run it over tcp/443 and have it look like a normal TLS connection to anything that isn't monitoring the traffic patterns, but it's effectively just adding a TLS pipe which only achieves the use of QUIC's congestion control algorithm and handshake but nothing else. I would love to see an SSH implementation which uses QUIC correctly; this isn't it.
MOSH already exists, and it is a proper ssh-like protocol over UDP that takes advantage of the properties of UDP. It's great for use when traveling and being forced to use horrible high latency wireless connections.
MOSH is really a on-purpose "horrible SSH" as far as SSH goes, but it is instead intended to be what you actually need for remote, unstable, unreliable slow connections: a somewhat reponsive experience, a kinda of remote desktop protocol but for terminals, you only send the input and output deltas; you intentionally don't block waiting at any side for precise confirmation of every single byte in or out of a remote terminal.
It’s a bit of a silly hack and it seems pretty stupid to be encrypting things twice. But there’s also a pretty stupid advantage which is that openssh sets pretty small limits on socket buffer sizes whereas quic (hopefully) does not, so if you are rsyncing or scping files over a long distance (and have reasonably modern cpus and crypto libraries) you’ll find things are faster. You could use hpn-ssh but then that’s potentially more configuration to do.
I think this might also come with quic advantages like tolerance for changing ip (eg if one client is mobile) though I think people have other wireguard based solutions they like for that.
The most obvious disadvantage to me is security: sometimes local connections are treated differently by sshd, eg allowed to log in as root.
The "G" in "GUI" stands for "graphical". Some people use "TUI" to mean "Terminal User Interface". It therefore follows that someone using merely "UI" has not specified the type of interface.
Probably only if this implements a similar roaming concept as mosh by using a nonce or something along that line vs. ssh session keys that are mapped to an IP. Mosh was designed by MIT folks not just for high latency but also mobile networks which can change IP and lose connectivity frequently. Perhaps the code author is here on HN?
Mosh was designed for a great number of things, including what you mentioned.
To me, mosh is "careful and impressively pedantically correct UTF-8 terminal emulator" + "careful and impressively pedantically correct state synchronization protocol". :)
Any similarity with tmux is purely because it's connectionless. It's mostly certainly more like ssh than it is like tmux. Both are remote shell protocols, while tmux is simply a terminal multiplexer.
Mosh is not at all like ssh, tries hard to avoid duplicating ssh functionality, and this is by design.
If it were like ssh the authors would have had to then handle security/authentication and all that jazz perfectly. It was written to "stand on the shoulders" of ssh, except handle terminal emulation and UTF-8 correctly. By using ssh, you don't have to trust "some new thing" as long as you trust ssh.
It's not even a shell protocol if you think about it!
Mosh bidirectionally synchronizes the state between the terminal window on the client and the virtual terminal on the server. It runs at a frame rate, which results in not filling intermediate network queues, which is where the low latency comes from. :)
> It's not even a shell protocol if you think about it!
Nor is SSH. Feel free to take a read over the RFCs. There's next to no 'sh' in SSH as a protocol. What mosh adds to SSH is the ability to securely resume a session. SSH is fundamentally protocol for setting up a secure connection and then ping-pong messages back and forth.
tmux runs locally. It's not a network daemon. The complexion of a daemon and protocol meant to operate over a network is very, very different from one intended to run over Unix domain sockets or on the loopback interface.
Mosh is a terminal emulator itself and sends the diff of the output from the server to the client. Ssh just passes the terminal data through. I think that is why mosh is like tmux, because tmux is also a terminal emulator.
Since quic sessions can be tracked by the connection id rather than the srcip/dstip/sport/dport/ipproto 5-tuple you could switch networks and have your session survive. Not sure if this implementation achieves that or not though.
Since browsers implement QUIC, probably you can run SSH over QUIC on a web browser, making it possible to run ssh client on unconventional platforms that have a browser.
It looks like the multiplexed SSH channels are in a single QUIC stream, so it doesn't help with head-of-line blocking? Honestly not sure what it does from reading the README.
Alright, so we're double-encrypting traffic? Or is it not encrypting the SSH tunnel? Or did QUIC finally come around to having a Sane not-encrypted mode?
It's double encrypting the traffic. SSH is completely unaware that there's a tunnel moving this data over the Internet, that's being done by the "Quicssh" proxy in their diagram which is software at both ends doing QUIC.
If you were building this into SSH itself you'd have to do a bunch of work to arrange to do SSH-style KEX instead of the TLS KEX that QUIC would normally use, and then do SSH-style proof-of-identity for the server and client, rather than the equivalent TLS mechanisms. Once you have a shared secret, there's no reason QUIC streams aren't a drop-in replacement for the SSH encrypted TCP streams, thus no double encryption needed. It's definitely possible to design this, and maybe it's even worth somebody's time to do it, although my instinct is that won't be OpenSSH people.
It would make no sense for the IETF to standardise a "not-encrypted mode" for QUIC given BCP 188 "Pervasive Monitoring Is An Attack".
The real win from quic might come from mapping ssh channels to quic streams (are they called that?). Then you could have many forwarded tcp streams internally (for a socks proxy etc) but wouldn't have to deal with SSH channel windowing slowing things down.
> If you were building this into SSH itself you'd have to do a bunch of work to arrange to do SSH-style KEX instead of the TLS KEX that QUIC would normally use, and then do SSH-style proof-of-identity for the server and client, rather than the equivalent TLS mechanisms.
Or modify SSH to do TLS key exchange and TLS-based proof of identity.
Has someone made a faithful representation of ssh over quic? You could use quic’s built in certificates and multiple streams of data and create something very similar to ssh. Is anyone doing that?
Surely the protocol of choice over QUIC (assuming the endpoint which terminates the QUIC binding is itself the host being logged into) would be .. telnet?
Does this map SSH channels into QUIC channels? They're in hand-waving terms similar in concept. Edit: I'm going to guess not since it's a proxy.