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