Opsview Monitor has the capability of a more secure method of communication between the Opsview Agent and its Unix clients. Previous versions were limited to using relatively weak ADH-based ciphers, but now it's possible to use SSL certificates. These offer not only a stronger encryption method, but also authentication, so both the client and server know that they are indeed talking to each other, and not a man-in-the-middle. Please take a moment to read the [PKI documentation](🔗) before continuing with the below.
Whatever method of communication you choose, both the Opsview Agent server and clients (check_nrpe) must be told to use the same method: ciphers directly, or SSL certificates. The Opsview Agent server configuration is in `
/opt/opsview/agent/etc/nrpe.cfg` (on Windows in `
C:/Program Files/Opsview Agent/opsview.ini`), and the clients are configured by command line parameters.
## Host Variables
We have added default parameters to every Service Check that comes with Opsview Monitor. If you check their definitions, you'll see two new Host variables - `
NRPE_CIPHERS` and `
NRPE_CERTIFICATES` - discussed below. Note that you'll have to add these variables yourself if you're upgrading from an older version of Opsview Monitor. To do this add these two variables:
Label Arg1: Cipher list
Default Arg1: ADH-AES256-SHA:ADH-AES128-SHA
Label Arg1: Path to certificate
Label Arg2: Path to private key
Label Arg3: Path to CA certificate
For each check_nrpe based service check that is to be used with the new feature, add these parameters:
In nrpe.cfg, `
ciphers` (on Windows in opsview.ini it is `
allowed_ciphers`) indicates the cipher list to use. Because there is no authentication involved in using a cipher directly like this, only ADH ciphers can be used here. The list follows the standard OpenSSL convention of colon-separated names, where the program attempts to use each cipher starting from the left, and falls back to the next one if unsuccessful. Similarly, the `
-y` parameter to check_nrpe lists ciphers that the client should attempt to use, which, of course, must contain at least one of the ciphers that the server is using.
Each check_nrpe based Service Check is configured to accept the NRPE_CIPHERS host variable. Make sure the value of this variable is the same or contains at least one of the ciphers configured in nrpe.cfg.
## SSL Certificates
In nrpe.cfg, `
privatekey`, and `
cacert_file` (opsview.ini uses `
certificate_key` and `
ca`) are file paths to a certificate PEM file. The first value, Arg1, is the path to the certificate on the Collector, Arg2 is the path to the private key and Arg3 is the CA certificate. These parameters correspond to the `
-r` parameters of the check_nrpe plugin.
The generation and use of the actual certificates is the User's responsibility - please refer to the [PKI documentation](🔗). The automated installer should create the required certificates for the Orchestrator. In a single server system (assuming the FQDN of the orchestrator is `
opsview.example.com`), the following settings should be used:
Arg 1: HIGH:!3DES:!CAMELLIA:!AES128:!aNULL:!eNULL:!ADH:!EXP:!LOW:!DES:!MD5:!PSK:!SRP:!DSS _(note: to match configuration of the Opsview agent)_
pki` to create a `
and transfer the following files to that server (NOTE: `
agent-machine.example.com` should match exactly the `
Primary Hostname/IP` configured in Opsview Monitor for the server)
On the `
agent-machine.example.com` host, edit nrpe.cfg (or `
custom.ini` on Windows), uncomment and change `
ciphers` to match the definition used within `
NRPE_CIPHERS`, and `
privatekey`, and `
cacert_file` options to point to their respective pem files. Then, restart the agent.
On Collectors that will be doing the monitoring, each check_nrpe based service check is configured to accept the NRPE_CERTIFICATES variable. The values for this variable refer to the certificate files for the Collector, and not the Host being monitored, as is the case usually with Host variables.