Contexte

Cette page a pour but de décrire la mise en place d'une configuration minimale nécessaire pour un Linux supervisé par le pack linux_by_ssh

Comment configurer la connexion SSH ?

Pour l'exécution correcte des commandes du pack linux_by_ssh, vous aurez besoin d'une connexion SSH.

Quelques informations au préalable sont nécessaires pour la bonne compréhension de cette partie.

• D'une part, du côté de l'architecture Shinken, l'exécution des checks ( plus exactement les sondes ) sont réalisées par les Pollers, en tant qu'utilisateur "shinken".
  • Donc l'utilisateur "shinken " devra avoir accès aux clefs SSH que vous utiliserez pour la connexion SSH sur les serveurs distants monitorés.
• D'autre part, du côté des machines Linux supervisées,
  • un nom d'utilisateur, et une clé SSH ou mot de passe sont requis.
  • Dans le modèle linux_by_ssh, des données sont prévues à cet effet.

Nous conseillons l'utilisation d'un utilisateur spécifique ( pour le service de supervision ) ainsi que l'utilisation d'une connexion via clé SSH, afin d'éviter l'utilisation du super utilisateur root qui n'est pas requis par les checks.

Côté client ( machine ou serveur Linux supervisé )

Si votre utilisateur de supervision n'est pas déjà créé sur votre linux à superviser, depuis un terminal de la machine supervisée "linux-1" ( en root ), il faut créer un nouvel utilisateur local avec mot de passe.

• dans cet exemple, nous utilisons "user-service-shinken" mais vous pouvez créer un autre utilisateur.

                [root@linux-1 ~]# useradd -m -r -k /dev/null -s /bin/bash user-service-shinken
 [FACULTATIF] : [root@linux-1 ~]# passwd user-service-shinken

• '-m' : Permet la création d'un répertoire /home/user-service-shinken.
  Necessaire afin que le fichier '/home/user-service-shinken/.ssh/authorized_keys' existe et autorise les connexions.
• '-r' : Spécifie que l'utilisateur créé sera un compte de système.
  Cela n'a pas d'influence direct sur le comportement du pack, mais permet de catégoriser le compte créé.
• '-k /dev/null' : Spécifie qu'aucun dossier squelette doit être utilisé pour créer le dossier principal de l'utilisateur.
  Par défaut '/etc/skel' est utilisé comme dossier squelette.
  Spécifier '/dev/null' permet que le nouveau dossier principal de l'utilisateur créé soit vierge de tout fichiers, notamment de .bashrc qui peuvent altérer la bonne exécution du check.
• '-s /bin/bash' : Spécifie le shell à executer par defaut lorsque l'utilisateur se connecte. Notamment lors d'une connection SSH.
  Bash est choisi comme shell par défault pour s'assurer d'une execution standard des checks du pack.

Côté serveur Poller

Copie de la clé SSH de votre utilisateur de supervision "shinken" depuis le serveur Poller "shinken-poller" ( pour cet exemple ), vers le serveur supervisé "linux-1" pour l'utilisateur "user-service-shinken" ( dans cet exemple, IP : 192.168.1.19 ) 

Copie clé SSH via commande ssh-copy-id

Soit via la méthode "automatique" via la commande ssh-copy-id en se connectant au préalable via l'utilisateur shinken sur le ou les serveurs pollers :

[root@shinken-poller ~]# su - shinken
[shinken@shinken-poller ~]#  ssh-copy-id -i ~/.ssh/id_rsa.pub user-service-shinken@linux-1
The authenticity of host '192.168.1.19 (192.168.1.19)' can't be established.
RSA key fingerprint is 00:ff:ee:dd:cc:bb:aa:d6:d3:79:1d:f6:93:47:80:27.
Are you sure you want to continue connecting (yes/no)? yes
user-service-shinken@linux-1's password: XXXXXXXXXXX
Now try logging into the machine, with "ssh 'user-service-shinken@linux-1'", and check in:
  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Copie clé SSH via commande ssh

Soit via une commande SSH depuis le serveur Poller, il s'agit d'ajouter la clé publique au fichier "authorized_keys" du serveur supervisé ( ici linux-1 ) :

cat /var/lib/shinken/.ssh/id_rsa.pub | ssh root@linux-1 "cat >> /home/user-service-shinken/.ssh/authorized_keys"

Ici la connexion se fait via l'utilisateur root du serveur linux-1 ( mais vous pouvez utiliser votre propre utilisateur ), le but étant de rajouter, en une commande SSH, la clé de l'utilisateur shinken du Poller /var/lib/shinken/.ssh/id_rsa.pub à la fin du fichier /home/user-service-shinken/.ssh/authorized_keys du serveur supervisé.

Copie clé SSH manuellement

Soit via méthode "manuelle" via rajout de la clé dans le fichier authorized_keys

• Récupérez la clé publique de l'utilisateur qui va établir la connexion SSH, et la copier

  [root@shinken-poller ~]# su - shinken [-bash-4.1]$ cat .ssh/id_rsa.pub -> copiez la clé

• Connectez-vous sur le serveur linux supervisé avec votre utilisateur de supervision et collez cette clé dans le fichier "authorized_keys" de l'utilisateur de supervision :

  [root@linux-1 ~]# su - user-service-shinken [-bash-4.1]$ vi .ssh/authorized_keys -> collez la clé

Test de connexion

Test de connexion au serveur "linux-1" en tant qu'utilisateur "user-service-shinken" via l'utilisateur du Poller ( shinken ) :

[root@shinken-poller ~]# su - shinken
[shinken@shinken-poller ~]# ssh user-service-shinken@linux-1 -i .ssh/id_rsa

La connexion doit s'établir avec succès.

Problème de connexion : regarder dans les logs

Si la connexion échoue, les logs du service "sshd" peuvent donner des indications précieuses sur la cause de l'échec. La méthode de consultation de ces informations dépend de la distribution utilisée et de son ancienneté.

Ci-dessous, la liste non exhaustive des méthodes connues pour consulter les logs, sur les distributions officiellement supportées par Shinken :

Pour Redhat / Almalinux / Rockylinux / Centos :

• la commande journactl permet d'afficher les logs du service :

  journalctl -xf -u sshd

• Le fichier de log "secure" contient les informations concernant les dernières connexions :

  cat /var/log/secure

Pour Debian :

• la commande journactl permet d'afficher les logs du service (le nom de service utilisé n'est pas le même que pour les autres distributions) :

  journalctl -xf -u ssh

Ces logs permettent, entre autres, de savoir :

• Si le problème de connexion provient du client ou du serveur.
• Si les algorithmes de chiffrement utilisés sont cohérents entre les serveurs et permettent l'établissement de la connexion. 
• Si les droits attribués aux répertoires contenant les clés d'authentification sont les bons.

Exemple :

Dans l'exemple ci-dessous, les droits n'ont pas été correctement appliqués au répertoire de Shinken contenant les clés SSH. La connexion n'a pas pu s'établir 

[root@alpachouette-shinken01 shinken]# journalctl -xf -u sshd
-- Logs begin at Wed 2025-09-03 14:44:35 CEST. --
Sep 04 15:32:21 shinken-server sshd[1372868]: Authentication refused: bad ownership or modes for directory /var/lib/shinken/.ssh
Sep 04 15:32:21 shinken-server sshd[1372868]: Connection closed by authenticating user shinken 172.17.0.37 port 48152 [preauth]
Sep 04 15:32:25 shinken-server sshd[1372968]: Authentication refused: bad ownership or modes for directory /var/lib/shinken/.ssh
Sep 04 15:32:25 shinken-server sshd[1372968]: Connection closed by authenticating user shinken 172.17.0.37 port 48160 [preauth]
Sep 04 15:32:25 shinken-server sshd[1372971]: Authentication refused: bad ownership or modes for directory /var/lib/shinken/.ssh

Côté interface de configuration

Dans chaque hôte héritant du modèle d'hôte "linux_by_ssh", "linux_by_ssh_advanced" ou "linux_by_ssh_extra",

• vous aurez 4 données concernant la connexion SSH ( SSH_KEY, SSH_KEY_PASSPHRASE, SSH_PORT, SSH_USER )
• Ces 4 données seront par la suite utilisées par tous les checks.
  • Par défaut, ces données sont configurées pour utiliser des variables globales défini par défaut dans le fichier /etc/shinken/resource.d/ssh.cfg ( sur le serveur central hébergeant l'Arbiter ).
  • Si vous souhaitez les changer globalement,
    • vous pouvez modifier le fichier "/etc/shinken/resource.d/ssh.cfg",
    • ou faire vos propres modèles qui héritent des modèles d'hôtes proposés par ce pack en surchargeant ces 4 valeurs ( ainsi vous aurez vos propres valeurs par défaut ).

Par exemple, voici le paramétrage d'une connexion via Utilisateur/Mot de passe :