Is this a new Bug?

[X] I checked that the bug hasn't been reported before

Package Name

mosh

Package Version

1.4.0-4

Device Model

DS218play

Device Architecture

AArch64 (ARMv8)

Firmware Version

DSM 7.2.1-69057 Update 5 and DSM 7.2.2

What happened?

It was unclear how to connect to mosh running on the Synology NAS when connecting via macOS (Big Sur) or Debian/Ubuntu Linux.

There are two or three tricks to make it work, which might be placed in the documentation for future users.

Reproduction steps

This is not a bug report!

... but just a suggestion for adding some more documentation 📖

Rationale

I'm not a mosh "expert", but I can assume that others might not be experts either, and a little bit of extra information might help!

The issue

I lost access to my NAS via ssh. The error is cryptic (it refuses to accept any keys whatsoever) and I remember having encountered it before on other systems, but I really need to read the logs first. A reboot does not restore the situation. Neither does the activation or deactivation of the sshd daemon (via Control Panel). Needless to say, telnet access doesn't work either.

That means an effective lockout from the NAS. The solution? Well, there are a few, but mosh is clearly one of the best (given that packages such as GateOne have been discontinued and are unavailable for DSM 7+).

Usage

For the majority of use cases, mosh just needs to be installed from the SynoCommunity repo, and then, from the local computer's command line, just run mosh user@myNAS-IP. That's it, mosh should deal with any issues that occur. Since it's so easy, no further documentation is (usually) needed.

However, there are three (possible) issues:

Different locale settings between the client and the server will hopelessly confuse mosh.
mosh may not be able to find the correct remote command to run (e.g., /usr/local/bin/mosh)
UDP ports 60000-61000 must be allowed to send traffic in both directions (to and from the Synology NAS), and that has to be set up on all intervening firewalls, starting with the Synology NAS.

Any of the above will give a cryptic error saying that mosh failed to start a remote session, or eventually it starts doing something but times out silently (which is more often the case with blocked ports).

You can disregard 1. if you're sure that both client & server have the same locale (I'm assuming that's precisely what happens in 90% of all scenarios).

What is described under 2. is even more cryptic. Allegedly, this Synology package has installed mosh, mosh-client, and mosh-server, all with the proper symlinks from /usr/local/bin, which is where mosh is supposed to search for its server counterpart; but, for some reason, it doesn't (possibly because /usr/local/bin is not in the default path, I just add it when bash starts, i.e. under my user's .bashrc).

Thus, to ensure that I covered both of the points above, I run:

$ LC_ALL=en_US.UTF-8 mosh myHomeIP.synology.me --server=/usr/local/bin/mosh-server

where en_US.UTF-8 is the locale your Synology NAS is set to (run locale on your NAS's prompt to confirm).

Note that if you're using mosh from your home network, you'll need to use the private IP address of your NAS instead.

The last point (opening UDP ports 60000-61000) should be obvious or trivial for anyone familiar with how mosh selects its ports to communicate. This package doesn't change the firewall automatically; if you're strictly connecting from your home network, you might not need to change anything (I didn't), but if you connect from the "world outside" (as you did/do with SSH), then you'll need to add those ranges of UDP ports on all firewalls between your NAS and your remote machine; again, that's obvious and trivial for those who are used to do that for all possible communication protocols, but it's always worth mentioning it first.

Note that you can change the range, or even restrict it to a single UDP port, if you wish. But you must have at least one! The reason for having a range is two-fold: first, ranges might be shared between different services (it's possible) and this avoids a collision with packets from different applications; and second, for anyone attempting to illegally intercept traffic sent/received via mosh, it's much harder to simultaneously monitor thousand different ports instead of just one. See the mosh instructions for more.

It might also be worth mentioning that mosh is not a full replacement for SSH; see https://mosh.org to learn about what mosh can do and what its limitations are.

But it certainly avoided having a 'bricked' Synology NAS to which I couldn't connect 🙂 (Ironically the moment mosh authenticated my user, SSH started working again. Weird. Or maybe there was a hiccup on the authentication system — weird again — which somehow mosh 'fixed'...? I don't really get it, but at least the next time I won't be stressing so much about the lack of connectivity via SSH...)

Install Log

N/A

Service Log

N/A

Other Logs

N/A

SynoCommunity / spksrc

[Documentation Suggestion] For a beginner, it's non-trivial to figure out how mosh works. Here are some suggestions. (not a bug) #6219