I’m with Stephen on this one. I see this reverse ssh with port forwarding used as a pretty standard support tool. The only difference I would add is that the tunnel is initiated by the user on demand and one uses the site login to authenticate for the tunnel. I expect this won’t be used on a wide scale for OVMS gear, but it is simple, useful, and widely used for hardware support. Yada, yada, S. (via the iPad thingamajigg)
On 3 Feb 2020, at 14:06, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Seeking opinions (in particular Stephen, our ssh guru).
As I (and others) are doing more work remotely (OVMS modules in cars, and trying to connect in remotely to diagnose, test, or develop), I am seeing the same issue come up often. If the car is on your own home WiFi, it is simple and easy. But if the car is elsewhere, on someone else’s WiFi, then connecting _to_ the car becomes hard. Firewalls, port forwarding, and all that mess. Security also becomes an issue (once ports are opened and forwarded).
The core requirements seem to be:
A way to get a proper shell. The ovms v2 protocol shell is ok, but quite painful to work with (especially as logs are not shown and there is no command expansion).
A way to get CAN dumps out of the car. Can save to sd card, but can’t copy in/out.
Both of these are simple TCP connections.
The second issue (CAN dumps) is resolvable if the developer has a public address. Open the firewall, ’nc -l’ a port, and ‘can log start tcpclient …’ on the module. But a little kludgy, and doesn’t support SavvyCAN (which can only connect _to_ the module, not receive a connection _from_ the module).
I can see three possible approaches to this:
Extension of OVMS v2 protocol
We could extend the OVMS v2 protocol to support a PIPE mode. Have it allow connections and data to be transferred over the v2 protocol link using simple messages. Then, the pipe could be used to tunnel SSH and CAN log connections. The same could be done with v3 over MQTT (the transport is different, but the console / port forwarding bits inside the ovms module are the same).
The advantage here is that the OVMS v2 server becomes a man-in-the-middle broker. Both the car module and the developer connect to the OVMS v2 server to exchange data. No incoming connections, so everything can be dynamic.
The disadvantage is security is fairly weak on that protocol. Very dated RC4 encryption and poor authentication.
Leverage SSH
SSH has a port forwarding facility built in, that wolfssh seems to support. It is also possible to do a reverse ssh client.
The advantage here is security (very strong encryption and authentication).
The disadvantage is complexity and the fact that the developer end needs to poke a hole in their firewall (and possibly do NAT port forwarding, etc) to allow the incoming connections from the car.
STUNNEL / WireGuard / Mosh / VPN / etc
Perhaps someone else knows of something suitable? The issues here are that the LWIP stack is not the easiest to work with.
My initial preference is #1 or #2, but open to discussion…
Regards, Mark.
P.S. To save you time, the reverse SSH (using normal Unix like systems) works like this:
Say developer at IP address A wants to connect to module at IP address B.
On the module: $ ssh -R 19999:localhost:22 <user-A>@<A> (And go through authentication for B to ssh to A)
Then, on the developer’s workstation: $ ssh -p 19999 <user-B>@localhost
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev