I have installed nagios server including nrpe & nagios plugins. Its working properly.
However I am trying to install nrpe & nagios plugins for remote host monitoring using nagios server, After the configuration is done & I am running below command for testing:
/usr/local/nagios/libexec/check_nrpe -H localhost
Output:
CHECK_NRPE: Socket timeout after 10 seconds. (And for some of the services its giving)
CHECK_NRPE: Error - Could not complete SSL handshake.
The port 5666 is listening on that server.
Can anyone please let me know what other changes to be made to get proper results of the above command.
Also please let me know if you need any more details about the configurations.
Sometimes this might also mean that the server is trying to perform a check with SSL while the NRPE daemon is not running with the SSL option (or the other way around).
Could you try running the check like below ?
/usr/local/nagios/libexec/check_nrpe -H localhost -n
You may need to check firewall.
Also make sure that both nagios and nrpe daemons are running.
You should have the openssl and openssl-devel installed
aptitude install openssl openssl-devel
Are you using Xinetd?
If you are, you should check the service configuration in /etc/xinetd.d/nrpe
You shoud have something like this:
# 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 <YouNagiosServerIP>
}
And Finally:
service xinetd restart
Related
nrpe on azure server - nrpe-srvr, user nrpe, executing script /usr/local/naemon/libexec/check_curl_http.php I'll call it script
Desired output after ./script -U www.google.com:
Page OK: HTTP Status Code 200 - 11099 bytest in 0.** seconds | time=0.059 size=11099
I achieve the above output by running the script from root or nrpe
Running sudo -u nrpe ./script -U www.google.com returns:
Error in opening page! Err:Failed to connect to [ipv6 addr] Network is
unreachable
However running su - nrpe -c './script -U www.google.com' works with the desired result.
Naemon reports:
CHECK_NRPE: Socket timeout after 30 secs
Other NRPE checks to the same host are working, so I think it's something to do with user execution of this specific script. I did have a deny from SELinux, but adjusted the context. Removing the context and setting SELinux to permissive yielded the same error. Enabled NRPE Log files, with debugging, but other than Running command it doesn't really reveal much. There is a:
WARNING: my_system() seteuid(0): Operation not permitted
in the logs, but looking at the support documentation that is "Normal" behavior.
I'll post this just in case someone else has this issue, and I'll tag Azure / AWS.
Essentially, cloud providers (mostly) have an internal proxy that is stored in an environment variable http_proxy && https_proxy. NRPE by default doesn't use load environment variables. Now I don't know if there is an option for it (it's mentioned in the docs that there is a bug when using uid instead of username (was using username)) however it's simple enough to call proxy for checks like this.
When I had installed Jenkins on Amazon Linux AMI following steps mentioned in http://bhargavamin.com/how-to-do/install-jenkins-on-amazon-linux-aws/
After installation I was able to open Jenkins through browser but when I selected option "Install Plugins" it showed error as "Unable to connect to Jenkins Server."
So then how to troubleshoot this issue??
The problem here is pretty simple, if you do curl http://127.0.0.1:8080 on your host machine, you should get a message stating:
Authentication required
<!--
You are authenticated as: anonymous
Groups that you are in:
Permission you need to have (but didn't): hudson.model.Hudson.Administer
-->
This means that jenkins has anonymous priviledges which is not allowing any connection.
To solve this issue, you will have to do two changes:
Add Jenkins user to root group: sudo usermod -a -G root jenkins
Make Jenkins listen to all external IPs by editing file /etc/sysconfig/jenkins and changing the JENKINS_LISTEN_ADDRESS="0.0.0.0"
Once this is done, restart the jenkins server and then try to install plugins for jenkins.
I'm using this trick https://issues.jenkins-ci.org/browse/JENKINS-45388 and it works. What I did is add passwd: as prefix of file /var/lib/jenkins/secrets/initialAdminPassword and click retry button for several times and finally it works.
Updating java-1.7.0-openjdk to java-1.8.0-openjdk will do the trick and restart the jenkins service or else change the port number and try it.
I got the same error on my ubuntu VPC, here is how I solve Unable to connect to Jenkins issue.
In my VPC Nginx is installed. Nginx is listening on port 80 so you need to open the firewall to that port as well.
To open the firewall use the following command:
sudo ufw allow 80.
And run this command sudo ufw status to verify the firewall is opened for port 80
After that, you can get the default web page for Nginx by using your_public_ip:80 and Jenkins by entering your_public_ip:8080.
1.Click on retry
2.Fill admin user name, pwd ,mail, full name
3.If filled already use pwd given in initialAdminPassword folder
4.proceed
When I do "ssh -X abcserver", I got message "X11 forwarding request failed on channel 0".
I checked online and it was suggested to solve it by switching "X11UseLocalhost no" to "X11UseLocalhost yes".
However, both my manager and I don't have this administrative privilege. I am wondering, except this solution, whether there is another option to solve the issue ? I also don't have sudo privilege to directly install X11 on the server.
My local platform is:
Linux version 3.16.0-4-amd64 (debian-kernel#lists.debian.org)
(gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02)
The remote platform is:
Linux version 3.13.0-88-generic (buildd#lgw01-16)
(gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) )
#135-Ubuntu SMP Wed Jun 8 21:10:42 UTC 2016
Adding the -v option to ssh when trying to log in will give a lot of debug information which might give a clue to exactly what the problem is, like for instance
debug1: Remote: No xauth program; cannot forward with spoofing.
which in my case installing xauth on the server fixed the issue.
I had to edit the sshd config file on the remote server to fix the issue. It worked on Ubuntu 16.04 Server:
$ sudo vim /etc/ssh/sshd_config
Set `X11UseLocalhost no`
Save the file.
$ sudo service sshd restart
$ exit
Now it works!
$ ssh -X user#remotehost
$ xclock
sudo apt install xauth
change the line #AddressFamily any to AddressFamily inet in /etc/ssh/sshd_config
sudo service ssh restart
This is enough on Ubuntu 18.04 LTS.
After login with ssh -X (or after activating the PuTTY / KiTTY option "Enable X11 forwarding") you should see that the environment variable DISPLAY is automatically defined to localhost:10.0 or similar. After first successful login (with a functional X11 forwarding) the file .Xauthority will be generated. Another positive sign of success.
If you are interested to see and to understand the details of X11 forwarding within your session you can try with lsof -i -P|grep ssh.
1.make sure that during ssh -X root#server you have root permission.
2.update the /etc/ssh/sshd_config and make sure this line is uncommented
X11Forwarding yes
3.systemctl restart sshd
4.exit from server
5.ssh -X root#server
6.virt-manager
In my case, as superuser, editing /etc/ssh/sshd_config on the remote host and changing the following line fixed it.
From
#X11Forwarding no
to
X11Forwarding yes
Then: pkill -HUP sshd on the remote host to make sshd reload its config, which also closes the sshd session.
After X11 forwarding suddenly stopped working after no other changes than moving the ssh server to another wifi, I followed the answer to this seemingly completely different question and it worked.
In other words, it seems the solution for me was to specify AddressFamily inet in /etc/ssh/sshd_config.
I am using SSH Secure Shell to connect to a server. My connection is allowed to Tunnel X11 connections but when I execute the command. The display is not showing up. I get the message:
couldn't connect to display "localhost:12.0"
I have a ssh server installed and running on my machine.
Remember: Both the client and the server have to allow X forwarding.
On the server look in /etc/ssh/sshd_config and make sure you have X11Forwarding yes. You will need to restart the service if you edit this file.
On the client look in /etc/ssh/ssh_config (your user ~/.ssh/ssh/config will override global settings, if you have created this file) and make sure you have ForwardX11 yes.
Alternatively give the -X switch when you create your client connection. e.g. ssh -X user#host
Oh and of course, your client needs to be running an X server which you have authority to use! E.g. if you connect from Windows using PuTTY it will never work, as Windows is not an X server!
I figured it out. I needed to have X-Server installed on my computer instead of SSH-Server. I installed Xming for that purpose and now everything works as it should.
I work at an organization with stringent security requirements, sometimes excessively so. My project team is trying to create an SVN repository, and we are having difficulties setting one up to comply with both our needs and our security requirements.
Our IT department requires us to authenticate ourselves with two-factor authentication. Each developer has an RSA token that must be used to log in to the repository host machines via SSH. The value displayed on the token changes once per minute and each value can be used only once.
The developers require the capability to store passwords. This prevents us from using svn+ssh to log in to the repository. Since the RSA token changes once a minute, we can't store the SSH passwords. Worse, the RSA token would reduce us to one SVN operation each minute. This is flatly unacceptable, especially since we have scripts that chain multiple SVN operations together.
We attempted to compromise by opening an SSH tunnel with port forwarding. We would open up a tunnel using ssh user#hostmachine -L 3690:localhost:3690 to forward all SVN requests on our local machine to the secure machine, where an svnserve process was running. This meant we could log in with two-factor authentication, and then use a separate SVN username and password (which could be stored) with our utilities.
Unfortunately, we noticed that we didn't need the tunnel; port 3690 was available to any computer for whom the hostname was visible. This is unacceptable to IT, and our sysadmin thinks that svnserve is the problem, so she is wondering if we have to go back to svn+ssh.
Is there any solution that works? Is our sysadmin correct? Is there an option on svnserve that will force it to listen only to traffic from localhost?
use:
svnserve -dr /my/repo --listen-host 127.0.0.1
This way the service will only listen on the loopback interface. When you connect with ssh use:
ssh -L3690:127.0.0.1:3690 user#svnserver.mycompany.com
also see:
vince#f12 ~ > svnserve --help
usage: svnserve [-d | -i | -t | -X] [options]
Valid options:
-d [--daemon] : daemon mode
-i [--inetd] : inetd mode
-t [--tunnel] : tunnel mode
-X [--listen-once] : listen-once mode (useful for debugging)
-r [--root] ARG : root of directory to serve
-R [--read-only] : force read only, overriding repository config file
--config-file ARG : read configuration from file ARG
--listen-port ARG : listen port
[mode: daemon, listen-once]
--listen-host ARG : listen hostname or IP address
[mode: daemon, listen-once]
-T [--threads] : use threads instead of fork [mode: daemon]
--foreground : run in foreground (useful for debugging)
[mode: daemon]
--log-file ARG : svnserve log file
--pid-file ARG : write server process ID to file ARG
[mode: daemon, listen-once]
--tunnel-user ARG : tunnel username (default is current uid's name)
[mode: tunnel]
-h [--help] : display this help
--version : show program version information
svnserve might have options to only listen on localhost, but this sounds like a firewall configuration issue.
If port 3690 isn't meant to accessible externally, it should be blocked by the firewall. It shouldn't matter whether svnserve or anything else is listening on that port. svnserve can then continue to listen on 3690, but will only receive connections from localhost because others are blocked by the firewall.