NRPE vs. check_by_ssh

Kevin Keane subscription at kkeane.com
Wed Mar 25 20:49:03 CET 2009


Michael Medin wrote:
> Kevin Keane skrev:
>> Wouldn't the SSL certificates provide authentication comparable to 
>> SSH keys? I'm not familiar with how NRPE uses SSL, but I would assume 
>> that you could also use client certificates?
>>   
> I am no expert but AFAIK it merely encrypts the traffic ie, no 
> certificates at all. If someone knows hoe to use certificates please 
> feel free to let me know so I can add it to NSClient++ but what I have 
> seen it is not possible...
No, that wouldn't be possible. Encryption always requires some form of 
key or another. In SSL, the key is embedded in the server's certificate. 
The client certificate is optional; it also contains a second encryption 
key. If you use client certificates, in effect the traffic is doubly 
encrypted.

You almost certainly *are* using certificates in NSClient++. But if you 
are using the standard Windows API functions, Windows transparently 
hides most of that complexity from you; the MSXML object and its ilk 
take care of it. You would be using the certificates from the Internet 
Explorer key store.


Actually, when I described how the SSL connection can use single or 
double encryption, I lied. It is more complicated than that. The SSL 
keys are extremely long (1024, 2048 bits or more), and they have to be 
because by nature they don't change over years. SSL keys in the 
certificates are also the public keys of a public/private key pair. 
These factors make using the SSL key for encryption *extremely* slow. 
That is why in reality, public key encryption is only used for extremely 
short messages (measured in bytes, not kilobytes).

To work around that, the client and the server generate yet another 
random key, this time a symmetric key (which has to be kept secret from 
anybody). This symmetric key is usually 128 bits or 256 bits. Unlike 
public-key encryption, symmetric encryption can be implemented very 
fast. This key is sent using the slow public-key encryption. The actual 
traffic is then encrypted using this second key, which will be thrown 
away after the connection ends.

Incidentally, SSH works basically the same way. The only substantial 
difference is that the public keys comes from the authorized_keys file 
instead of a certificate.

Both SSL and SSH actually allow you to use various different encryption 
algorithms and mechanisms for exchanging keys under the hood. You may, 
for instance, see DHE for the key exchange, RSA for the public/private 
encryption, and AES for the symmetric encryption and SHA for hashing 
(which I haven't even touched on).

-- 
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.


------------------------------------------------------------------------------
_______________________________________________
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





More information about the Users mailing list