You are here

Restricting SSH Commands

SSH is our communication method of choice between the Opsview Monitor master server and slaves. It is pre-installed on all the operating systems we support Opsview Monitor on, providing a secure channel over which sensitive data can be transferred. 

Opsview Monitor can use SSH connections initiated by either the master server (a 'forward tunnel') or by the slaves (a 'reverse tunnel'), but there is always a risk that if the master server is compromised in some way, the attacker can then very easily take control of the slaves.

There are many tutorials on the Internet advising on ways to make SSH more secure. One method is to limit the commands that can be run when using a specific SSH key. This is done by amending the $HOME/.ssh/authorized_keys file on the "remote end" and prepending the public key with options. 

Options available include: 

  • from="pattern-list" - Will limit access to a matching remote host or IP address pattern
  • no-pty - Prevents TTY allocation to prevent login sessions from being started
  • command="/path/to/command" - The listed command will be run automatically; no other commands are possible

More details on the options are available in the documentation

For systems using reverse tunnels, the entry to add on the master is simple:

no-pty,command="/bin/false" ......

This means the ports can be tunneled correctly, but the slaves are not able to run any commands on the master server. If you don't use reverse tunnels, then security is even easier - make sure the slaves do not have SSH keys up to access the master. If you don't need the access, don't enable it! 

Forward tunnels tend to be more complicated. The master server regularly runs many different tasks on the slaves to check on their health, as well as each slave in a cluster running tasks on all the other nodes. Therefore, a wrapper script must be used to check whether the requested command can be run. The wrapper script can be downloaded here

This should be included with the forthcoming Opsview 5.3, but it can also be used on earlier versions. 

As always, care must be taken when implementing security, otherwise you may think your system is secure, but it isn't! The script should be copied to somewhere outside of /usr/local/nagios (such as the Nagios user home directory, assuming this isn't under /usr/local/nagios) as otherwise the script could be updated on the master server and sent to the slaves, removing the security the script provides.

To make use of this wrapper script, use:

no-pty,command="/path/to/restricted_slave_ssh" ...... 

Add it to the authorized_keys file on each slave.  This script logs all commands (both allowed and denied) via syslog, so you can see what machine tried to run what command (and when) on each slave.

Security is never just about implementation, it is also about review! Please check your system logs regularly to ensure you find any suspicious activity.

Get unified insight into your IT operations with Opsview Monitor

dferguson's picture
by Duncan Ferguson,
Opsview Technical Expert
Duncan has been developing, supporting and implementing Opsview for customers since 2007 (around version 2.5 onwards). He has a passion for Customer Support and is also involved with a number of open source projects.

More like this

By Opsview Team, Administrator

Opsview Monitor has many daemons running on both the Maser and Slave Node servers to allow for efficient monitoring of hosts. Some of these...

Choosing between on premises and off premises
By Opsview Team, Administrator

When choosing an Enterprise monitoring tool there are many considerations, but one that is almost always right at the top of the list is...

By Opsview Team, Administrator

Opsview Monitor is able to watch many different types of hosts, from networking devices to servers. We provide a package for many servers which...