Skip to main content

Hello,

Out of habit, I use check_by_ssh on most of my checks. It works very fine, but opens a new SSH connection for each check, and generate a lot of useless auth.log on clients, among other things.

So, I've started using check_by_ssh with the SSH connector. At first, I created symlinks for centreon-engine’s ed25519 ssh key, because connector only check for id_rsa (Is there a solution to directly use ed25519 ?) :

✓ h2024-05-22 13:45:50 +0200] centreon-engine@kepler k ~/.ssh ]
$ l
total 32
-rw------- 1 centreon-engine centreon-engine 419 Dec 27 2022 id_ed25519
-rw-rw-r-- 1 centreon-engine centreon-engine 104 Dec 27 2022 id_ed25519.pub
lrwxrwxrwx 1 centreon-engine centreon-engine 10 May 22 03:41 id_rsa -> id_ed25519
lrwxrwxrwx 1 centreon-engine centreon-engine 14 May 22 03:41 id_rsa.pub -> id_ed25519.pub

The connector works, but when a large enough number of checks are run at the same time, an error occurs on several of the checks, as if a limit had been reached:

  • Poller : /var/log/centreon-engine/connector-ssh.log:
>2024-05-22 04:26:07.211] 7core] [error] fail to open channel for creds:root@isengard.westeros.lan:22 for check 3877 Channel open failure (connect failed)
  • Client : /var/log/auth.log:
2024-05-22T04:26:07.210137+02:00 isengard sshdr209347]: error: no more sessions

For testing, I've already set a very high limit on MaxSessions and MaxStartups on my SSH server, but I can't see what any other limit I'm reaching that's causing this error…

 

Thank you for your help.

Hello,

 

maybe you can create a ~/.ssh/config and add this:

Host *
ControlMaster auto
ControlPath ~/.ssh/S.%r@%h:%p
ControlPersist 5m

IdentityFile ~/.ssh/id_ed25519

 

 

This should help to maintain the ssh connection open and reuse it.

 


Thanks @supervhs for your suggestion, it seems that the connector doesn't take the IdentityFile part into account, too bad, it would have avoided having a useless symbolic link.

It seems that setting MaxSessions to 100 (I've kept some slack in case I add probes), and setting MaxStartups to 120 is enough to have something "stable" once you've restarted all the client’s ssh services, killed the open connections, and killed the centreon_connector_ssh processes on the pollers.

Only pfSense in CARP is still causing me some problems despite these modifications...


@Nyxtorm did you try with:

 

    --ssh-priv-key
            Define the private key file to use for user authentication.
 


Hi,

 

maybe is some issue with your configuration, because I have distincs IdentityFile on my .ssh/config (one for each “datacenter/servers group”

/var/lib/centreon-gorgone/.ssh/config

Host *
ControlMaster auto
ControlPath ~/.ssh/S.%r@%h:%p
ControlPersist 5m


Host *.alice.com
IdentityFile ~/.ssh/id_ed25519_alice

Host *.boc.com
IdentityFile ~/.ssh/id_ed25519_bob

 

Note: On my case, I’m using gorgone, but if you are should be the same to any other system/account .

 

Note2: Try to connect by ssh with the account and check 

sudo su - centreon-engine

ssh host_address -vvv

 

It should show you what keys are trying to use and the reason why it is not working (Maybe it are trying to use the RSA first).


Hi @supervhs ,

Actually, I’m using centreon-engine user for my SSH checks, no problem with id_ed25519 used for a long time. Classic SSH authentication is OK as well. Problem for id_rsa occurs only if I enable the SSH Connector in my check command:

In this last case, if I look at /var/log/centreon-engine/connector-ssh.log, I can see:

b2024-05-22 03:21:16.324] .core] cerror] fail to authent with /var/lib/centreon-engine/.ssh/id_rsa.pub for root@naboo.westeros.lan:22 -16:Unable to open public key file

So, the SSH Connector (not SSH itself) seems to only check for id_rsa file. So I’ll keep my symlinks at least for a time… 😅


NOTE1 :

The SSH connector looks very interesting in terms of execution times and poller load. The left of the graph is with the connector, the right without:

 


Well, 

 

without a log (ssh -vv) as mentioned it is difficult to have a idea why the error.

 

See you


make sure the proper folder/file rights are there for the keys and the .ssh folder


The key and folder rights are correct and the key works as long as the Centreon check does not use the "SSH Connector" connector.

A connection via "ssh -vv" works fine as it doesn't use the SSH connector used by the Centreon command.

Maybe an option to update in the command in the check_by_ssh part, I'll check that, thank you for your answers.


Hi @Nyxtorm

Please remember to click the “Best Answer” button for the solution that helped you resolve your issue.
Alternatively, you can share with us how you were able to solve the problem.

By doing so, you'll help someone else with the same issue in easily finding the solution.

Thank you,


Reply