Have you ever tried using ssh on a train? Or closed your laptop and found that all of your remote session are now frozen? Or using it via a crowded antenna tower? In all theses cases, ssh fails to work as expected.
This is due to the fact that common ssh connections are transported via TCP. As you know, TCP is unable to change IPs, nor is it able to have multiple streams (such as a control one and some data ones). TCP is not really fit to our mobile present and yet most connections use it.
A bunch of solutions exists, I’m exposing two here.
The network approach
Many improvement for the network we call Internet are in the pipeline. The most known example is IPv6, ready for deployment 30 years ago. We also need to get rid of TCP: it is inefficient and nonflexible. Here comes SCTP, the Stream Control Transmission Protocol, a way better transport. It avoids most of the issues associated with TCP.
There is support for SCTP in OpenSSH since 2003. As you know, everyone is using it now⸮
Even though it has been standardized for years, neither MacOS nor Windows support it and hardly any customer network can route it. There is of course support for it in Linux. To avoid the networking issue, you can actually wrap the SCTP stream in an UDP one, with bridging handled by the kernel.
As SCTP is a different type of socket from classical TCP, the application needs to implement support for it. It is the case in OpenSSH: you tell sshd to listen on SCTP trafic via the Transport config option. Finally, you can connect to it using ssh -z ... and enjoy a multi-homing and reliable ssh connection.
Sadly in my case, I wasn’t able to make it work. It fails with a Broken pipe signal. After more investigation, it looked like some interaction with the max number of unauthenticated connection. But I already took too long to write this article and I don’t think my boss would let me lose more time by deep-diving in the implementation. Try it on your side, tell me how it went, and push everyone to deploy and use SCTP!
The new program approach
Even though SCTP is the best fix for the issue at hand, it is not very practical with our current infrastructure. And even with SCTP, we will still have some issues with reactivity on a clogged network. To allow for a better user experience (humans..), we need a new remote shell mechanism.
Here comes mosh, a new remote shell implementation working with roaming & intermittent connections, and some other nice features. It authenticates via ssh so you can in most case use it as a drop-in replacement.
First, it needs a new transport. So it uses UDP packets instead of a TCP stream. No more unwanted retransmission. Of course with UDP, you still need a stable server IP, compared to SCTP that supports roaming of both addresses.
It also implements a synchronization mechanism rather than trying to send the whole TTY output. It improves responsiveness by dropping non-longer relevant state. For example, if you read a whole lot of logs and that some packets get dropped, mosh doesn’t care and just send the next ones, but ssh do resend everything even if it will be printed and replaced by the next page in a matter of milliseconds.
There is a last feature that is quite users friendly: local echo. When typing in ssh, your key inputs has to all the way to the server, processed and send back before showing it on screen. mosh considers that in most cases, it can simply output it first before the back-and-forth and simply validate that it correctly predicted. You can write your line, edit it and send it, all while the network is actively scrambled by the NSA party van right outside; mosh takes care that it arrives on the remote end anyway.
(very small) conclusion
use mosh for your remote shell; use ssh for data-transfer
don’t bite your fingers anymore when closing your laptop and all your remote sessions are dead
enjoy modern remote shell
—
tharvik