Execute Checks on Linux maschines without Agent?

hello everyone, as i am new to checkmk and already achieved many things in the last 2 days while testing it…i have this one question which i wish it works.

we have i our company some old linux machines runing only some very sensitiv databases. so i should not install an agent or anything else on them. instead i need to monitor some services and existing files using ssh connection.

is it possible without an agent at all, to tell checkmk to create an ssh session and execute a bash script that i wrote and deliver me the output - like icinga - ? i found the check via ssh service section but there is nothing mentioned in docs.checkmk about it so i can implement it. Would someone like to show how its done if its possible? thank you very much-

Yes, it is. And it is quite easy. Create a datasource script that does a login on the machine, runs the command and then from output or return value creates a minimal Checkmk agent output like this. Here we create one so called local check that immediately can be added to monitoring and one section (“yoyodyne”) that needs a plugin on the CMK server:

<<<check_mk>>>
AgentOS: linux
<<<yoyodyne>>>
performance 53.0
<<<local:sep(0)>>>
1 "Yoyodyne performance" perf=53.0 Performance is worse than expected.

(for local checks: 0=OK, 1=WARN, 2=CRIT, 3=UNKN)

hi @ymez
check via ssh could work, but if people are fine with you placing a bash script and executing it via ssh, just use the agent via ssh:) It’s not part of the 2.1 documentation but I’m pretty sure it will still work.

This way, you don’t have to install the agent and have it running in the background you simply have the checkmk agent shell script installed but it only gets called when your checkmk hosts contacts it via ssh.

Gerd

1 Like

thank you for the reply. shall i use the check via ssh service for this? if yes where should i put the password for the ssh user?


or is it only accepting an ssh key?

thank you for the reply. this seems to be kind of workaround… but this would mean i should run an “not known” script., in this case the checkmk shell agent which is not allowed. Or i should study the shell agent from the scratch… which will be time consuming…

Hi Gerd,

we splitted the article on the Linux agent for 2.1. There is now a separate article on invocation via xinetd and SSH plus manual installation. If it’s possible to deploy the agent script and run it via SSH, it would probably be the easiest solution.

2 Likes

ok thank you. i will read the documentation and test it out.

correct, it is a “not known” script from your perspectice. But

  • it has been security audited
  • it doesn’t take any input from the outside
  • you only need to give your ssh user access to this one script, (i.e. limit access in the authorized_keys!) while using “check via ssh” you would have to give your user a proper login shell which is much more difficult to properly secure
  • it is still just a shell script, so anyone doubting what happens can check it out
2 Likes

In case you need full control, but you are able to install a shell script on the server, create your own agent script that produces minimal agent output as mentioned above and follow the rules for datasource via SSH. You also might take the “official” agent script and strip parts you don’t need.

1 Like

If I read that well the concern is not related to security but to add addition load or additional configuration complexity to these machines
The “Agent” is just a shell script which is scheduled by xinetd/inetd. Simple to install, consume almost no resources and very safe to run. Its not necessary to install a full package (rpm,deb etc.) The agent script and the xinetd/inetd configuration could be copied to the system. We do it that way with our AIX systems.
Scheduling the agent by ssh is more complex to setup and has also some security weaknesses. You cannot protect the private key with a password. If one get access to the private key he has access to the remote systems. As the agent and many other nagios plugins needs to be run with privileged account the risk is not acceptable for us.

Just my two cents

Michael

1 Like

Hi Mike,

it’s relatively easy to limit a key to just execute the Checkmk agent. So in cases where no additional ports should be opened or agent output can be useful for an attacker, SSH is an appropriate way (deeplink to the section):

@mschlenker Thank you, I didnt knew that.
Beside that a community member added this how to:

I agree that the symmetric encryption is not the perfect security measure.
Because of the I developed solutions to use GPG or OPENSSL:

1 Like

i did not really understand how this datasource works and how to make it really run … i even tried on a vm the shell agent…but have no idea how really to install it and in which folder to place the script…documentation seems somehow not complete…

so right now am using nagios plugins … wrote small bash script on a remote server and worte a second one in checkmk under nagios directory…so the checkmk runs his own script in nagios’s folder and execute the script on the remote server using ssh… but its not really a great solution because i have to write for every single check an own script and add it into the checkmk GUI manually as a nagios plugin…

How many services should be monitored on each of the “old Linux” hosts? Would it be suitable to install the Linux agent script to /usr/local/bin to run this via SSH? Or is this already too much of installation?

we have like 400 hosts and more than 200 are linux machines so … i would have to setup for each linux machine at least 4 checks…

OK, on the “old” Linux machines you mentioned above, start by “manually” deploying the agent script (and nothing more) as described her (deep link):

Proceed here by accessing it via SSH (deep link):

Then check the connections and add the host to the monitoring. The script already checks many common services.

You need more services, then add Checkmk plugins as described here (deep link):

Or add Nagios plugins as described here (deep link):

thank you i will check it out.

# Created by Check_MK Agent Bakery.
# This file is managed via WATO, do not edit manually or you
# lose your changes next time when you update the agent.


service check-mk-agent
{
        type           = UNLISTED
        port           = 6556
        socket_type    = stream
        protocol       = tcp
        wait           = no
        user           = root
        server         = /usr/bin/check_mk_agent
        log_on_success =
        disable        = no
}

Copy the agent script to /usr/bin/check_mk_agent and restart xinetd.
If you only have inetd I can send you config for this, just let me know.
regards

Michael

well … i have no permission to create the file under the /etc/xinetd.d
image

the root user is in the Demo Appliance disabled
image

These files has to be created on the monitored host and not on the monitoring server.
You wrote you have some old linux machines where you are not allowed to install new software.