In this recipe, we'll learn how to deal with the common situation of a machine running an SSH daemon that is running on an alternative port; in this case, a service definition that uses check_ssh as used in the recipe Monitoring SSH for any host fails, because the plugin defaults to using the standard SSH TCP port number 22.
This kind of setup is common in situations where an SSH server should not be open to the general public and is often employed as a "security by obscurity" method to reduce automated attacks against the server. The SSH daemon is, therefore, configured to listen on a different port, usually with a much higher number, and the administrators who need to use it are told what the port number is.
We'll deal with this situation and monitor the service in Nagios Core, even though it's running on a non-standard port. We'll do this by defining a new command that checks SSH on a specified port number and creating a service definition that uses that command. The command will accept the port number to check as an argument.
The principles here should generalize well to any other situation where checking an alternative port is necessary and the Nagios Core plugin being used to make the check supports doing so on an alternative port.
You should have a Nagios Core 4.0 or newer server with at least one host configured already. We'll use the example of troy.example.net, a host defined in its own file and listening on the non-standard SSH port 5022. You should also understand the basics of how hosts and services relate, which is covered in the recipes in Chapter 1, Understanding Hosts, Services, and Contacts.
A good first step may be to verify that we're able to access the SSH daemon from the monitoring server on the specified port. We can do this from the command line using the ssh client, specifying the port number with the -p option:
$ ssh troy.example.net -p 5022
Alternatively, you can run the check_ssh plugin directly from the command line:
# sudo -s -u nagios $ /usr/local/nagios/libexec/check_ssh -p 5022 troy.example.net
We can set up a service check for SSH on a non-standard port as follows:
- Change to the objects configuration directory for Nagios Core. The default is
/usr/local/nagios/etc/objects. If you've put the definition for your host in a different file, move to that directory instead.# cd /usr/local/nagios/etc/objects - Edit a suitable file containing command definitions and find the definition for the
check_sshcommand. In the default installation, this file iscommands.cfg. Thecheck_sshdefinition looks something like this:define command { command_name check_ssh command_line $USER1$/check_ssh $ARG1$ $HOSTADDRESS$ }
- Beneath the
check_sshdefinition, add a new command definition as follows:define command { command_name check_ssh_altport command_line $USER1$/check_ssh -p $ARG1$ $HOSTADDRESS$ }
- Edit the file containing the definition for the host. The host definition might look something like this:
define host { use linux-server host_name troy.example.net alias troy address 192.0.2.25 }
- Beneath the definition for the host, place a new service definition using our new command:
define service { use generic-service host_name troy.example.net service_description SSH_5022 check_command check_ssh_altport!5022 }
- Validate the configuration and restart the Nagios Core server:
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg # /etc/init.d/nagios reload
With this done, Nagios Core will begin running service checks using the check_ssh plugin, but will use the alternative destination port 5022 for its connection attempts for the service with the description SSH_5022.
The preceding configuration has almost exactly the same end result as adding a default check_ssh service; the only difference is that a different port is checked in order to make the connection. We use the command check_ssh_altport to do this, which we also defined ourselves in a syntax very similar to the check_ssh definition.
The difference is that the command accepts an argument, which is used as a value for the -p option to the check_ssh plugin, to check the specified port number—in this case, TCP port 5022, rather than the default port 22.
Because arguments in Nagios Core can include spaces, we could also have defined the service check as follows, without having to define an extra command:
define service {
use generic-service
host_name troy.example.net
service_description SSH_5022
check_command check_ssh!-p 5022
}This is because the $ARG1$ macro representing the argument is still used in the original check_ssh command, but it needs to have the option as well as its value included. The difference is mainly one of preference, depending on which we feel is clearer and more maintainable. It may help to consider whether a well-named command could assist someone else reading our configuration to understand what is meant.