Quicssh: SSH over QUIC
github.com
github.com
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.
Tennish
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.
And lastly you can host it on port 443 so it will look similar to a HTTP connection externally.
It's not anywhere near as bad as you conjecture.
edit: it also has a hardcoded parameter to not validate certs which defeats the whole purpose of it using TLS in the first place... (https://github.com/moul/quicssh/blob/5f5a17c3431a39a8287467d...)
Given the protocol changes needed, it may be a new implementation. I actually expect it would be.
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.
Plus there is like 11 different variants of QUIC out there.
without needing to run mosh on the server
UI is just plain ol' things for user to interact with computer.
To me, mosh is "careful and impressively pedantically correct UTF-8 terminal emulator" + "careful and impressively pedantically correct state synchronization protocol". :)
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. :)
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.
Just like browser apps can't use TCP.
What configuration? I'm trying to assume best intent but have you ever used mosh? It has zero configuration. That's the whole point.
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".
Or modify SSH to do TLS key exchange and TLS-based proof of identity.
why double-encrypt?
https://www.ietf.org/archive/id/draft-bider-ssh-quic-09.html
But I can see not wanting to deal with the problems this creates. :)