Hi dear community , I am quite a novice and I hope your indulgence in my first question about Icinga2 .
I wish to monitor my servers without using the Direktor module, I wish to monitor my servers in ssh and to be able to do it on servers only accessible in ssh by a private key / public key.
For example, on my icinga2 server, in /etc/icinga2/id_rsa I’ve entered my private key, my public key is the same on both the icinga2 server and the destination server. Can you help me determine where I should enter the information in icinga2?
I want to call this check check_by_ssh , I know how to configure the host in /etc/icinga2/conf.d/hosts.conf but how do I write this check? and where? in services.conf? templates.conf? Thank you very much
Hi & welcome,
On which distribution is the icinga server installed?
With which user you to login in your destination server(s)?
Icinga doesn’t care which object definition is placed in which file. However, you should not use files in /etc/icinga/conf.d since they might get overwritten by the package management and they are just examples.
yes, you’re absolutely right, I’m going to disassociate my hosts from the hosts.conf file, etc. My question is more about syntax, since for the moment I can’t do what I want to do, i.e. supervise a server accessible only with my key using ssh.
I use an ubuntu 20.04 distribution
I use a specific user, say sam , or even root
In Ubuntu icinga is configured to run as user nagios. Hence, your public key needs to be owned by nagios. You could leave it in /etc/icinga2, but best practice is to place in in the default directory which is .ssh in nagios’ home directory means /var/lib/nagios/.ssh/id_rsa. Following this best practice makes it obsolete to add information about the key in check_by_ssh`.
The public key could be easily copied and configured using ssh-copy-id <user>@<target> e.g. ssh-copy-id sam@x.x.x.x
You should check is the connection is working before assigning any check. One easy way to do so is to run on your icinga server sudo -u nagios bash and try to login to the destination system with ssh sam@x.x.x.x. Only if this works without any error or asking for password you are ready to use service checks.
As you will not have distributed deployment you can define any path for your conf files you want and add it via include_recursive to /etc/icinga2/icinga2.conf.
1 Like
Thank you, you’ve put me on the right track and indeed it led me to another path which was that of the rights assigned to my files containing the keys, I was in root my files did not have the right permissions 600 etc …
Despite all this, what I’m missing is the syntax I need to define to indicate the path to my private key, with arguments etc., so that a check_by_ssh_disk, for example, is recognized.
If you don’t place your private key in the default place, you need to add vars.by_ssh_identity = "/your/directory/id_rsa" to your host or service object(s).
Hello , thank you for your help , I’m trying an order that I define like this :
object CheckCommand "by_ssh_memory" {
import "by_ssh"
vars.by_ssh_command = [ PluginDir + "/check_memory" ]
vars.by_ssh_identity = "/etc/icinga2/ssh/id_rsa"
vars.by_ssh_logname = "sam"
In the GUI I still get the error L’exécution de la commande à distance Host key verification failed.
à échoué
Yet I have no trouble connecting via ssh from my icinga server to my test machine in sam@XXXXXX with no password required.
My private key in pem format is in etc/icinga2/ssh/id_rsa.
And for my host
object Host “test-check”{
import “generic-host”
check_command = “by_ssh_memory”
address = “XX.XX.XX.XX”
}
You could enable debuglog and check for any hints. You could also take the complete commandline and run it manually with verbose level increased.
BTW: You have defined a memory check as host check, that does not make any sense. Very common is hostalive instead.
Thanks Roland I appreciate your help but I’m really stuck.
I’ve tried debuglog , syslog , auth.log , all of which didn’t get me anywhere .
You tell me to use hostalive , I tell you that hostalive works perfectly , this machine accepting ping it has no problem as for basic checks like disk or ssh .
The problem is that I need to administer servers in a more complex and detailed way, such as “how many processes are running at the moment”, “what is the memory size and warn me when the load reaches this or that level”.
These servers use private and public keys to connect to them, and for this kind of detailed check I’ll necessarily need to use this key exchange.
The checks have to be done in ssh, which is what I’m asked to do, so I decide to put my key somewhere else than in nagios, despite having the right authorizations:
700 for the .ssh folder
640 for authorzed_keys ( public key)
600 for id_rsa ( private key )
Authorization on the GUI is invariably denied when I go through :
vars.by_ssh_identity = “/root/.ssh/id_rsa/”
vars.by_ssh_logname = “sam”
or another path with the same permissions, I’m refused
Thanks for your help
I would like to point out that I have no problem connecting via ssh after the command:
sudo -u nagios bash
ssh sam@XXXXXXXXX
Yes, because memory check as host command does not make sense at all. A memory check should be configured as service check.
Of course, user nagios does not have access rights for /root
Do you have XXXXXX exactly configured the same in icinga? Are you using ip address, short name or FQDN? It needs to be identical in icinga as well as on command line.
When you check debug.log you’ll find something like:
[2023-08-25 11:51:24 +0200] notice/Process: Running command ‘/usr/lib/nagios/plugins/check_by_ssh’ ‘-C’ ‘’/usr/lib/nagios/plugins/check_load’ ‘-c’ ‘10,6,4’ ‘-w’ ‘5,4,3’’ ‘-H’ ‘XXXXXXXX’ ‘-l’ ‘sam’: PID 1005345
You could then sudo to user nagios and manually run this command to get an error indication. You could add -v to the command to get more information.
Thanks for your invaluable help, in any case I had put it aside other tasks were assigned to me but I had the right inspiration this morning, I put my key in /etc/icinga2/conf.d and it works, thank you.
And if you want to put your key somewhere else, you have to give your private key nagios user and group rights, if that helps anyone later.