[Debian 8] Superviser un serveur Linux via SSH avec Shinken

La création d’un nouvel hôte à superviser peut se faire dans le fichier « hosts.cfg« , par défaut dans le dossier « /etc/shinken/hosts« . Vous pouvez en ajouter plusieurs à la suite dans un même fichier.

Il est toutefois préférable de différencier vos serveurs dans des fichiers indépendants, pour garder une organisation claire dans vos fichiers.


Partie machine (cliente) supervisée

Une première étape préliminaire consiste à s’occuper du SSH – Il faut configurer le SSH sur les machines supervisées et le serveur de supervision.
Rappelez-vous que le serveur Shinken utilise le compte « shinken » pour lancer des commandes, il faut donc créer un utilisateur « shinken » (peu import le mot de passe) sur les machines à superviser.

useradd shinken

Une fois l’utilisateur créé et son mot de passe attribué, il faut préparer le serveur de supervision et effectuer une première connexion (échange de clé) via SSH.


Partie serveur de supervision

Connectez-vous avec l’utilisateur « Shinken » sur votre serveur de supervision, puis générez sa paire de clé SSH.

su shinken
ssh-keygen

Par défaut, la paire de clé va se créer à la racine du home de l’utilisateur dans un dossier caché, soit (dans notre exemple) « /home/shinken/.ssh/« . Le fichier s’appelle « id_rsa« . Lors de la génération de la paire de clés, vous pouvez modifier l’emplacement et le nom des clés.

Vous devez copier cette clé sur le serveur de supervision – pour pouvoir se connecter et effectuer la supervision matérielle, Shinken se connecte via le compte « shinken » sur la machine distante avec sa clé RSA.

ssh-copy-id -i /home/shinken/.ssh/id_rsa.pub shinken@srv_supervisé

Cette commande copie la clé RSA de l’utilisateur « shinken » de la machine cliente sur le serveur de supervision, dans le compte « shinken » distant (donc du serveur de supervision). Ainsi, la connexion pourra se faire via SSH, notamment par l’échange de clés.

Pour tester si la connexion est opérationnelle, allez sur votre serveur de supervision, puis connectez-vous sur la machine distance (à superviser) via SSH et l’utilisateur « shinken »

ssh shinken@ip_server_supervisé

Vous devriez vous connecter sans mot de passe, puisque la négociation s’est faite avec les échanges de clés.


L’échange de clés SSH étant effectué, il faut définir un nouveau serveur Linux à superviser via SSH dans Shinken. Ce fichier doit être créé dans le dossier « /etc/shinken/hosts » et avoir l’extension « .cfg » (par exemple, « srv01.cfg ») :

define host {
 use linux-ssh ; Template SSH utilisée par Shinken pour superviser
 host_name srv_supervisé ; Nom de l'hôte qui apparaîtra dans la dashboard de Shinken (webUI)
 alias Serveur linux client ; Rapide description de l'hôte -- FACULTATIF
 address 192.168.51.145 ; Adresse IP ou nom FQDN de l'hôte
 hostgroups srv ; Nom du groupe auquel appartient l'hôte -- FACULTATIF
 contact_groups admins ; Nom du groupe des contacts (pour les notifications)
}


Explications :

  • define host { : Définition d’une nouvelle machine à superviser ;
  • use linux-ssh : Il faut utiliser le template « linux-ssh » pour effectuer les contrôles via SSH ;
  • host_name nom_server : Vous devez définir le nom de la machine supervisée – Ce nom sera utilisée pour repérer plus facilement les machines dans l’interface web de Shinken d’une part, et de pouvoir utiliser ce nom pour créer et gérer des groupes de serveur (hostgroups), diverses hiérarchies etc…
  • alias Serveur linux client : Une petite description de votre poste supervisé, des notes complémentaires... – FACULTATIF –
  • address 192.168.51.145 : L’adresse IP de la station / du serveur supervisé.
    Il n’y a pas besoin de mettre un port spécifique, d’utilisateur ou autre informations – Seulement l’adresse IP de la machine à superviser.
  • hostgroups srv : La définition d’un « hostgroups » permet de grouper certains serveurs à superviser ensemble et ainsi, envoyer une série de commandes à ce groupe (et donc à tous les serveurs du groupe), de « classer » les serveurs et ainsi créer une hiérarchie… – FACULTATIF –
  • contact_groups admin : Le groupe des contacts permet d’envoyer des notifications à toutes les personnes dans le groupe saisi.

Pour prendre en compte les modifications, redémarrez le module « shinken-arbiter » (systemctl restart shinken-arbiter)

Pour tester un script de supervision via SSH, vous pouvez lancer ce type de commande :

/var/lib/shinken/libexec/check_ssh_connexion.py -H ip_server_supervisé -i /home/shinken/.ssh/id_rsa

Le résultat devrait être retourné de cette façon (à titre indicatif) :

OK: connexion is good

D’autres commandes peuvent être passées pour récupérer les stats, comme la mémoire :

/var/lib/shinken/libexec/check_memory_by_ssh.py -H 192.168.184.130 -i /home/shinken/.ssh/id_rsa

Dans l’interface web, voici le résultat :

Des erreurs sont présentes, elles vont être réglées par la suite.

 

Merci à Maxence et Cédric pour les précisions via leurs commentaires ! 😉

Julien H

Passionné depuis toujours par l'informatique, je transforme ma passion en expertise. J'utilise quotidiennement les outils et systèmes Microsoft. Je ne délaisse pas mon côté ouvert, notamment via l'utilisation des OS Debian et Archlinux. L'infosec m'ouvre les yeux sur les enjeux actuels et futurs de l'IT.

6 commentaires

    1. Hello !
      Cet article a été saisi pour superviser le serveur localhost (ici, mon serveur Shinken) via SSH – En effet, il faut effectuer un échange de clés pour les autres machines – Je vais peaufiner cet article et saisir la suite de ce pas… 😉

      – EDIT le 18/06/2015 – 22h45 : Article modifié en conséquence. Merci pour la remarque Maxence !

  1. Bonjour,

    En théorie, on génère la clé SSH sur le **serveur Shinken** (et non sur l’équipement supervisé) et on copie la clé SSH **publique** (et non privée) sur l’équipement supervisé.

    C’est plus logique dans ce sens car on a généralement un seul serveur de supervision pour superviser plusieurs dizaines d’équipements. Dans ce cas, il suffit de copier la clé **publique** sur tous les équipements supervisés.

    1. Bonjour Cédric,
      Merci pour la remarque ! Pardonne-moi pour la lenteur de ma réponse… J’ai modifié mon article en conséquence pour tenir compte des remarques, après avoir re-testé sur mes VM.

      1. Hello

        Ce que propose Cedric est tres dangereux. Car celui qui possede la clef a le droit de communiqué avec le central. C’est donc à proscrire.

        1. Hello,

          Non, absolument pas et heureusement d’ailleurs ! La configuration que j’indique permet au serveur de supervision de se connecter à tous les serveurs. Mais connaître la clé publique SSH d’un compte utilisateur sur un serveur ne permet pas de s’y connecter !

          Par contre, j’admets qu’il y a quelque chose de dangereux : si le serveur de supervision est compromis, toute l’infra est compromise.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Fermer
Fermer