I am install checkmk monitoring tool are cloud Digital Ocean Droplet and I am monitor locally IT infrastructure like PCs, switches, cameras router etc. please provide me solution how can monitor
Why do you want to install the CMK in the cloud to monitor local infrastructure?
That makes no sense.
Thats not how this works in an opensource community. What did you do yourself until now? Did you read the documentation? Have you installed checkmk already? What are the issues you are facing?
1 Like
Actually we have multiple offices and we want to monitor all offices network using single cloud server.
Actually i just wana make sure if this is possible that we can moniter physical network via installing checkmk agent on cloud server ?
That is possible as long as the monitoring server can reach the target, say port 6556/tcp for the agent. You might as well install satellite instances[1] of checkmk in every branch office that will report back to the main instance in the cloud.
[1] Distributed monitoring - Scaling and distributing Checkmk
1 Like
Please don’t let OP think its a good idea to open port 6556 in the firewall in every office to every devices just so that he or she can monitor them from their cloud instance…
If all sites have VPN tunnels to their “cloud” then yes that is possible.
Hi,
As tboston says, it is possible. But also as Anders says you need VPN tunnels between checkmk server and agent environment.
We run that. We have the checkmk server in a cloud environment (only accessible with vpn client) and from there we have dedicated ipsec tunnels to our customer’s firewalls that allow the traffic between checkmk server and agents. We are right now testing with v 2.1 and so far it also works after opening up for port 8000 back to the checkmk server.
The other solution would be The distributed monitoring solutions as tboston also refers to.
I totally agree but for me, this is crystal clear and I would assume people know that. Not my fault if they don’t. 
In essence CMK can monitor any host as long as you allow the way in which you want to monitor it available ( like in port etc.)
CMK can (besides the usage of port 6556/xinetd) be made to do the same over SSH/key-authentication.
As long as you set up the key-trust, and limit the usage of the user logging in via this method (on Linux systems) with a customised entry in authorized_keys to only allow the check-command you should be safe (vpn or not).
In this way the SSH’ing of the monitoring host will not be able to execute more then just this one command :
#check_mk
command="/usr/bin/check_mk_agent" ssh-ed25519 <your trusted key here>
- glowsome
2 Likes
That is what OP wants. Interesting how you should SSH to these? Also opening up SSH directly to EVERY client on the entire corporate network is one of the most stupidest ideas I’ve heard. SSH is not safe, there have been multiple zero-day vulnerabilities in SSH
I am no security professional, so my insight here might be limited, but I have to speak up, as your comment is rather harsh. I do not entirely disagree with any of your points, but there can be vulnerabilities in any piece of software (even firewall firmware, which could affect your VPNs), so banishing SSH seems a little short-sighted to me. There are thousands of servers on the internet running publicly accessible SSH services, be it on port 22 or a custom port. If this was a terrible practice, we would see more servers compromised I assume. But of course “all the others do it” is not a good argument.
What I am trying to say is: Every possible way of monitoring with Checkmk has up- and downsides as well as security implications. You want to consider those before configuring anything.
Or even simpler: Don’t drink and root. 
3 Likes
How about setting up one Checkmk server in your cloud, and one Checkmk server per physical location. Then, using distributed monitoring, you can manage them centrally from your Cloud.
Maybe also keep an eye an the upcoming Checkmk Push agent configuration, that may lend itself well to hybrid cloud setups. Not sure here myself if licensing will allow it, etc. nonetheless, keep eye out.
1 Like
Also opening up SSH directly to EVERY client on the entire corporate network is one of the most stupidest ideas I’ve heard. SSH is not safe, there have been multiple zero-day vulnerabilities in SSH
Opening up any other (additional) port/protocol/service to handle it is equally unsafe as @robin.gierse mentioned.
What i meant (seeing your response that was not clear) is that opening up an additional port for monitoring purposes will create a potential additional attack-vector, with it’s own issues.
In my opinion SSH is a well-known protocol, meaning if flaws/exploits are found they are also quickly detected, and a solution is found/made.
For other ports/communication methods i am not that sure in how quick they are solved after being detected (as in 0-day’s)
Yes, i do understand that some equipment can not be monitored over SSH, as they just dont have that functionality, then the question is how much impact does it have to enable the monitoring regarding introducing new attack-vectors to an environment compared to the conveinience of having it monitored, just because you want to.
Additional motivations will be how ‘mission-critical’ it is to monitor those components compared to opening up a/the port/service on the firewall.
=> these are questions that need to be answered by a security-department and the stakeholder who wants this to be monitored.
To conclude, i do support the suggestion of @Marius_Pana2 to setup distributed monitoring for such cases.
1 Like
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.