I’m looking for a way to see if the SSH host key has changed on a monitored host. In our environment, it’s somewhat common to change which Docker is using port 22, or whether the host system is using 22 or some other port. It would be nice to deploy a set of rules across 5 servers to watch if a host key changes so we know everything has seen a change, or similarly, if we need to fix something.
Another benefit of course is seeing if a host key unexpectedly changes, possibly indicating a hijacking/MITM attack.
If anyone can suggest a solution, I’d love it!
Thanks!
EDIT: To clarify, I want to be able to see FROM a host TO a remote SSH server.
Hallo,
don t know if I ve understand your question but doesn t an file age check solve your problem.
If keyfile older than X last change didn t work.
Ralf
Whenever you connect to an SSH server, your client is presented with a host key (basically a public/private key pair). The first time you connect to the server, your client will ask you to cache the key presented. If a different key is ever sent from that IP/port, your client will either prevent or warn you.
What I’m hoping for is a check that will change states when a host key changes. So I can have the check connect to a remote host and request the key, then CMK will throw a warning if it sees the requested key is different than configured.
EDIT: To clarify, I want to be able to see FROM a host TO a remote SSH server.
So just to be 100% gold plated sure: You want to observe if the host keys for a remote host have changed?
As something built-in to checkmk server, I’m not sure. But, if you have a central host that you can poll the others from, then this is fairly easy to do as a local check. For example you could use ssh-keyscan to pull in remote keys, store them somewhere and compare them to subsequent runs. Mismatch = fail = alert.
Even simpler would be to use StrictHostKeyChecking and let ssh warn you…
We tumbled the thought of doing ssh-keyscan and comparing against previous results, but then the ability to deploy changes easily goes away (though, I guess this is mitigated when we purchase Enterprise and get the Bakery).
This would be awesome if the CMK added host key checking into the check_ssh check.
Once 1.7 comes out (and we purchase Enterprise), I’ll likely write a check relying on ssh-keyscan (if no other solution is available by that point).
Let’s say one of our servers (HostA) has 8 different clients connect to it. All 8 clients have the CMK agent installed on it. Optimally, all 8 clients will occasionally connect to HostA to check if the host key has changed. If it has, we will see 8 CRITs appear in CMK.
If we use local checks, we now have to connect to 8 clients to reconfigure the local check. If it’s part of a plugin, we could configure (on the CMK server itself) what key should be seen and that rule would simply apply to each of the 8 clients.
I know it seems silly to monitor the same host key from many different locations, but this also allows us to see if an attack is being performed on a single server. For example, Client 8 is having its connections redirected to a different IP, but clients 1-7 all see the same IP.
I don’t know about you, but I would recommend you to use a configuration management software (puppet,ansible,chef, salt,…) to distributed the hostkeys amongst each other and then set StrictHostKeyChecking=yes
I guess I’m assuming you’re managing your plugins and local checks (puppet, ansible, etc.)
On the CEE side, there’s their agent “bundler” deployer as well. But if you’re already using some sort of CM device (like us), it’s easier for us to do things through it (we are migrating from puppet to ansible, both can do this).
I like the idea of using a CM, but rather for doing the checkmk plugin maint. But just keeping ownership/control over the platform keys via your favorite CM, might be enough for many environments.