Case study
Remote diagnostics over SSH
Our onboard units run a local web interface for diagnostics. Getting to it usually meant being on site. I wrote a Python tool that goes through our existing SSH jump host, so an engineer can open that interface from their own desk. The vehicle never gets a new inbound service.
The setup
The onboard platform serves a local web page for diagnostics and maintenance. When something needed checking, the easy option was to connect to the vehicle and open that page directly. It works, but it turns a software question into a road trip.
Putting that interface on the internet was out of the question. So I took the access path we already had and made it work from a normal engineering workstation.
The problem
The engineer needs a browser session against a service that only exists inside the vehicle's network. The route has to go through an authenticated jump host. And the session has to be easy to start, easy to stop, and clear about what it's doing.
A public endpoint on every vehicle would fix the browser side and open a much bigger security hole. I didn't want that trade.
Use the door that's already there. Don't cut a new one.
How it works
The tool opens an SSH connection through the jump host and forwards a local address to the onboard web interface. The engineer opens that address in a browser, and the traffic goes through the authenticated SSH session.
The tool handles the whole session. It shows progress while it connects, tells you when something fails, and closes the forwarded path when you're done. The browser sees a normal local service. The vehicle sees a normal SSH client.
What I built
- A Python command-line tool to start and stop the forwarded session.
- An SSH jump path that reuses the access we already had.
- A local browser address mapped to the onboard web interface.
- Status and error messages the operator can act on.
- Cleanup, so the forwarded path doesn't outlive the job.
Design choices
Go through the jump host
The jump host is already the controlled way in. Going through it keeps access auditable, and the vehicle gets no new listener.
Forward locally
The forwarded address only exists on the engineer's machine. The onboard interface never goes on the open internet.
Say what's happening
A session that fails silently is worse than one that won't start. The tool tells you what it's connecting to and when the path is ready.
Clean up after
Stopping the tool tears down the forwarding. You switch remote access on for a job and off again, so there's no background service left running that everyone forgot about.
The result
It cut travel and intervention costs a lot, because an engineer can now look at a vehicle with no technician on site.
It's a small tool, but it touches Linux access, process and session management, local services for the browser, and equipment that's never on your desk. And it keeps exposure as narrow as the job allows.