thr3ads.net - CentOS - [CentOS] Could not complete SSL handshake to Amazon EC2 host [May 2015]

If this information is useful, please help other people find it:
Share via:

Tim Dunphy

2015-May-01 11:14 UTC

[CentOS] Could not complete SSL handshake to Amazon EC2 host

> This is strange...
> Do you have SSL aktive on both systems? Run nrpr localy without parameters
> (this should return some nrpe stats) and check ldd for libssl.

I don't seem to have that command.


[root at monitor1:~] #find / -name "*nrpr" 2> /dev/null
[root at monitor1:~] #

And that's on either system.

 And if I do an ldd on both, this is what I can tell:

Server:

[root at monitor1:~] #ldd /usr/local/nagios/libexec/check_nrpe
        linux-vdso.so.1 =>  (0x00007fffd895d000)
       * libssl.so.10 => /lib64/libssl.so.10 (0x00007fc61722a000)*
*        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fc616e43000)*
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fc616c29000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fc616868000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2
(0x00007fc61661c000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fc616338000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fc616134000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fc615f02000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fc615cfd000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fc615ae7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc6174a0000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0
(0x00007fc6158d8000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fc6156d3000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fc6154b9000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc61529d000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc615077000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fc614e16000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc614bf1000)


Client:

[root at ops:~] #ldd /usr/local/nagios/libexec/check_nrpe
       * libssl.so.6 => /lib64/libssl.so.6 (0x00002aaaaaaba000)*
*        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002aaaaad08000)*
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaab05a000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaab273000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
(0x00002aaaab5cc000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaab7fa000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaaba90000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaabc92000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaabeb7000)
        libz.so.1 => /lib64/libz.so.1 (0x00002aaaac0bc000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0
0002aaaac2d0000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002aaaac4d8000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaac6db000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aaaac8f0000)
        libsepol.so.1 => /lib64/libsepol.so.1 (0x00002aaaacb09000)


So it looks like everything is OK from the SSL end of things. Any other
ideas or suggestions?

Thanks
Tim

On Fri, May 1, 2015 at 5:46 AM, Eric Lehmann <e.lehmann88 at gmail.com>
wrote:
> This is strange...
> Do you have SSL aktive on both systems? Run nrpr localy without parameters
> (this should return some nrpe stats) and check ldd for libssl.
> Am 01.05.2015 07:32 schrieb "Tim Dunphy" <bluethundr at
gmail.com>:
>
> > Hi Eric,
> >
> >  Thanks for your reply. I do have nrpe running under xinetd on the
host
> I'm
> > trying to monitor.
> >
> >  And running the nrpe checl locally:
> >
> > [root at ops:~] #/usr/local/nagios/libexec/check_nrpe -H localhost
> > NRPE v2.15
> >
> > [root at ops:~] #grep only_from /etc/xinetd.d/nrpe
> >         only_from       = 127.0.0.1 216.120.248.126
> >
> > And I do have port 5666 open on the security group for this host.
> >
> > And I made sure the local firewall was stopped, because I am blocking
> ports
> > with the security groups instead.
> >
> > [root at ops:~] #service iptables status
> > Firewall is stopped.
> >
> > It's only when checking from the monitoring host that nrpe fails:
> >
> > [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H
> > ops.jokefire.com
> > CHECK_NRPE: Error - Could not complete SSL handshake.
> >
> > Really, really puzzling. This is driving me up a wall!! I hopeI can
solve
> > this soon....
> >
> > Thanks for any and all help with this one!!
> > Tim
> >
> > On Fri, May 1, 2015 at 1:02 AM, Eric Lehmann <e.lehmann88 at
gmail.com>
> > wrote:
> >
> > > Hi
> > > Does the deamon run under xinetd? Then  you have to configure the
> > only_from
> > > in  */etc/**xinetd.d**/**nrpe* to.
> > >
> > > Regards
> > > Eric
> > > Am 01.05.2015 06:46 schrieb "Tim Dunphy" <bluethundr
at gmail.com>:
> > >
> > > > Hello,
> > > >
> > > >  I am trying to monitor a host in the Amazon EC2 cloud.
> > > >
> > > > Yet when I try to check NRPE from the monitoring host I am
getting an
> > SSL
> > > > handshake error:
> > > >
> > > > [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe
-H
> > > > ops.jokefire.com
> > > > CHECK_NRPE: Error - Could not complete SSL handshake.
> > > >
> > > > And if I telnet into the host on port 5666 to see if the FW
port is
> > open,
> > > > the connection closes right away:
> > > >
> > > > [root at monitor1:~] #telnet ops.somewhere.com 5666
> > > > Trying 54.225.218.125...
> > > > Connected to ops.somewhere.com.
> > > > Escape character is '^]'.
> > > > Connection closed by foreign host.
> > > >
> > > > You can see there it connects, but then it closes
immediately after
> the
> > > > connection.
> > > >
> > > >  I have NRPE running on the host I want to monitor:
> > > >
> > > > [root at ops:~] #lsof -i :5666
> > > > COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
> > > > xinetd  1434 root    5u  IPv4   4063       TCP *:nrpe
(LISTEN)
> > > >
> > > > And I have the IP of my nagios server listed in the xinetd
conf file:
> > > >
> > > > [root at ops:~] #cat /etc/xinetd.d/nrpe
> > > > # default: on
> > > > # description: NRPE (Nagios Remote Plugin Executor)
> > > > service nrpe
> > > > {
> > > >         flags           = REUSE
> > > >         socket_type     = stream
> > > >         port            = 5666
> > > >         wait            = no
> > > >         user            = nagios
> > > >         group           = nagios
> > > >         server          = /usr/local/nagios/bin/nrpe
> > > >         server_args     = -c /usr/local/nagios/etc/nrpe.cfg
--inetd
> > > >         log_on_failure  += USERID
> > > >         disable         = no
> > > >         only_from       = 127.0.0.1 xx.xx.xx.xx   # <-
representing
> my
> > > real
> > > > nagios server IP
> > > > }
> > > >
> > > >
> > > >
> > > > And I have my default security group for that host open on
port 5666
> to
> > > the
> > > > world for this experiment.  I plan on locking that down
again to the
> > > single
> > > > IP of my monitoring host once I get this resolved.
> > > >
> > > > Does anyone have any suggestions on how I can get that
problem
> solved?
> > > >
> > > > Thanks,
> > > > Tim
> > > >
> > > > --
> > > > GPG me!!
> > > >
> > > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
> > > > _______________________________________________
> > > > CentOS mailing list
> > > > CentOS at centos.org
> > > > http://lists.centos.org/mailman/listinfo/centos
> > > >
> > > _______________________________________________
> > > CentOS mailing list
> > > CentOS at centos.org
> > > http://lists.centos.org/mailman/listinfo/centos
> > >
> >
> >
> >
> > --
> > GPG me!!
> >
> > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
> > _______________________________________________
> > CentOS mailing list
> > CentOS at centos.org
> > http://lists.centos.org/mailman/listinfo/centos
> >
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


-- 
GPG me!!

gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

Eero Volotinen

2015-May-01 11:18 UTC

head link

[CentOS] Could not complete SSL handshake to Amazon EC2 host

well. how about trying default setting and running nrped without xinetd.

--
Eero

2015-05-01 14:14 GMT+03:00 Tim Dunphy <bluethundr at gmail.com>:
> > This is strange...
> > Do you have SSL aktive on both systems? Run nrpr localy without
> parameters
> > (this should return some nrpe stats) and check ldd for libssl.
>
>
> I don't seem to have that command.
>
>
> [root at monitor1:~] #find / -name "*nrpr" 2> /dev/null
> [root at monitor1:~] #
>
> And that's on either system.
>
>  And if I do an ldd on both, this is what I can tell:
>
> Server:
>
> [root at monitor1:~] #ldd /usr/local/nagios/libexec/check_nrpe
>         linux-vdso.so.1 =>  (0x00007fffd895d000)
>        * libssl.so.10 => /lib64/libssl.so.10 (0x00007fc61722a000)*
> *        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fc616e43000)*
>         libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fc616c29000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007fc616868000)
>         libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2
> (0x00007fc61661c000)
>         libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fc616338000)
>         libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fc616134000)
>         libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fc615f02000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00007fc615cfd000)
>         libz.so.1 => /lib64/libz.so.1 (0x00007fc615ae7000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007fc6174a0000)
>         libkrb5support.so.0 => /lib64/libkrb5support.so.0
> (0x00007fc6158d8000)
>         libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fc6156d3000)
>         libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fc6154b9000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc61529d000)
>         libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc615077000)
>         libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fc614e16000)
>         liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc614bf1000)
>
>
> Client:
>
> [root at ops:~] #ldd /usr/local/nagios/libexec/check_nrpe
>        * libssl.so.6 => /lib64/libssl.so.6 (0x00002aaaaaaba000)*
> *        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002aaaaad08000)*
>         libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaab05a000)
>         libc.so.6 => /lib64/libc.so.6 (0x00002aaaab273000)
>         libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
> (0x00002aaaab5cc000)
>         libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaab7fa000)
>         libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaaba90000)
>         libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3
> (0x00002aaaabc92000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaabeb7000)
>         libz.so.1 => /lib64/libz.so.1 (0x00002aaaac0bc000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
>         libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0
> 0002aaaac2d0000)
>         libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002aaaac4d8000)
>         libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaac6db000)
>         libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aaaac8f0000)
>         libsepol.so.1 => /lib64/libsepol.so.1 (0x00002aaaacb09000)
>
>
> So it looks like everything is OK from the SSL end of things. Any other
> ideas or suggestions?
>
> Thanks
> Tim
>
> On Fri, May 1, 2015 at 5:46 AM, Eric Lehmann <e.lehmann88 at
gmail.com>
> wrote:
>
> > This is strange...
> > Do you have SSL aktive on both systems? Run nrpr localy without
> parameters
> > (this should return some nrpe stats) and check ldd for libssl.
> > Am 01.05.2015 07:32 schrieb "Tim Dunphy" <bluethundr at
gmail.com>:
> >
> > > Hi Eric,
> > >
> > >  Thanks for your reply. I do have nrpe running under xinetd on
the host
> > I'm
> > > trying to monitor.
> > >
> > >  And running the nrpe checl locally:
> > >
> > > [root at ops:~] #/usr/local/nagios/libexec/check_nrpe -H
localhost
> > > NRPE v2.15
> > >
> > > [root at ops:~] #grep only_from /etc/xinetd.d/nrpe
> > >         only_from       = 127.0.0.1 216.120.248.126
> > >
> > > And I do have port 5666 open on the security group for this host.
> > >
> > > And I made sure the local firewall was stopped, because I am
blocking
> > ports
> > > with the security groups instead.
> > >
> > > [root at ops:~] #service iptables status
> > > Firewall is stopped.
> > >
> > > It's only when checking from the monitoring host that nrpe
fails:
> > >
> > > [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H
> > > ops.jokefire.com
> > > CHECK_NRPE: Error - Could not complete SSL handshake.
> > >
> > > Really, really puzzling. This is driving me up a wall!! I hopeI
can
> solve
> > > this soon....
> > >
> > > Thanks for any and all help with this one!!
> > > Tim
> > >
> > > On Fri, May 1, 2015 at 1:02 AM, Eric Lehmann <e.lehmann88 at
gmail.com>
> > > wrote:
> > >
> > > > Hi
> > > > Does the deamon run under xinetd? Then  you have to
configure the
> > > only_from
> > > > in  */etc/**xinetd.d**/**nrpe* to.
> > > >
> > > > Regards
> > > > Eric
> > > > Am 01.05.2015 06:46 schrieb "Tim Dunphy"
<bluethundr at gmail.com>:
> > > >
> > > > > Hello,
> > > > >
> > > > >  I am trying to monitor a host in the Amazon EC2 cloud.
> > > > >
> > > > > Yet when I try to check NRPE from the monitoring host I
am getting
> an
> > > SSL
> > > > > handshake error:
> > > > >
> > > > > [root at monitor1:~]
#/usr/local/nagios/libexec/check_nrpe -H
> > > > > ops.jokefire.com
> > > > > CHECK_NRPE: Error - Could not complete SSL handshake.
> > > > >
> > > > > And if I telnet into the host on port 5666 to see if
the FW port is
> > > open,
> > > > > the connection closes right away:
> > > > >
> > > > > [root at monitor1:~] #telnet ops.somewhere.com 5666
> > > > > Trying 54.225.218.125...
> > > > > Connected to ops.somewhere.com.
> > > > > Escape character is '^]'.
> > > > > Connection closed by foreign host.
> > > > >
> > > > > You can see there it connects, but then it closes
immediately after
> > the
> > > > > connection.
> > > > >
> > > > >  I have NRPE running on the host I want to monitor:
> > > > >
> > > > > [root at ops:~] #lsof -i :5666
> > > > > COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
> > > > > xinetd  1434 root    5u  IPv4   4063       TCP *:nrpe
(LISTEN)
> > > > >
> > > > > And I have the IP of my nagios server listed in the
xinetd conf
> file:
> > > > >
> > > > > [root at ops:~] #cat /etc/xinetd.d/nrpe
> > > > > # default: on
> > > > > # description: NRPE (Nagios Remote Plugin Executor)
> > > > > service nrpe
> > > > > {
> > > > >         flags           = REUSE
> > > > >         socket_type     = stream
> > > > >         port            = 5666
> > > > >         wait            = no
> > > > >         user            = nagios
> > > > >         group           = nagios
> > > > >         server          = /usr/local/nagios/bin/nrpe
> > > > >         server_args     = -c
/usr/local/nagios/etc/nrpe.cfg --inetd
> > > > >         log_on_failure  += USERID
> > > > >         disable         = no
> > > > >         only_from       = 127.0.0.1 xx.xx.xx.xx   #
<- representing
> > my
> > > > real
> > > > > nagios server IP
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > > And I have my default security group for that host open
on port
> 5666
> > to
> > > > the
> > > > > world for this experiment.  I plan on locking that down
again to
> the
> > > > single
> > > > > IP of my monitoring host once I get this resolved.
> > > > >
> > > > > Does anyone have any suggestions on how I can get that
problem
> > solved?
> > > > >
> > > > > Thanks,
> > > > > Tim
> > > > >
> > > > > --
> > > > > GPG me!!
> > > > >
> > > > > gpg --keyserver pool.sks-keyservers.net --recv-keys
F186197B
> > > > > _______________________________________________
> > > > > CentOS mailing list
> > > > > CentOS at centos.org
> > > > > http://lists.centos.org/mailman/listinfo/centos
> > > > >
> > > > _______________________________________________
> > > > CentOS mailing list
> > > > CentOS at centos.org
> > > > http://lists.centos.org/mailman/listinfo/centos
> > > >
> > >
> > >
> > >
> > > --
> > > GPG me!!
> > >
> > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
> > > _______________________________________________
> > > CentOS mailing list
> > > CentOS at centos.org
> > > http://lists.centos.org/mailman/listinfo/centos
> > >
> > _______________________________________________
> > CentOS mailing list
> > CentOS at centos.org
> > http://lists.centos.org/mailman/listinfo/centos
> >
>
>
>
> --
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>

Eric Lehmann

2015-May-01 11:43 UTC

head link

[CentOS] Could not complete SSL handshake to Amazon EC2 host

Oh my mistake. I mean nrpe without parameters. It should say something
about SSL/TLS aktiv or so.
You could test nrpe without SSL. Use nrpe -n - H host
Am 01.05.2015 13:18 schrieb "Eero Volotinen" <eero.volotinen at
iki.fi>:
> well. how about trying default setting and running nrped without xinetd.
>
> --
> Eero
>
> 2015-05-01 14:14 GMT+03:00 Tim Dunphy <bluethundr at gmail.com>:
>
> > > This is strange...
> > > Do you have SSL aktive on both systems? Run nrpr localy without
> > parameters
> > > (this should return some nrpe stats) and check ldd for libssl.
> >
> >
> > I don't seem to have that command.
> >
> >
> > [root at monitor1:~] #find / -name "*nrpr" 2> /dev/null
> > [root at monitor1:~] #
> >
> > And that's on either system.
> >
> >  And if I do an ldd on both, this is what I can tell:
> >
> > Server:
> >
> > [root at monitor1:~] #ldd /usr/local/nagios/libexec/check_nrpe
> >         linux-vdso.so.1 =>  (0x00007fffd895d000)
> >        * libssl.so.10 => /lib64/libssl.so.10 (0x00007fc61722a000)*
> > *        libcrypto.so.10 => /lib64/libcrypto.so.10
(0x00007fc616e43000)*
> >         libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fc616c29000)
> >         libc.so.6 => /lib64/libc.so.6 (0x00007fc616868000)
> >         libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2
> > (0x00007fc61661c000)
> >         libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fc616338000)
> >         libcom_err.so.2 => /lib64/libcom_err.so.2
(0x00007fc616134000)
> >         libk5crypto.so.3 => /lib64/libk5crypto.so.3
(0x00007fc615f02000)
> >         libdl.so.2 => /lib64/libdl.so.2 (0x00007fc615cfd000)
> >         libz.so.1 => /lib64/libz.so.1 (0x00007fc615ae7000)
> >         /lib64/ld-linux-x86-64.so.2 (0x00007fc6174a0000)
> >         libkrb5support.so.0 => /lib64/libkrb5support.so.0
> > (0x00007fc6158d8000)
> >         libkeyutils.so.1 => /lib64/libkeyutils.so.1
(0x00007fc6156d3000)
> >         libresolv.so.2 => /lib64/libresolv.so.2
(0x00007fc6154b9000)
> >         libpthread.so.0 => /lib64/libpthread.so.0
(0x00007fc61529d000)
> >         libselinux.so.1 => /lib64/libselinux.so.1
(0x00007fc615077000)
> >         libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fc614e16000)
> >         liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc614bf1000)
> >
> >
> > Client:
> >
> > [root at ops:~] #ldd /usr/local/nagios/libexec/check_nrpe
> >        * libssl.so.6 => /lib64/libssl.so.6 (0x00002aaaaaaba000)*
> > *        libcrypto.so.6 => /lib64/libcrypto.so.6
(0x00002aaaaad08000)*
> >         libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaab05a000)
> >         libc.so.6 => /lib64/libc.so.6 (0x00002aaaab273000)
> >         libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
> > (0x00002aaaab5cc000)
> >         libkrb5.so.3 => /usr/lib64/libkrb5.so.3
(0x00002aaaab7fa000)
> >         libcom_err.so.2 => /lib64/libcom_err.so.2
(0x00002aaaaba90000)
> >         libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3
> > (0x00002aaaabc92000)
> >         libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaabeb7000)
> >         libz.so.1 => /lib64/libz.so.1 (0x00002aaaac0bc000)
> >         /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
> >         libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0
> > 0002aaaac2d0000)
> >         libkeyutils.so.1 => /lib64/libkeyutils.so.1
(0x00002aaaac4d8000)
> >         libresolv.so.2 => /lib64/libresolv.so.2
(0x00002aaaac6db000)
> >         libselinux.so.1 => /lib64/libselinux.so.1
(0x00002aaaac8f0000)
> >         libsepol.so.1 => /lib64/libsepol.so.1 (0x00002aaaacb09000)
> >
> >
> > So it looks like everything is OK from the SSL end of things. Any
other
> > ideas or suggestions?
> >
> > Thanks
> > Tim
> >
> > On Fri, May 1, 2015 at 5:46 AM, Eric Lehmann <e.lehmann88 at
gmail.com>
> > wrote:
> >
> > > This is strange...
> > > Do you have SSL aktive on both systems? Run nrpr localy without
> > parameters
> > > (this should return some nrpe stats) and check ldd for libssl.
> > > Am 01.05.2015 07:32 schrieb "Tim Dunphy" <bluethundr
at gmail.com>:
> > >
> > > > Hi Eric,
> > > >
> > > >  Thanks for your reply. I do have nrpe running under xinetd
on the
> host
> > > I'm
> > > > trying to monitor.
> > > >
> > > >  And running the nrpe checl locally:
> > > >
> > > > [root at ops:~] #/usr/local/nagios/libexec/check_nrpe -H
localhost
> > > > NRPE v2.15
> > > >
> > > > [root at ops:~] #grep only_from /etc/xinetd.d/nrpe
> > > >         only_from       = 127.0.0.1 216.120.248.126
> > > >
> > > > And I do have port 5666 open on the security group for this
host.
> > > >
> > > > And I made sure the local firewall was stopped, because I am
blocking
> > > ports
> > > > with the security groups instead.
> > > >
> > > > [root at ops:~] #service iptables status
> > > > Firewall is stopped.
> > > >
> > > > It's only when checking from the monitoring host that
nrpe fails:
> > > >
> > > > [root at monitor1:~] #/usr/local/nagios/libexec/check_nrpe
-H
> > > > ops.jokefire.com
> > > > CHECK_NRPE: Error - Could not complete SSL handshake.
> > > >
> > > > Really, really puzzling. This is driving me up a wall!! I
hopeI can
> > solve
> > > > this soon....
> > > >
> > > > Thanks for any and all help with this one!!
> > > > Tim
> > > >
> > > > On Fri, May 1, 2015 at 1:02 AM, Eric Lehmann <e.lehmann88
at gmail.com>
> > > > wrote:
> > > >
> > > > > Hi
> > > > > Does the deamon run under xinetd? Then  you have to
configure the
> > > > only_from
> > > > > in  */etc/**xinetd.d**/**nrpe* to.
> > > > >
> > > > > Regards
> > > > > Eric
> > > > > Am 01.05.2015 06:46 schrieb "Tim Dunphy"
<bluethundr at gmail.com>:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > >  I am trying to monitor a host in the Amazon EC2
cloud.
> > > > > >
> > > > > > Yet when I try to check NRPE from the monitoring
host I am
> getting
> > an
> > > > SSL
> > > > > > handshake error:
> > > > > >
> > > > > > [root at monitor1:~]
#/usr/local/nagios/libexec/check_nrpe -H
> > > > > > ops.jokefire.com
> > > > > > CHECK_NRPE: Error - Could not complete SSL
handshake.
> > > > > >
> > > > > > And if I telnet into the host on port 5666 to see
if the FW port
> is
> > > > open,
> > > > > > the connection closes right away:
> > > > > >
> > > > > > [root at monitor1:~] #telnet ops.somewhere.com
5666
> > > > > > Trying 54.225.218.125...
> > > > > > Connected to ops.somewhere.com.
> > > > > > Escape character is '^]'.
> > > > > > Connection closed by foreign host.
> > > > > >
> > > > > > You can see there it connects, but then it closes
immediately
> after
> > > the
> > > > > > connection.
> > > > > >
> > > > > >  I have NRPE running on the host I want to
monitor:
> > > > > >
> > > > > > [root at ops:~] #lsof -i :5666
> > > > > > COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE
NAME
> > > > > > xinetd  1434 root    5u  IPv4   4063       TCP
*:nrpe (LISTEN)
> > > > > >
> > > > > > And I have the IP of my nagios server listed in
the xinetd conf
> > file:
> > > > > >
> > > > > > [root at ops:~] #cat /etc/xinetd.d/nrpe
> > > > > > # default: on
> > > > > > # description: NRPE (Nagios Remote Plugin
Executor)
> > > > > > service nrpe
> > > > > > {
> > > > > >         flags           = REUSE
> > > > > >         socket_type     = stream
> > > > > >         port            = 5666
> > > > > >         wait            = no
> > > > > >         user            = nagios
> > > > > >         group           = nagios
> > > > > >         server          =
/usr/local/nagios/bin/nrpe
> > > > > >         server_args     = -c
/usr/local/nagios/etc/nrpe.cfg
> --inetd
> > > > > >         log_on_failure  += USERID
> > > > > >         disable         = no
> > > > > >         only_from       = 127.0.0.1 xx.xx.xx.xx  
# <-
> representing
> > > my
> > > > > real
> > > > > > nagios server IP
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > > And I have my default security group for that host
open on port
> > 5666
> > > to
> > > > > the
> > > > > > world for this experiment.  I plan on locking that
down again to
> > the
> > > > > single
> > > > > > IP of my monitoring host once I get this resolved.
> > > > > >
> > > > > > Does anyone have any suggestions on how I can get
that problem
> > > solved?
> > > > > >
> > > > > > Thanks,
> > > > > > Tim
> > > > > >
> > > > > > --
> > > > > > GPG me!!
> > > > > >
> > > > > > gpg --keyserver pool.sks-keyservers.net
--recv-keys F186197B
> > > > > > _______________________________________________
> > > > > > CentOS mailing list
> > > > > > CentOS at centos.org
> > > > > > http://lists.centos.org/mailman/listinfo/centos
> > > > > >
> > > > > _______________________________________________
> > > > > CentOS mailing list
> > > > > CentOS at centos.org
> > > > > http://lists.centos.org/mailman/listinfo/centos
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > GPG me!!
> > > >
> > > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
> > > > _______________________________________________
> > > > CentOS mailing list
> > > > CentOS at centos.org
> > > > http://lists.centos.org/mailman/listinfo/centos
> > > >
> > > _______________________________________________
> > > CentOS mailing list
> > > CentOS at centos.org
> > > http://lists.centos.org/mailman/listinfo/centos
> > >
> >
> >
> >
> > --
> > GPG me!!
> >
> > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
> > _______________________________________________
> > CentOS mailing list
> > CentOS at centos.org
> > http://lists.centos.org/mailman/listinfo/centos
> >
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>

Possibly Parallel Threads

Search for more seemingly similar threads

CentOS - May 2015 - Could not complete SSL handshake to Amazon EC2 host

[CentOS] Could not complete SSL handshake to Amazon EC2 host

[CentOS] Could not complete SSL handshake to Amazon EC2 host

[CentOS] Could not complete SSL handshake to Amazon EC2 host

Possibly Parallel Threads