34 ms·
Quicssh: SSH over QUIC
- itsTyrion 3y ago... why though? Like, I don't see the point and there is no explanation in the README, either.
- nnntriplesec 3y agoWould this make ssh more robust against intermittent connectivity? like https://mosh.org/ https://mosh.org/ without needing to run mosh on the server
- FrancoisBosun 3y agoMosh 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.
- cl3misch 3y agoDo you mean UI as in X forwarding? I thought this wasn't possible, which kept me from using mosh so far.
- tempay 3y agoThey mean UI as in for command lines, like vim/emacs/shells
- egberts1 3y agoTUI, better? UI is just plain ol' things for user to interact with computer.
- NoZebra120vClip 3y agoThe "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.
- ori_b 3y agoMosh is closer to tmux than to ssh.
- talideon 3y agoAny 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.
- deleted 3y ago[deleted]
- hackernudes 3y agoMosh 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.
- loxias 3y agoMosh 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. :)
- talideon 3y ago> 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.
- LinuxBender 3y agoProbably 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?
- Avamander 3y agoIt 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.
- loxias 3y agoMosh 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". :)
- rwmj 3y agoLost opportunity to call this (Sean Connery's voice) "quicsshilver" ... 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.
- aidenn0 3y agoWhat time did Sean Connery show up to Wimbledon? Tennish
- cyclotron3k 3y agoI would have gone with Quissh, (pronounced "quiche")
- raggi 3y agobut there are two quic quiche projects already :'''(
- NelsonMinar 3y agoWhat's the use case for this?
- bheadmaster 3y agoI think the lack of head of line blocking could be useful for SSH session multiplexing when using it as an ad hoc VPN.
- remram 3y agoIt 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.
- pfoof 3y agoApparently SSH over UDP with much less code and configuration compared to Mosh.
- trollied 3y agoLast time I installed Mosh (on Ubuntu) I just installed the package & did not need to do any configuration. It just worked.
- loxias 3y ago> 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.
- Rucadi 3y agoSince 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.
- rebolek 3y ago
- aztecrabbit 3y agoport hopping support would be awesome, like hysteria do
- ilc 3y agoThis 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.
- tankenmate 3y agoBut 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.
- mvkg 3y agoIt 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/5f5a17c3431a39a8287467d1e3efb4b0ec973822/client.go#L18 https://github.com/moul/quicssh/blob/5f5a17c3431a39a8287467d...)
- Avamander 3y agoI doubt e.g. OpenSSH would ever implement something like you describe though. They're seemingly very much against anything x509/WebPKI.
- ilc 3y agoYou 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.
- mayli 3y agoHow about mosh over quic?
- ilc 3y agoVery possible if one of the tmux replacements wants to do it. But I can see not wanting to deal with the problems this creates. :)
- Avamander 3y agoIf one could run this alongside with Wireguard and H/3 on the same port, that would be very interesting against analysis.
- zokier 3y agoIs there actually anything ssh-specific here? Seems like quic support is something that could fit something like socat pretty well?
- remram 3y agoI think so, I tried to proxy a raw TCP server and it didn't work.
- anderspitman 3y agoIt's SSH-specific only on the server side, right? The client side looks like a normal TCP tunnel (-o ProxyCommand)
- remram 3y agoIf it's SSH-specific on one side, and unpacks the protocol, it probably has to be SSH-specific on the other side.
- exabrial 3y agoAlright, 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?
- tialaramex 3y agoIt'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".
- JoshTriplett 3y ago> 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.
- mkj 3y agoThe 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.
- ggm 3y agoSurely 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?
- bvinc 3y agoHas 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?
- 1letterunixname 3y agosocat and quicat exist, so why doesn't anyone need this?
- bengl3rt 3y agoHave you succeeded at using quicat to do what this is doing?
- jesuspiece 3y agoDoes this not even build for anyone else?
- rhn_mk1 3y agoThere'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