Running Mathematica on a Remote Machine (using frontend and ssh)

Question

I've been trying to run my Mathematica code on a remote machine. I'm using Windows and the remote machine is a Linux machine. I write a notebook on my local machine, convert it to a .m file, and use WinSCP to put it onto the remote machine.

I attempted to connect to the remote machine through the front end (https://reference.wolfram.com/language/howto/ConnectToARemoteKernel.html) but got the error: The kernel failed to connect to the front end. (Error = MLECONNECT). You should try running the kernel connection outside the front end.

So I then decided to ssh onto the remote machine and run code through the command line. However, none of my .m files would run. There'd be no error, but there'd be no output either. I decided to try the following answer, where I create a shell script: remote kernel through SSH

But it fails with Exit Code 65280, alongside the following error: Bad port 'w'

I'm really quite lost as to what the issue is. I've turned off my firewall to no avail. And if I write a Mathematica script on the machine and run it, it works. I attempted to establish a VPN connection with the remote machine but then got the error: The remote connection was not made because the attempted VPN tunnels failed. Are there basic checks that I should be doing?

I'd be hugely grateful for any help.

Answer 1

I just wanted to post a comment but I don't have enough reputation. I have been discussing this topic in a Wolfram Community post. I shared there my working solution (for the moment, I want to test it more extensively) which relies on setting up a local VPN server and connecting the remote machine to it.

---

Update

As suggested by Artes in the comments, I will provide here a few details about the solution that's discussed in the community post linked above.

The solution I'm going to describe relies on the possibility of either

1. installing & configuring a VPN local server (e.g., on your router)
2. installing a custom firmware on your router that enables the VPN server support.

I would say that it might also be possible to set up the server elsewhere on the local LAN (for example, on a Raspberry Pi), but I did not test such solution and I guess that the overall configuration might differ a bit, without considering the bottleneck arising from an additional device operating in the middle.

I am not able to give detailed guide on how to setup the VPN server since it depends on the hardware you have. Yet, there is a very thorough article which explains the procedure of installing and configuring a VPN server on your router, including the installation of a custom firmware (if your router supports it).

That being said, the procedure boils down to three steps:

1. Setting up the VPN server: installing the OpenVPN packages and creating the certificates and keys for both the server and the client(s)
2. Putting together an OpenVPN configuration profile (a profile.ovpn file) for your client. Once your server is configured, it provides you with a generic profile to which you have to add the certificate and key that you created in step 1. You will also have to create at least a pair of user credentials (username/password) for your client: this can be done once again during the server configuration.
3. Installing the VPN client on your remote machine and connecting to the server. Normally connecting is as simple as issuing a openvpn --config profile.ovpn on your server.

One caveat is the following: if you are connected to your server through SSH, then it's very likely that your connection will drop. The reason is that the OpenVPN server will change the default gateway on the server: the route from your local machine to the server remains unchanged, but the traffic from the server to the local machine now goes through the VPN gateway. This is a shortened explanation: I don't think it's the right place to explain the networking details that you can find, for example, here. Yet, there is a quick solution to this problem. Before starting up the VPN client, tell the server not to route all the traffic through the VPN but through the previous gateway with something like route add -host <public IP local machine> gw <default gateway server>.

The previous solution relies on having a static public IP associated to your local internet connection. If that's not the case, then a way to deal with it and simultaneously making your VPN server always reachable is using a Dynamic DNS service.

Once all is set on the VPN side – server running and remote machine connected – then your remote machine will have a new IP address in the subnet created by the VPN server. That's the address you should use in the "Kernel configuration" profile in Wolfram Mathematica/Desktop. On my local machine (either macOS or an Ubuntu laptop with Wolfram Desktop 12.1), I'm using system's SSH to establish the connection. Here is, for example, another answer that shows how to do it.

As a closing remark, a colleague of mine pointed out this handy program written in Python called sshuttle that could be a working alternative that's much less elaborate to set up than a full-blown OpenVPN server. I want to try it as well but I haven't yet.

I hope these additional details make the answer more useful.