NRPE/NSCA replacement thoughts?

[Kevin Keane]

> -----Original Message-----
> From: Flyinvap [mailto:flyinvap at orange.fr]
> 
> > With SNMP, there is no way to do that - you basically can't wrap UDP
> > in any way. With NRPE, you can easily implement all kinds of
> > homegrown solutions already: ssh tunnels, HTTPS.
> 
> You can use SNMP on TCP. You can even use SNMP on SSH or DTLS [1].

I am risking the life of an innocent equine by flogging when I respond...

I know, but it's really an unusual configuration (I was going to say "nonstandard" but technically speaking it is in the RFC).

> net-snmp [2] can do that without implementing SSL tunnel or other kind
> of solution. With SNMP v3, you can use authentication and encryption.

It seems to me that SNMP v3 is not even in the running due to performance concerns; pretty much everybody in this discussion seems to have agreed on that point (and for me also, because of a lack of support by vendors; Microsoft, in particular).

> I'm not saying SNMP is a good solution but provides all security
> needed.
> 
> Finally, SSH is cloud be the best way to execute remote plugins.

Personally, I'm not sure if there is a single "best way". That is why I keep promoting separating the protocol from the transport. Basically, Nagios protocol data fits into Layer 6 or 7 of the OSI model, while the encryption and authentication really should be handled by layer 4 or 5.

SSH really is a good way, but in many scenarios HTTPS may be even better.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
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