AW: [BUG] check_nrpe fails, SSL handshake error
Michael Tucker
mtucker at airmail.net
Wed Jan 7 21:45:12 CET 2004
Good idea. Done.
Ethan, to bring you up to speed: there appears to be a bug in
check_nrpe/nrpe, something to do with its implementation of OpenSSL. I
apologize for the length of this message; it might be easier for you to
follow if you go back and follow the thread from the beginning. But
there's quiet a bit of information here. Hopefully some of it will
prove helpful to you.
Here's the short form of the problem:
> check_nrpe -> nrpe fails if SSL is enabled, and returns the message:
>> # ./check_nrpe -H {host to monitor} -c check_load
>> CHECK_NRPE: Error - Could not complete SSL handshake.
>
> If SSL is disabled (recompile with --disable-ssl), it works just fine.
Michael
On Wednesday, January 7, 2004, at 02:05 PM, Richard Mayhew wrote:
> Hi
>
> Not to mention Fedora Core 1, which is also having the problem which
> brought
> about the rediscussion of this problem.
>
> If there is any extra info needed, please let me know.... maybe we
> should CC
> Ethan on this?
>
> ----- Original Message -----
> From: "Michael Tucker" <mtucker at airmail.net>
> To: "Maurer Roland MKG-Bank" <R.Maurer at MKG-BANK.DE>
> Cc: <nagios-users at lists.sourceforge.net>
> Sent: Wednesday, January 07, 2004 8:52 PM
> Subject: Re: AW: [Nagios-users] [BUG] check_nrpe fails, SSL handshake
> error
>
>
>
> On Wednesday, January 7, 2004, at 08:55 AM, Maurer Roland MKG-Bank
> wrote:
>
>> Have find out what is working wrong. I have the same problem by using
>> SUSE
>> 9.
>>
>> Roland Maurer
>>
>
> I presume that you meant "Have you found out...?" (I'm not picking on
> your English. I'm sure that it's better than my German.)
>
> No, I have not. I am still looking for an answer to this problem. Has
> anyone else found a solution?
>
> To reiterate some points that have been made in other threads:
>
> check_nrpe -> nrpe fails if SSL is enabled, and returns the message:
>> # ./check_nrpe -H {host to monitor} -c check_load
>> CHECK_NRPE: Error - Could not complete SSL handshake.
>
> If SSL is disabled (recompile with --disable-ssl), it works just fine.
>
> So far, we've had users report this error using Solaris 9 (me), AIX 5.1
> (Chris Stevens), and SUSE 9 (you). I am now inclined to believe that
> this is a bug in NRPE 2.0, or in its implementation of OpenSSL;
> specifically, the call to SSL_connect (), and the setup calls which
> lead up to it:
>
> ----- begin code segment from check_nrpe.c -----
> /* do SSL handshake */
> if (result==STATE_OK && use_ssl==TRUE){
> if((ssl=SSL_new(ctx))!=NULL){
> SSL_CTX_set_cipher_list(ctx,"ADH");
> SSL_set_fd(ssl,sd);
> if((rc=SSL_connect(ssl))!=1){
> printf("CHECK_NRPE: Error - Could not complete SSL handshake.\n");
> ----- end code segment from check_nrpe.c -----
>
> Somewhere in here, something isn't working. I don't know enough about
> the SSL library to deduce what might be wrong with this. Does someone
> else have a clue?
>
> Michael
>
>> -----Ursprüngliche Nachricht-----
>> Von: Steve Feehan [mailto:sfeehan at sbb.uvm.edu]
>> Gesendet: Mittwoch, 24. Dezember 2003 00:24
>> An: John Downs
>> Cc: nagios-users at lists.sourceforge.net
>> Betreff: Re: [Nagios-users] check_nrpe fails, SSL handshake error (NOT
>> Solved)
>>
>>
>> On Tue, Dec 23, 2003 at 03:30:14PM -0500, John Downs wrote:
>>> I tried truss while running in daemon mode and got lots of output.
>> However,
>>> I don't
>>> know how to interpret that output. I also got nothing returned when
>>> I do
>> a
>>> "netstat -a | grep -i nrpe ",and different results when I changed the
>>> ownership on nrpe.cfg from root to nagios. How would I run truss with
>>> an
>>> inetd process? Can I?
>>>
>>> -john
>>
>> Try running nrpe in daemon mode through truss again, this time
>> pass the -f option (I think that's the one to trace children as
>> well).
>>
>> As for tracing through inetd, it will be messy on a busy system.
>> But it is possible... figure out the PID of inetd and then attach
>> truss to that process (i think it's -p PID). Make sure you specify
>> the -f (or whatever) to trace children. You'll get a lot of output
>> to wade through, but maybe it'll help.
>>
>> In the trace below, the only think I see suspicious are the calls
>> to fstat(-1, ...). Not really sure where that's coming from. But
>> it would be nice to see the trace of the children after the fork.
>>
>> I'll be glad to look at the truss output, problem is I'm going
>> out of town till Sunday. :)
>>
>> Steve
>>
>>> #nrpe stream tcp nowait nagios /usr/bin/nrpe -c /etc/nrpe.cfg
>>> -i
>>> # truss /usr/bin/nrpe -c /etc/nrpe.cfg -d
>>> execve("/usr/bin/nrpe", 0xFFBEF3D4, 0xFFBEF3E8) argc = 4
>>> mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A0000
>>> resolvepath("/usr/lib/ld.so.1", "/usr/lib/ld.so.1", 1023) = 16
>>> open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
>>> open("/usr/lib/libnsl.so.1", O_RDONLY) = 3
>>> fstat(3, 0xFFBEEAFC) = 0
>>> mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>> 0xFF390000
>>> mmap(0x00000000, 704512, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>>> 0xFF280000
>>> mmap(0xFF31C000, 32740, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED, 3, 573440) = 0xFF31C000
>>> mmap(0xFF324000, 30928, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xFF324000
>>> munmap(0xFF30C000, 65536) = 0
>>> memcntl(0xFF280000, 82252, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
>>> close(3) = 0
>>> open("/usr/lib/libsocket.so.1", O_RDONLY) = 3
>>> fstat(3, 0xFFBEEAFC) = 0
>>> mmap(0xFF390000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
>>> 0) =
>>> 0xFF390000
>>> mmap(0x00000000, 114688, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>>> 0xFF370000
>>> mmap(0xFF38A000, 4365, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED, 3, 40960) = 0xFF38A000
>>> munmap(0xFF37A000, 65536) = 0
>>> memcntl(0xFF370000, 14496, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
>>> close(3) = 0
>>> open("/usr/lib/libc.so.1", O_RDONLY) = 3
>>> fstat(3, 0xFFBEEAFC) = 0
>>> mmap(0xFF390000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
>>> 0) =
>>> 0xFF390000
>>> mmap(0x00000000, 794624, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>>> 0xFF180000
>>> mmap(0xFF23A000, 24652, PROT_READ|PROT_WRITE|PROT_EXEC,
>>> MAP_PRIVATE|MAP_FIXED, 3, 696320) = 0xFF23A000
>>> munmap(0xFF22A000, 65536) = 0
>>> memcntl(0xFF180000, 113332, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
>>> close(3) = 0
>>> open("/usr/lib/libdl.so.1", O_RDONLY) = 3
>>> fstat(3, 0xFFBEEAFC) = 0
>>> mmap(0xFF390000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
>>> 0) =
>>> 0xFF390000
>>> close(3) = 0
>>> open("/usr/lib/libmp.so.2", O_RDONLY) = 3
>>> fstat(3, 0xFFBEEAFC) = 0
>>> mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>> 0xFF360000
>>> mmap(0x00000000, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>> 0xFF340000
>>> mmap(0xFF354000, 865, PROT_READ|PROT_WRITE|PROT_EXEC,
>> MAP_PRIVATE|MAP_FIXED,
>>> 3, 16384) = 0xFF354000
>>> munmap(0xFF344000, 65536) = 0
>>> memcntl(0xFF340000, 3124, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
>>> close(3) = 0
>>> open("/usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1", O_RDONLY) = 3
>>> fstat(3, 0xFFBEE98C) = 0
>>> mmap(0xFF360000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
>>> 0) =
>>> 0xFF360000
>>> mmap(0x00000000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>> 0xFF270000
>>> close(3) = 0
>>> munmap(0xFF360000, 8192) = 0
>>> brk(0x000267D0) = 0
>>> brk(0x000287D0) = 0
>>> fstat(-1, 0xFFBEEA78) Err#9 EBADF
>>> open("/etc/nrpe.cfg", O_RDONLY) = 3
>>> fstat64(3, 0xFFBEE098) = 0
>>> brk(0x000287D0) = 0
>>> brk(0x0002A7D0) = 0
>>> ioctl(3, TCGETA, 0xFFBEE024) Err#25 ENOTTY
>>> read(3, " # # # # # # # # # # # #".., 8192) = 5019
>>> fstat(-1, 0xFFBED468) Err#9 EBADF
>>> open("/dev/conslog", O_WRONLY) = 4
>>> fcntl(4, F_SETFD, 0x00000001) = 0
>>> fstat(4, 0xFFBED468) = 0
>>> fstat(4, 0xFFBEDEC8) = 0
>>> time() = 1072211336
>>> open("/usr/share/lib/zoneinfo/US/Eastern", O_RDONLY) = 5
>>> read(5, " T Z i f\0\0\0\0\0\0\0\0".., 8192) = 1250
>>> close(5) = 0
>>> getpid() = 1768 [1767]
>>> putmsg(4, 0xFFBED580, 0xFFBED574, 0) = 0
>>> open("/var/run/syslog_door", O_RDONLY) = 5
>>> door_info(5, 0xFFBED4B8) = 0
>>> getpid() = 1768 [1767]
>>> door_call(5, 0xFFBED4A0) = 0
>>> close(5) = 0
>>> fstat(4, 0xFFBEDEC8) = 0
>>> time() = 1072211336
>>> getpid() = 1768 [1767]
>>> putmsg(4, 0xFFBED580, 0xFFBED574, 0) = 0
>>> open("/var/run/syslog_door", O_RDONLY) = 5
>>> door_info(5, 0xFFBED4B8) = 0
>>> getpid() = 1768 [1767]
>>> door_call(5, 0xFFBED4A0) = 0
>>> close(5) = 0
>>> fstat(4, 0xFFBEDEC8) = 0
>>> time() = 1072211336
>>> getpid() = 1768 [1767]
>>> putmsg(4, 0xFFBED580, 0xFFBED574, 0) = 0
>>> open("/var/run/syslog_door", O_RDONLY) = 5
>>> door_info(5, 0xFFBED4B8) = 0
>>> getpid() = 1768 [1767]
>>> door_call(5, 0xFFBED4A0) = 0
>>> close(5) = 0
>>> brk(0x0002A7D0) = 0
>>> brk(0x0002C7D0) = 0
>>> fstat(4, 0xFFBEDEC8) = 0
>>> time() = 1072211336
>>> getpid() = 1768 [1767]
>>> putmsg(4, 0xFFBED580, 0xFFBED574, 0) = 0
>>> open("/var/run/syslog_door", O_RDONLY) = 5
>>> door_info(5, 0xFFBED4B8) = 0
>>> getpid() = 1768 [1767]
>>> door_call(5, 0xFFBED4A0) = 0
>>> close(5) = 0
>>> fstat(4, 0xFFBEDEC8) = 0
>>> time() = 1072211336
>>> getpid() = 1768 [1767]
>>> putmsg(4, 0xFFBED580, 0xFFBED574, 0) = 0
>>> open("/var/run/syslog_door", O_RDONLY) = 5
>>> door_info(5, 0xFFBED4B8) = 0
>>> getpid() = 1768 [1767]
>>> door_call(5, 0xFFBED4A0) = 0
>>> close(5) = 0
>>> read(3, 0x0002681C, 8192) = 0
>>> llseek(3, 0, SEEK_CUR) = 5019
>>> close(3) = 0
>>> fork() = 1769
>>> llseek(0, 0, SEEK_CUR) = 70514
>>> _exit(0)
>>> # hostnam
>>> hostnam: not found
>>> # hostname
>>> photon
>>> #
>>>
>>>
>>> ----- Original Message -----
>>> From: "Patrick Soltani" <PSoltani at iitcorporation.com>
>>> To: "Michael Tucker" <mtucker at airmail.net>;
>>> <nagios-users at lists.sourceforge.net>
>>> Sent: Tuesday, December 23, 2003 2:26 PM
>>> Subject: RE: [Nagios-users] check_nrpe fails, SSL handshake error
>>> (NOT
>>> Solved)
>>>
>>>
>>>> Hi,
>>>>
>>>> When there is no more info on the module, then I'll turn to "truss"
>>>> on
>>> Solaris and run the same command line but with truss to see what
>>> exactly
>> the
>>> module is doing and what kind of internal roll-o-coaster it
>>> traverses.
>>>>
>>>> That should shed more light on the issue.
>>>>
>>>> Regards,
>>>> Patrick Soltani.
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: nagios-users-admin at lists.sourceforge.net
>>>>> [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of
>>>>> Michael
>>>>> Tucker
>>>>> Sent: Monday, December 22, 2003 8:23 PM
>>>>> To: nagios-users at lists.sourceforge.net
>>>>> Subject: Re: [Nagios-users] check_nrpe fails, SSL handshake error
>>>>> (NOT
>>>>> Solved)
>>>>>
>>>>>
>>>>>
>>>>> On Monday, December 22, 2003, at 05:34 PM, John Downs wrote:
>>>>>
>>>>>> I wish my problem was so easy to fix. I recompiled with
>>>>>> --disable-ssl
>>>>>> option and it works
>>>>>> a little better.(I tried the permissions issue it didn't
>>>>> help) I am
>>>>>> still
>>>>>> getting the following error
>>>>>> in /var/adm/messages:
>>>>>>
>>>>>> Network server bind failure (126: cannot assign requested
>>>>>> addres)
>>>>>> This happens when I start start nrpe in daemon mode with:
>>>>>> /usr/bin/nrpe -c /etc/nrpe.cfg -d
>>>>>>
>>>>>> nrpe is owned by root and has suid bit set. nrpe.cfg is owned by
>>>>>> nagios and
>>>>>> is readable by everyone.
>>>>>>
>>>>>> any ideas on this?
>>>>>>
>>>>>> Thanks!!
>>>>>>
>>>>>> -john
>>>>>>
>>>>>
>>>>> Yeah, I get exactly the same thing. (Well *almost* exactly the
>>>>> same.
>>>>> Mine says "(125: cannot assign requested address)", but
>>>>> otherwise it's
>>>>> the same if I try to launch nrpe as a stand-alone daemon. (In
>>>>> my case,
>>>>> both nrpe and nrpe.cfg are owned by nagios:nagios, no suid
>>>>> bit set, and
>>>>> are readable by everyone.)
>>>>>
>>>>> It works if I use inetd with tcp wrappers, though, as I
>>>>> described in my
>>>>> first message...
>>>>>
>>>>>> /etc/inetd.conf:
>>>>>> nrpe stream tcp nowait nagios
>>>>> /usr/sfw/sbin/tcpd /usr/local/nagios/
>>>>>> bin/nrpe -c /usr/local/nagios/bin/nrpe.cfg -i
>>>>>>
>>>>>> /etc/services:
>>>>>> nrpe 5666/tcp # NRPE (Nagios remote plugin executor)
>>>>>
>>>>> ...but ONLY if I have SSL disabled (recompiled nrpe with
>>>>> --disable-ssl). I plan to deploy this to some sites where the SSL
>>>>> security will be critically important. I can continue with my
>>>>> testing
>>>>> without it, but sooner or later I've got to fix this link in
>>>>> the chain.
>>>>>
>>>>> Surely there's someone out there running Solaris who's had a
>>>>> similar
>>>>> problem, and figured out how to solve it?
>>>>>
>>>>> *frustrated*
>>>>>
>>>>> Michael
>>
>> --
>> Steve Feehan
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
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