HOWTO Setup NRPE: Difference between revisions
New page: == Purpose == SSH (The Secure Shell) is arguably the '''best''' way to access your data, over a network connection. The communication is encrypted, and a number of other services can run... |
|||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== Purpose == | == Purpose == | ||
NRPE (Nagios Remote Plug-Ins Executo) is how Nagios checks services on remote hosts. The communication is encrypted, and the commands are limited to a small number of "Plugins" which are installed on each host. These plugins report back information about the host to the main Nagios service, which displays them | |||
== Installation == | == Installation == | ||
Under Gentoo: | Under Gentoo: | ||
<font color=red>hostname</font> <font color=blue>~ #</font> '''emerge -pv net- | <font color=red>hostname</font> <font color=blue>~ #</font> '''emerge -pv net-analyzer/nagios-nrpe''' | ||
== Configure == | == Configure == |
Latest revision as of 01:24, 5 May 2009
Purpose
NRPE (Nagios Remote Plug-Ins Executo) is how Nagios checks services on remote hosts. The communication is encrypted, and the commands are limited to a small number of "Plugins" which are installed on each host. These plugins report back information about the host to the main Nagios service, which displays them
Installation
Under Gentoo:
hostname ~ # emerge -pv net-analyzer/nagios-nrpe
Configure
The main configuration file for an SSH server is /etc/ssh/sshd_config.
User Control
Adding the AllowUsers Directive is nearly a necessity, and implies that all other unspecified users are Denied.
AllowUsers nx gordp mdeepwel
(the user nx allows for the use of NoMachine's NXServer / NXClient remote desktop)
Conversely, there may be times when we want our entire LDAP-user-list to have access, except for a select few usernames then we use the DenyUsers directive:
DenyUsers grinch scrooge cindy_lou_who DenyUsers administrator bob sfuresearchstats
If the box is ldap enabled, please deny administrator, bob, and sfuresearchstats. You could also consider the directives AllowGroups or DenyGroups, if groups were suitably set up (which ours are not).
SSH Daemon Control
Typically, you will want the SSH daemon to start at boot, and run whenever your computer is turned on. Under Gentoo:
hostname ~ # rc-update add sshd default * sshd added to runlevel default
You can manually stop, start, or restart the SSH daemon with this syntax (Gentoo):
hostname ~ # /etc/init.d/sshd stop hostname ~ # /etc/init.d/sshd start hostname ~ # /etc/init.d/sshd restart (use this to effect changes; will maintain an existing connection)
Additional Security
The addition of a firewall, or tcpwrappers can add considerable security! Use them!
Usage
Graphical tools exist for use with just about every OS, making such tasks as drag-and-drop file-transfer both easy and secure! Use this rather than FTP, wherever possible.
Problems
- By far, the most-common difficulty encountered is that a host's RSA key has changed, and you are denied access. This can be quite opaque when using a GUI client like Fugu. The cure is to edit your ~/.ssh/known_hosts file, and remove the offending key. If this means nothing to you :-) then perhaps it's easiest to entirely delete your ~/.ssh/known_hosts and begin collecting keys all over again.
- For those who connect to a number of different machines behind the same IP address (this happens with a NAT firewall, and multiple machines behind it), you can hand-edit your ~/.ssh/known_hosts file and add multiple public RSA keys for the same IP address. Here is an example of multiple keys, for different machines behind a single IP-address:
70.70.130.1 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAy9L56BD2+70YA97DzdBY0GGuDMHwPn1BUdByPBmOVLxPTdOtcbXLGHpV2IoYeiej0TAngAtzn4tUv2HZJS4y3OKnVq+nvHU3AtZm26oSaiHEDq6ilLX/AtA7lgi+keZSPASDTYA2M34nv6lsFpT3AFugTreKlkdORXDoamlW8Ds= 70.70.130.1 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAzVZj8PTtTQVAsbPs8s61YHT4CPQj73yiIEhh6FrAJOzRZSexaXGDO9R2cKCNYvIaXUnbI6QXhp2CNAofpKkLkqGOUiMQI2qkf/TdHAi2kgB33m0Tghy/Gf3CCS+YAh0z0oFzLQz93aSCsuKRYgKDAriDpzy9ZAsKpKXzn6VsW2k= 70.70.130.1 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAuxvwzkYpj3U3uNB/ZzTT0fxbzc+1xXApDf67iY0sfqn+pKx+r8mu2bRylflzH7DUDkmJmLoj5vXfgU1wHrfdjLnabMwhJO2B0kWi/kij0NuEp1O2PZgTNTAmsyju+i64ug82Urp9WO882gbLX7GAE9I0D54PfhncyVnhb6rT1mU=
Generally, you copy these entries from the intended target machine, using any number of means to get the key transferred. For example, you can easily set up and accept the key from your first machine, then use that computer to connect to the second machine (all behind your NAT firewall), then easily copy the public RSA key, which then would allow direct-connection to the second box). The file you need to copy is typically /etc/ssh/ssh_host_rsa_key.pub, with a bit of trimming after the = sign.