What are the reasons to use NRPE?

[Kevin Keane]

RijilV wrote:
> 2009/4/27 Sean Carolan <scarolan at gmail.com>:
>   
>>> I just wonder what the reasons are to use NRPE in favour of checks
>>> over ssh with ssh keys. To me, NRPE seems just one more piece of
>>> software that may potentioally be broken and more hassle with
>>> firewalls. Why do people still use it when ssh checks are just as
>>> simple and (in my opinion) far more secure?
>>>       
>> I may be in the minority here but I also prefer using ssh with keys
>> for our remote nagios checks.  We have a medium sized network, around
>> 220 hosts and about 1550 active checks.  The reports of performance
>> degradation are greatly exaggerated, IMHO.  Our average check time is
>> less than one second which is more than fast enough for our needs.  By
>> using ssh we avoided having to install NRPE on several different
>> versions of Red Hat, and as you mentioned ssh is much more secure
>> especially if you do it right (eg, password protected key, perhaps
>> with keychain for loading into ssh-agent after you boot the server
>> up).
>>
>>     
>
>
> I agree with using SSH.  If you search back through recent lists there
> was some talk of using ssh connection master which will make SSH
> greatly faster than NRPE.
>   
That can be a great approach, but it also requires that you have a 
single endpoint to the SSH connection, or just a few of them. The idea 
is that you keep the actual SSH connection established indefinitely, and 
reuse it. If you need separate SSH connections to each host, you still 
get some benefit, but it is much reduced.
> As for security...not so much.  Both (can) use the same encryption
> algorithms.  What really differs is SSH uses asymmetric encryption to
> setup the shared keys whereas with NRPE you give it the shared key
> (hence NRPE being faster, for the most part).  A shared key VS a
> certificate.... I'm not feeling a real win with either side.  In one
> case I need to grab a config file, in the other I need to grab a
> ssh-key file...
>   
Isn't the whole point of the ssh-key file that you only need to grab the 
public key? You could even publish it on a public Web site without 
compromising your security. With a shared key, a hacker that gets a hold 
of either end of the connection has compromised the connection, and you 
wouldn't even know it. If all the clients use the same shared key, a 
hacker would even compromise the whole network. With a public ssh key, 
the connection remains secure even when the SSH server is compromised 
(with NRPE, the SSH server is of course the monitored host). Only when 
the private key is stolen (which should never be on the SSH server, only 
on the client - which in this case is the single central Nagios server) 
do you have a compromise.

The second security benefit of SSH is that every time you connect, it 
uses a different shared key for the actual connection. With a shared-key 
file, you would be using the same shared key for months.

In a pinch, with SSH, you could even use the same private/public key 
pair for all monitored clients and still only moderately compromise 
security. With a shared-key file, if you use the same shared key for all 
clients, a hacker who compromises any of the machines in the network has 
full control over everything. Not what you'd want to see.
> The default to setup NRPE with explicit commands vs just allowing a
> user to run arbitrary over SSH, NRPE comes out ahead here.
SSH also has the capability to restrict what commands you can execute; 
you can specify it in the authorized_keys file on the client. In fact, I 
sometimes establish a (semi-)permanent tunnel by forwarding some ports 
via SSH, and prohibit executing any commands on the remote end.

Here is a line from the authorized-key that I use to lock down on one of 
my servers to only allow forwarding a few ports (in this case, for mysql 
and LDAP), and not execute any commands at all.
> from="<private 
> IP>",no-X11-forwarding,no-pty,permitopen="localhost:3306",permitopen="localhost:389",command="/bin/true" 
> ssh-rsa <actual public key goes here)
> But its not really any harder to setup SSH so each key corresponds to a particular check.
The problem with that is both performance and maintenance. In Sean's 
example, you have 220 hosts and 1550 active checks. That means managing 
either 220 key pairs (or if you aren't too concerned, you can get away 
with a single key pair), or 1550 key pairs if you use one for each 
check. You also defeat the master-connection approach suggested earlier.
> And you can setup NRPE to allow you to execute any
> command, which defeats the initial security you gain by limiting which
> commands it can run.
>
> As for having passwords on your keys and loading up a
> ssh-agent...pffft.
Agreed on that. Just leave the private keys without a passphrase and 
store them in a well-protected location. The agent would defeat the 
whole point of having a passphrase on the key anyway, AND, as you point 
out, make it available through a well-documented interface in RAM. And 
it makes rebooting the server problematic to boot, since somebody has to 
type in all the passphrases. With 220 private keys, that's a lot of work 
(and you DON'T want to use the same passphrase for each key. That would 
defeat most of the benefits).

Incidentally, it is also not trivial (and a very bad idea) to make an 
ssh-agent work with a daemon. For security reasons, the agent only 
allows you to store keys for the current logon session.

Finally, I'm not sure how well the ssh-agent would do in terms of 
performance with hundreds or thousands of keys loaded.

-- 
Kevin Keane
Owner
The NetTech
Find the Uncommon: Expert Solutions for a Network You Never Have to Think About

Office: 866-642-7116
http://www.4nettech.com

This e-mail and attachments, if any, may contain confidential and/or proprietary information. Please be advised that the unauthorized use or disclosure of the information is strictly prohibited. The information herein is intended only for use by the intended recipient(s) named above. If you have received this transmission in error, please notify the sender immediately and permanently delete the e-mail and any copies, printouts or attachments thereof.


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null