How to monitor SSH with Nagios Core

Remote administration depends on an SSH listener accepting connections from the monitoring network. Nagios Core can check that listener as a service on the host, so a stopped daemon, blocked firewall rule, or wrong port creates an alertable service state instead of staying hidden until the next login attempt.

The check_ssh plugin opens the SSH transport and reads the server banner without logging in. On Ubuntu and Debian package installs, the plugin is installed as /usr/lib/nagios/plugins/check_ssh, and the packaged command definitions under /etc/nagios-plugins/config/ssh.cfg include check_ssh and check_ssh_port.

A host object should already represent the server, such as web01.example.net. The service object uses the port that administrators actually use, then a clean configuration validation and a checked SSH OK result prove that Nagios Core loaded the object and can reach the listener from the monitoring server.

Steps to monitor SSH with Nagios Core:

Run check_ssh manually from the monitoring server.
```
$ sudo -u nagios /usr/lib/nagios/plugins/check_ssh -H web01.example.net -p 22
SSH OK - OpenSSH_10.2p1 (protocol 2.0) | time=0.004336s;;;0.000000;10.000000
```
The check confirms the SSH listener and banner. It does not authenticate with a user account or verify a host key fingerprint. Use the port your administrators use if sshd listens somewhere other than 22.
Related: How to run a Nagios plugin manually
Create a service object file for the existing host.
```
$ sudoedit /etc/nagios4/conf.d/web01-ssh.cfg
```
Use an existing host object when Nagios Core already monitors the server. Do not define the same host_name twice.
Related: How to add a host in Nagios Core
Add the SSH service definition.
/etc/nagios4/conf.d/web01-ssh.cfg
```
define service {
    use                     generic-service
    host_name               web01.example.net
    service_description     SSH
    check_command           check_ssh_port!22
}
```
The packaged check_ssh_port command passes the host object's address and the service argument to check_ssh. If validation reports an undefined command, add a local command definition or use the SSH command name already loaded by the installation.
Related: How to define a Nagios Core check command

Validate the Nagios Core configuration.

$ sudo nagios4 -v /etc/nagios4/nagios.cfg
Nagios Core 4.4.6
##### snipped #####
Reading configuration data...
   Read main config file okay...
   Read object config files okay...
##### snipped #####
Total Warnings: 0
Total Errors:   0

Things look okay - No serious problems were detected during the pre-flight check

Do not reload Nagios Core while Total Errors is greater than 0; an invalid service object can prevent the changed configuration from loading.

Reload Nagios Core to apply the service object.
```
$ sudo systemctl reload nagios4
```
Package installs on Ubuntu and Debian use the nagios4 unit. Use the local unit, init script, or source-install control method when Nagios Core was installed outside the package layout.
Related: How to manage the Nagios Core system service

Check the SSH service result after the next active check.

$ curl --silent --show-error 'http://monitor.example.net/nagios4/cgi-bin/statusjson.cgi?query=service&hostname=web01.example.net&servicedescription=SSH'
{
  "format_version": 0,
  "result": {
    ##### snipped #####
    "type_code": 0,
    "type_text": "Success",
    "message": ""
  },
  "data": {
    "service": {
      "host_name": "web01.example.net",
      "description": "SSH",
      "plugin_output": "SSH OK - OpenSSH_10.2p1 (protocol 2.0)",
      "perf_data": "time=0.006219s;;;0.000000;10.000000",
      "has_been_checked": true,
      "checks_enabled": true
    }
  }
}

Use the real Nagios Core URL and credentials when CGI authentication is enabled. If the service remains PENDING, force one service check or wait for the next scheduled interval.
Related: How to reschedule an active check in Nagios Core