NRPE vs. check_by_ssh

[Michael Medin]

Kevin Keane skrev:
> 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.
>   
Humm.
The cipher used is ADH which is "anonymous DH cipher suites" in addition 
to a "pre shared *known* secret" (read un-secret). Again I am no expert 
but I always interpreted the "secret key" (DH) thingy as a key and not a 
certificate but mayhap I got it all wrong? (in which case it might be 
possible to use proper certificates?)

And I am actually using openssl but mayhap it has a built-in keystore as 
well?

// Michael Medin
> 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).
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20090325/dad7f5b7/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
-------------- next part --------------
_______________________________________________
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