I’ve been using Resin.io for a recent project that is using a 3G USB modem to connect to the internet, and in testing I’ve noticed that SSH isn’t particularly responsive on slow connections like this. Even worse, when deployed my project will likely have a more flaky/inconsistent connection.
With that in mind, I’m curious if anyone has managed to get something like https://mosh.org/ working with Resin (if it’s even possible?), or if anyone on the Resin team has looked in to adding it as an option instead of SSH for remote access into devices. It seems like a great fit considering that Resin enables projects that are often using cellular connections.
I’d love to hear anyone’s thoughts/opinions on the matter, and if you have tips for improving/dealing with SSH over a cellular connection I’m all ears.
Hey Alex, we’ve had a couple people ask about Mosh, including those (such as yourself) who are using cellular. We’ve opened up an issue to explore it further and will let you know what we come up with.
Even without a cellular connection, the ability of mosh to gracefully handle disconnects is really handy.
I tried using it with the resin public URL, but doesn’t work.
on device
$ mosh-server new
MOSH CONNECT 60001 KuWWx7LXjE11KZpY8JO8vA
mosh-server (mosh 1.3.2) [build mosh 1.3.2]
Copyright 2012 Keith Winstein <mosh-devel@mit.edu>
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[mosh-server detached, pid = 400]
on desktop
$ mosh root@<device hash>.resindevice.io
root@<device hash>.resindevice.io: Permission denied (publickey).
/usr/bin/mosh: Did not find mosh server startup message. (Have you installed mosh on your server?)
nmap output
$ sudo nmap -sU -p 6001 d75c7b13cb5c8cdda9814eaa547e04f1.resindevice.io
Starting Nmap 7.70 ( https://nmap.org ) at 2018-08-08 13:47 IST
Nmap scan report for d75c7b13cb5c8cdda9814eaa547e04f1.resindevice.io (52.72.143.113)
Host is up (0.29s latency).
Other addresses for d75c7b13cb5c8cdda9814eaa547e04f1.resindevice.io (not scanned): 34.237.177.154
rDNS record for 52.72.143.113: ec2-52-72-143-113.compute-1.amazonaws.com
PORT STATE SERVICE
6001/udp open|filtered X11:1
Nmap done: 1 IP address (1 host up) scanned in 16.40 seconds
Hi @devxpy our team hasn’t had a chance to look into this yet, but I know there’s interest in exploring mosh, when time allows I’ve pinged a couple of people on the team to see if they might be able to take a closer look during a hack Friday soon.
Is it possible to expand on the proof-of-concept? I’m not entirely clear on where the IP addresses are coming from. I am using ngrok, but do not understand if this is assuming that the device and desktop are on the same network or can be on different networks.
It is also not clear if the tunnel can be setup automatically, or requires commands to be executed, when we desire to use mosh, on both the the device and desktop each and every time.
Our motivation is when working with network connections that often fail, preventing one in five ssh connections to the device from succeeding.
Mosh is based on UDP, which makes it difficult to tunnel.
The current PoC works like this:
We use ngrok to make the device reachable via TCP over the internet, so the device and the desktop do not have to be on the same network.
Through this ngrok tunnel we open an ssh connection to the device and use ssh tunnel forwarding, to expose a virtual network p2p connection between the device and the desktop computer. We use this virtual network connection to send UDP packets to the mosh server running on the device.
I’m not a 100% sure if this setup would work for your use case, but these are my thoughts:
The whole setup can probably be automated, and for your use case it has too. The current setup uses two underlying TCP connections (ngrok, ssh), when network connections fail a lot, these two TCP connections will also fail and an automated system would need to recreate these connections on the fly. The advantage of mosh like this is that mosh would be able to keep the current session open, because it is UDP based, there might be lags, when the underlying connections have to be recreated. This would give you the benefit of a continuous shell session, but you can also keep you current shell session, solely with ssh, with a tool like screen.
The other option would be to make a VPN connection:
We don’t grant direct access to the device via our VPN, but this does not mean, that you cannot put an openvpn client into your application as well and connect to you own openvpn server. If you make this vpn connection UDP based, you can directly connect to a mosh server listening on the VPN interface. Since both network connection would be UDP based, these are more robust against network failures, but this option would require you to operate an openvpn server.
I’ve pinged a couple of people on the team to see if they might be able to take a closer look during a hack Friday soon.