Teleport the xymon server to a remote-site

The great Xymon-addon ssh-tunnel written by Padraig Lennon allows for managing ssh port-forwardings (aka: ssh tunnels) from the Xymon server in a pretty flexible way.

The xymon communication with remote sites that are (only) reachable by ssh and cannot themselves contact the Xymon server (remote-datacenter, DMZ, …) then happens through that tunnel.

For that to work the Xymon server port tcp/1984 is forwarded to the client. The client in turn is configured to report to localhost:1984 — sending the data through the ssh-tunnel to the Xymon servers port 1984.

In contrast to using pulldata on the server and msgcache on the client (see hosts.cfg(5) and msgcache(8)) this has several advantages:

  • data is transmitted in encrypted form and not in clear/plaintext
  • ssh allows to compress the data (massively reducing the consumed bandwidth)
  • no additional open port 1984 of msgcache on the clients
  • potentially more resource friendly
  • no added (well: at least reduced) latency for the client-data to show up
  • the Xymon server does not need to become an active player pulling data but can remain passive in the communication

Monitoring many single hosts with this technique may lead to other problems on the Xymon server though: Many ssh processes, consuming a lot of resources (ports, memory, cpu) and a “messy” central monitoring server.

Monitoring a larger remote location, e.g. a complete datacenter, only requires one ssh-tunnel to be established.
For this to work

  • have a tunnel to host.remote.tld opening 1984 on it’s public/private interface

  • have all clients report to host.remote.tld:1984

This requires a bit of extra ssh-cofiguration on the remote server (check ssh(1) for the -R-option and sshd_config(5) for GatewayPorts for more details).

A follow-up post will describe how to avoid the sshd-reconfiguration.

Where to go from here?

The project page of (the patched) ssh-tunnel contains detailed documentation and a link to the original project page on