We use the SSH tunnel method to poll our devices for checkmk. Have done it for ages and we’re updating to 2.X (and going enterprise) but I’m seeing an error that I can’t figure out. The SSH rule command looks like this:
So it uses ipv4 and the user “root”. I can run this command as user “primary” and it runs perfectly (I see the expected output and remote client logs show connection from root) but when it’s run by checkmk it fails and the client side logs show user “primary” tried too.
Checkmk web status detail on services of host page:
Remote command execution failed: primary@[REDACTED]: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
I’ve also tried adding root@ but doesn’t seem to matter.
There is currently only one rule for ssh tunneling (unless one is built in and I didn’t see it). I added this one myself and then associated it with this singular host. Currently our deployment is greenfield.
In your screenshot → @root<HOST>
Should be → root@<HOST>
I would also remove the “-l root”
But as @robin.gierse said do this for the special agent call and not the SSH active check.
→ Setup → Other integrations → Individual program call instead of agent access
In my case the SSH calls looks a little bit more simple there.
ssh -oStrictHostKeyChecking=no root@$HOSTADDRESS$
This works if the used key is inside ~/.ssh/ in a well known name.
On the other side the public key is stored with “command=/usr/bin/check_mk_agent”.
So i don’t need to specify this also and i get a more secure key as i get no normal shell on the remote machine.
In our previous configuration it wasn’t in that rule section. I did try it just now and it’s not running at all there tho.
I did double check our previous setup and it appears it was in “Individual program call instead of agent access” which I’ve added it to but currently not able to get a valid discovery/poll. I’ll continue to dig. The UI has changed a bit so I’m not entirely familiar with it.
I did check the cmk -D for the host to check the “type of agent” used and did manage to get the settings correct where it shows the ssh tunnel command.
checkmkagenttest01.[REDACTED]
Addresses: [REDACTED]
Tags: [address_family:ip-v4-only], [agent:all-agents], [checkmk-agent:SSH], [criticality:prod], [ip-v4:ip-v4], [networking:lan], [piggyback:auto-piggyback], [site:primary], [snmp_ds:no-snmp], [tcp:tcp]
Labels: [org:cisd]
Host groups: check_mk
Contact groups: all
Agent mode: Normal Checkmk agent, all configured special agents
Type of agent:
Program: ssh -o ConnectTimeout=30 -o BatchMode=yes -oStrictHostKeyChecking=no -4 -l root -i /omd/sites/primary/checkmk.key checkmkagenttest01.[REDACTED] check_mk_agent
Process piggyback data from /omd/sites/primary/tmp/check_mk/piggyback/checkmkagenttest01.[REDACTED]
Services:
checktype item params description groups
--------- ---- ------ ----------- ------
And got it working.
The key to get it to show up as the agent was to change the agent/api integration option here (as well and make sure the ssh tunnel option I previously listed was still set.)
Aye, there was a bit of a copy/paste issue with the @root versus root@. That was after the -l root didnt work but turned out to be another issue (agent settings) so the root@ I removed and went with -l root.
Is there a reason to use root@ instead of -l root? Or will either be just as good?
Thanks for the help, still getting used to the newer UI changes but really liking how things work.
I think for the normal SSH call there is no difference. It is like most Unix/Linux commands you can do it different ways in the end it must work
In my environments is prefer the user@ to clearly see what user is used but this is my personal preference.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
