AW: [BUG] check_nrpe fails, SSL handshake error
Richard Mayhew
richard at splash.co.za
Wed Jan 7 21:05:08 CET 2004
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
-------------------------------------------------------
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