Quicssh: SSH over QUIC(github.com)
github.com
Quicssh: SSH over QUIC
https://github.com/moul/quicssh
62 comments
What time did Sean Connery show up to Wimbledon?
Tennish
Tennish
I would have gone with Quissh, (pronounced "quiche")
but there are two quic quiche projects already :'''(
This looks like the worst of all worlds.
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.
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's not anywhere near as bad as you conjecture.
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.
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.
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...)
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...)
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.
I doubt e.g. OpenSSH would ever implement something like you describe though. They're seemingly very much against anything x509/WebPKI.
I believe section 7 of RFC 9000 would allow for the creation of a handshake protocol which could conform to SSH without the need for including x509.
Thanks for the tip, wasn't aware of this.
You imply OpenSSH is the place to do this work.
Given the protocol changes needed, it may be a new implementation. I actually expect it would be.
Given the protocol changes needed, it may be a new implementation. I actually expect it would be.
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.
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.
It's like SCTP only worse.
SCTP has better header overhead than HTTP/2+QUIC
Plus there is like 11 different variants of QUIC out there.
Plus there is like 11 different variants of QUIC out there.
Would this make ssh more robust against intermittent connectivity? like https://mosh.org/
without needing to run mosh on the server
without needing to run mosh on the server
Mosh has latency-hiding mechanisms. I used mosh for a bit on while riding a bus. Latency-hiding helped quite a bit to keep the UI responsive.
Do you mean UI as in X forwarding? I thought this wasn't possible, which kept me from using mosh so far.
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". :)
To me, mosh is "careful and impressively pedantically correct UTF-8 terminal emulator" + "careful and impressively pedantically correct state synchronization protocol". :)
It doesn't have to be this piece of software implementing MP-UDP for roaming to work though. Nevertheless I doubt it has such functionality right now.
Mosh is closer to tmux than to ssh.
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. :)
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.
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.
[deleted]
Is there actually anything ssh-specific here? Seems like quic support is something that could fit something like socat pretty well?
I think so, I tried to proxy a raw TCP server and it didn't work.
It's SSH-specific only on the server side, right? The client side looks like a normal TCP tunnel (-o ProxyCommand)
If it's SSH-specific on one side, and unpacks the protocol, it probably has to be SSH-specific on the other side.
What's the use case for this?
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.
I think the lack of head of line blocking could be useful for SSH session multiplexing when using it as an ad hoc VPN.
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.
Apparently SSH over UDP with much less code and configuration compared to Mosh.
> Apparently SSH over UDP with much less code and configuration compared to Mosh.
What configuration? I'm trying to assume best intent but have you ever used mosh? It has zero configuration. That's the whole point.
What configuration? I'm trying to assume best intent but have you ever used mosh? It has zero configuration. That's the whole point.
Last time I installed Mosh (on Ubuntu) I just installed the package & did not need to do any configuration. It just worked.
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".
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.
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?
why double-encrypt?
why double-encrypt?
There's an IETF draft for SSH over QUIC, but I'm not sure if this is an implementation of it, or an own thing:
https://www.ietf.org/archive/id/draft-bider-ssh-quic-09.html
https://www.ietf.org/archive/id/draft-bider-ssh-quic-09.html
... why though? Like, I don't see the point and there is no explanation in the README, either.
socat and quicat exist, so why doesn't anyone need this?
Have you succeeded at using quicat to do what this is doing?
port hopping support would be awesome, like hysteria do
Does this not even build for anyone else?
If one could run this alongside with Wireguard and H/3 on the same port, that would be very interesting against analysis.
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.