Recording environmental data is one of my hobbies; I already reported about my magnificent dust sensor [1]. I also own a small weather station: the popular WH1080, which is sold under names like Fine Offset, Nextrend, Froggit, or TFA Nexus. It includes various external sensors, as well as an indoor base station.

I continually extract the measurement data via the USB port of the base system – any Linux machine would be capable of it, but my old Raspberry Pi 2B is the perfect choice. I use RRDtool to write the data to a round-robin database and conjure up colorful graphs for a web server (Figure 1.)

Figure 1: Charly's Raspberry Pi server records the weather station data with RRDtool.

I had to come up with something to publish the data on the web. My ISP uses Dual-Stack Lite [2] and doesn't even offer static IPs for an extra charge – and, I have an aversion to dynamic DNS services.

A reverse SSH tunnel should fix it. The Raspberry Pi opens a connection from the inside through the NAT to a server outside, which I rented for a little money. (Performance doesn't matter; it's all about having a static IP address.) This SSH connection creates a direct tunnel between port 80 of the web server and port 80 of the Raspberry Pi. This was fine as a proof of concept; later, I converted it to HTTPS with a certificate from Let's Encrypt.

The syntax for tunneling is simple. On the Raspberry Pi, you enter:

ssh -R <Webserver>:80:localhost:80<User>@<Webserver>

The tunnel is set up; I access the web server and see Connection refused. So what went wrong? After five minutes with a search engine that I really don't trust, I found this out: On the server, I have to add a GatewayPorts clientspecified line to /etc/ssh/sshd_config. Without this, the port is only bound to localhost.

Not Enough Action in the Tunnel

Unfortunately SSH disconnects after a period of inaction; because my weather server is not quite as popular as the one run by the Met Office, this happens quite soon. I can set the timeouts, but sooner or later the tunnel always breaks down, and it does not reopen. I succeeded in eliminating this annoyance with autossh [3]. The tool monitors the connection and restarts crashed tunnels. The syntax for doing this is:

autossh -M 9999 -N -R <Webserver>:80:localhost:80 <User>@<Webserver>

The -M switch is the monitoring connection. I chose the port number arbitrarily; it and the next one (i.e., 10000) both need to be free.

Caution: The machine (here, the Raspberry Pi) must not have access to the internal LAN at the same time, because if an attacker took over, they would be handed my entire home network on a silver platter. In my environment, the Raspberry Pi is connected to special DMZ ports on the firewall, which isolates it from the LAN. So let's see: 21°C – time to go out into the garden and see if the watering Raspberry Pi is doing its job properly.