Sommaire

Nagios : Supervision via SSH

Sur mon serveur en cloud sur lequel vous êtes actuellement, jusque là, je monitorais des choses qui pouvais se faire “à distance” comme :

  • L’accessibilité aux sites Web
  • La durée de validation du certificat SSL

Je me suis donc mis en tête de réaliser les mêmes “services checks” que les serveurs sur mon LAN.
Je cherchais donc un moyen de le faire de manière sécurisée (je ne souhaite pas que mes données circulent en clair sur le grand méchant Internet).
La solution était déjà sur mon serveur de supervision, celle du plugin check_by_ssh.

Principe

Le plugin permet d’en exécuter un sur un serveur distant et de récupérer le retour sur le serveur Nagios. La connexion distante s’effectue au travers d’une connexion SSH.

Pour que cela fonctionne, il faut réunir deux conditions :

  • Que l’utilisateur “nagios” puisse se connecter sur le serveur distant en SSH (de manière autonome)
  • Que les plugins Nagios soient disponibles sur le serveur superviser

Dans la suite de ce tutoriel, j’utiliserais le terme “serveur” pour évoquer le serveur Nagios et “hôte” pour le serveur supervisé distant (l’hôte à superviser).

Configuration SSH

Sur le serveur

On va donc faire le nécessaire pour réaliser une connexion SSH avec authentification par clé (donc pas de passphrase).
La connexion se fera sur l’hôte via un compte utilisateur dédié. On va donc créer un utilisateur (que j’ai appelé “nagios” sur l’hôte). On va lui donner les droits “sudo” pour qu’il puisse compiler les plugins Nagios.

On va donc maintenant générer la paire de clés SSH pour l’utilisateur Nagios du serveur. Tant qu’à faire, on en va faire une avec l’algorithme EdDSA.

1
2
sudo -H -u nagios bash
ssh-keygen -t ed25519

Ne mettez pas de passphrase ! La clé publique est alors contenue dans le fichier /home/nagios/.ssh/id_ed25519.pub et la privé dans /home/nagios/.ssh/id_ed25519.

Sur l’hôte

On créer donc l’utilisateur nagios. Lorque nous est demandé le mot de passe, il n’est pas nécessaire d’en mettre un.

1
  sudo adduser nagios

L’utilisateur n’a normalement pas besoin d’avoir les privilèges de super utilisateur mais cela peut-être le cas pour vous.
Si vous souhaitez le faire, il fait ajouté l’utilisateur au groupe _sudo _avec la commande : sudo usermod -aG sudo nagios
On édite donc les droits via la commande sudo visudo en ajoutant la ligne suivante dans le fichier :

1
2
  # Allow 'sudo' for user 'nagios'
  nagios  ALL=(ALL) NOPASSWD:ALL

On ajoute donc la clé publique de l’utilisateur “nagios” du serveur sur celui de l’hôte en copiant le contenu de sa clé publique dans le fichier /home/nagios/.ssh/authorized_keys. Ce fichier n’existe normalement pas par défaut, il faut donc le créer auparavant (ainsi que le dossier bien sûr).

On teste donc la connexion depuis le serveur en tant que qu’utilisateur nagios :

1
2
  sudo -H -u nagios bash
  ssh nagios@adresse_de_l_hote

On valide l’empreinte et ça devrait être bon.

Installation des plugins

L’installation des plugins étant déjà couverte dans mon tutoriel d’installation de Nagios, je fais ici simplement un copier-coller des commandes.

Donc, sur l’hôte :

1
2
3
4
5
6
7
8
sudo apt-get install gcc make
cd /tmp
wget https://nagios-plugins.org/download/nagios-plugins-2.2.1.tar.gz
tar xvaf nagios-plugins-2.2.1.tar.gz
cd nagios-plugins-2.2.1
sudo ./configure --with-nagios-user=nagios --with-nagios-group=nagios
sudo make
sudo make install

On teste la bonne compilation des plugins avec un check_dummy en local en tant que l’utilisateur nagios :

1
2
sudo -H -u nagios bash
/usr/local/nagios/libexec/check_dummy 0 TEST

On teste ensuite la même commande depuis le serveur avec check_by_ssh :

1
/usr/local/nagios/libexec/check_by_ssh -H adresse_de_l_hote -i /home/nagios/.ssh/id_ed25519 -C "/usr/local/nagios/libexec/check_dummy 0 TEST"

Intégration sur Nagios

Maintenant que l’on a un système fonctionnel, on va devoir créer les commandes et services nécessaires.

Commandes

Voici des exemples de commandes :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# Fichier /usr/local/nagios/etc/objects/commands.cfg

define command {
    command_name    check_ssh_disk
    command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -i $USER12$ -C "$USER1$/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$"
}

define command {
    command_name    check_ssh_load
    command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -i $USER12$ -C "$USER1$/check_load -w $ARG1$ -c $ARG2$"
}

La macro $USER12$ (dans le fichier ressource.cfg) contient le chemin de la clé privée de l’utilisateur “nagios”.

Services

De ce fait, les services associés sont de la forme suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
define service {
    use                             generic-service
    host_name                       HoteDistant
    service_description             Root Partition
    check_period                    24x7
    check_interval                  60
    max_check_attempts              3
    retry_interval                  2
    check_command                   check_ssh_disk!20%!10%!/
    icon_image                      camembert.png
}

define service {
    use                             generic-service
    host_name                       HoteDistant
    service_description             Current Load
    check_period                    24x7
    check_interval                  5
    max_check_attempts              3
    retry_interval                  1
    check_command                   check_ssh_load!5.0,4.0,3.0!10.0,6.0,4.0
    icon_image                      cpu.png
}

Voici donc pour les exemples.

Remarque_ : Si vous souhaitez faire des checks en SSH avec des plugins qui requiers une adresse IP, mettez donc _127.0.0.1_ ou encore _localhost_ dans l’option “-H” de la commande._

Cette procédure nous permet donc de monitorer convenablement notre serveur distant de manière sécurisé à travers le Net.