NAGIOS – Supervision à distance avec SSH

Supervision avec SSH

1. Le principe de fonctionnement

Comme nous venons de voir dans la section précédente, l’utilisation de NRPE oblige les administrateurs système à installer un agent sur chaque serveur qu’ils veulent contrôler. Aussi NRPE ne dispose pas d’un moyen d’authentification sécurisé puisque l’authentification est basée sur l’adresse IP ou la plage d’adresses IP du demandeur. Pour s’en passer, les administrateurs peuvent utiliser le protocole SSH qui peut également faire l’affaire de NRPE.

SSH est un protocole de communication sécurisé permettant un échange chiffré et authentifié entre un serveur et un client. Il utilise le port par défaut 22. L’intérêt d’utiliser ce protocole pour la supervision des hôtes est de se débarrasser de l’installation d’un agent puisque SSH est généralement installé par défaut sur les serveurs Linux/Unix et aussi de sécuriser l’échange entre le serveur de supervision Nagios et l’hôte distant.

Nagios propose un plugin nommé check_by_ssh pour exécuter une commande sur un serveur distant en utilisant le protocole SSH. Ce plugin prend en entrée le nom de l’hôte et le nom de la commande à exécuter. Ensuite, il se connecte à l’hôte en utilisant le protocole SSH, lance la commande et retourne à la fois le message et le code de sortie du contrôle effectué sur la machine distante à Nagios. La connexion à travers SSH n’est autorisée qu’après l’authentification auprès du serveur distant. Manuellement, nous pouvons entrer un nom d’utilisateur et un mot de passe pour s’authentifier. Mais, ce n’est pas le cas si l’authentification doit être faite par le serveur Nagios. Pour remédier à ce problème, SSH dispose d’un mécanisme d’authentification par chiffrement asymétrique basé sur des clés publiques et privées que nous allons configurer dans la suite de ce chapitre. De cette façon, Nagios est capable de se connecter automatiquement à des serveurs distants avec SSH sans utiliser un mot de passe. Le diagramme suivant résume ce principe de fonctionnement.

images/ssh-1.PNG

2. Configuration de la connexion SSH

SSH dispose de plusieurs méthodes d’authentification. L’une de ces méthodes est l’authentification par mot de passe. À chaque fois que l’utilisateur veut se connecter à une machine, il doit saisir un nom d’utilisateur et un mot de passe corrects pour s’authentifier. Cette méthode est classique et aussi dangereuse car elle est vulnérable aux attaques par force brute (brute-force attacks). Il est vivement recommandé de désactiver l’authentification par mot de passe et permettre uniquement une méthode d’authentification plus sécurisée comme l’authentification par clés asymétriques. En utilisant cette méthode, l’utilisateur doit disposer d’une paire de clés, une publique et une privée pour s’authentifier. Généralement, la génération des clés sur les serveurs Linux se fait sans problème en utilisant le programme ssh-keygen disponible avec l’outil OpenSSH nativement présent dans les serveurs Linux. La démarche de l’authentification consiste à créer une paire de clés et à transmettre la clé publique au serveur distant. Ainsi, lorsque le client se connecte au serveur, la communication entre le serveur et le client est chiffrée par la clé publique. En utilisant la clé privée, le client sera en mesure de comprendre les messages du serveur.

Dans notre cas, la première étape consiste à générer une paire de clés pour l’utilisateur nagios sur le serveur Nagios. Nous aurons besoin d’exécuter la commande ssh-keygen avec l’utilisateur nagios.

su - nagios 
cd /usr/local/nagios 
ssh-keygen

La commande su – nagios suivi de la commande cd nous permet de se positionner en tant qu’utilisateur nagios dans le répertoire /usr/local/nagios.

Si aucune option n’est spécifiée avec la commande ssh-keygen, une clé RSA de 2048 bits sera générée. Si vous souhaitez utiliser une autre taille de clé, vous pouvez la spécifier avec l’option -b :

ssh-keygen -b 4096

Ensuite, le terminal renvoie un message qui contient une liste de questions auxquelles vous devez répondre en appuyant uniquement sur la touche [Entrée] du clavier.

Enter file in which to save the key (/usr/local/nagios/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /usr/local/nagios/.ssh/id_rsa.  
Your public key has been saved in /usr/local/nagios/.ssh/id_rsa.pub.  
The key fingerprint is: 
5b:57:f1:73:e1:89:b3:41:cf:34:12:e8:72:bc:c8:85 nagios@nagios-server 

Une fois générées, nous pouvons voir les clés de l’utilisateur nagios dans le répertoire /usr/local/nagios/.ssh.

ls -la 
total 16 
drwx------ 2 nagios nagios 4096 Mar 12 09:00 . 
drwx------ 4 nagios nagios 4096 Mar 12 09:00 .. 
-rw------- 1 nagios nagios 1675 Mar 12 09:00 id_rsa 
-rw-r--r-- 1 nagios nagios  419 Mar 12 09:00 id_rsa.pub

La clé privée est nommée id_rsa, et la clé publique est nommée id_rsa.pub.

Ensuite, nous avons besoin de configurer la machine distante pour qu’elle accepte la connexion SSH avec l’utilisateur nagios. Tout d’abord, nous allons créer un utilisateur et de groupe nommé nagios :

groupadd nagios 
useradd nagios -g nagios -d /usr/local/nagios

Maintenant, nous allons transmettre la clé publique id_rsa.pub vers la machine à superviser en écrivant cette clé dans le fichier authorized_keys que nous devons créer sous le répertoire /usr/local/nagios/.ssh dans la machine distante.

mkdir /usr/local/nagios/.ssh  
scp .ssh/id_rsa.pub user@machine_distante:/usr/local/nagios/.ssh/authorized_keys

Ensuite, il faut s’assurer que les permissions sont modifiées comme suit pour le répertoire .ssh et le fichier authorized_keys, car beaucoup d’implémentations de serveur SSH ignorent l’authentification basée sur des clés si les fichiers peuvent être lues ou écrites par d’autres utilisateurs sur le serveur.

chown nagios:nagios /usr/local/nagios/.ssh /usr/local/nagios/.ssh/authorized_keys 
chmod 700 /usr/local/nagios/.ssh  
chmod 600 /usr/local/nagios/.ssh /authorized_keys

Afin de configurer plusieurs machines pour être accessibles via SSH en utilisant l’authentification par clé, vous devez répéter les étapes mentionnées ci-dessus, à l’exception de la génération de la clé sur le serveur Nagios, car une seule paire de clés suffit pour accéder à plusieurs machines. Maintenant, nous avons bien configuré le serveur Nagios et le serveur distant pour établir une connexion SSH entre eux. Nous pouvons vérifier cette configuration en essayant de se connecter en SSH à la machine distante avec l’utilisateur nagios avec l’option verbose :

ssh -v nagios@192.168.16.5

Si tout va bien, vous devez être placé dans le répertoire /usr/local/nagios ; sinon, vérifiez les permissions sur les répertoires et fichiers de SSH et consultez les logs dans le serveur distant.

3. Contrôle à distance avec SSH

Nagios peut contrôler les services et les ressources des machines à distance en utilisant le plugin check_by_ssh. Le plugin check_by_ssh permet à Nagios d’exécuter le suivi des plugins et des scripts sur la machine de manière sécurisée en utilisant le protocole SSH. L’exemple suivant montre comment check_by_ssh peut être utilisé pour contrôler la charge sur un serveur Linux distant.

./check_by_ssh -H 192.168.16.5 -i /usr/local/nagios/.ssh/id_rsa -C 
  "/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20" 
 
OK - load        average:0.00,0.00, 00.00 
|load1=0.000;15.000;30.000;0;load5=0.000;10.000;24.000;0; 
 load15=0.000;5.000;20.000;0;

La commande utilise l’argument -C pour spécifier la commande à exécuter sur le serveur distant. L’argument -i précise la clé privée de l’utilisateur nagios autorisé pour se connecter SSH sur le serveur distant.

La commande est similaire à celle d’une commande shell sécurisé, sous la forme de :

ssh -i private_key machine_distant "command"

La commande encapsulée dans un appel check_by_ssh doit être sous la forme suivante :

check_by_ssh -H <host> -C <command> [-fqv] 
            [-1|-2] [-4|-6]  
            [-S [lines]] [-E [lines]] [-t timeout]  
            [-i identity] [-l user] [-n name] [-s servicelist]  
            [-O outputfile] [-p port] [-o ssh-option]

Voyons la signification de chaque option disponible avec check_by_ssh :

  • -H, –hostname : cette option spécifie l’adresse IP ou nom DNS de la machine distante.

  • -C, –command : cette option fournit le chemin complet entre guillemets de la commande à exécuter sur l’hôte distant ainsi que tous les arguments supplémentaires.

  • -l, –logname : cette option spécifie le nom de l’utilisateur autorisé pour se connecter en SSH sur une machine distante. Par défaut, la connexion se fait avec l’utilisateur nagios.

  • -I, –identity : cette option spécifie le chemin d’accès à la clé privée SSH à utiliser pour l’autorisation. Le chemin /.ssh /id_rsa est utilisé par défaut.

  • -p, –port : cette option spécifie le port pour se connecter via SSH ; par défaut 22.

  • -n, –name : cette option spécifie le nom court d’hôte utilisé dans la configuration de Nagios.

  • -s, –services : cette option spécifie la liste des noms de services Nagios séparés par des “:”.

  • -O, –output : cette option spécifie le chemin d’accès au fichier de commandes externes de Nagios.

  • -o, –ssh-option : cette option permet de passer des options spécifiques à SSH.

  • -q, –quiet : cette option permet d’empêcher SSH d’afficher des messages d’avertissement et d’information.

  • -t, –timeout : cette option spécifie le délai après lequel la connexion doit être terminée, les contrôles arrêtés et un état critique retourné ; par défaut 10 secondes.

  • -w, –warning : cette option spécifie le délai après lequel la connexion doit être terminée et un état d’avertissement doit être retourné.

  • -c, –critical : cette option spécifie le délai après lequel la connexion doit être terminée et un état critique doit être retourné.

  • -4 : cette option permet d’utiliser le protocole IPv4 pour la connectivité SSH.

  • -6 : cette option permet d’utiliser le protocole IPv6 pour la connectivité SSH.

  • -1, –proto1 : cette option permet d’utiliser la version 1 du protocole SSH

  • -2, –proto2 : cette option permet d’utiliser la version 2 du protocole SSH; ceci est la valeur par défaut.

  • -f : cette option oblige SSH à travailler en arrière-plan après la connexion, au lieu d’utiliser un terminal.

Maintenant après avoir configuré l’accès SSH et compris le fonctionnement de plugin check_by_ssh, il ne reste qu’à définir une commande Nagios dans le fichier commands.cfg qui fait appel à ce plugin.

L’exemple ci-dessous définit une commande permettant de contrôler l’espace disque sur une machine Linux à distance. La macro $USER1$ contient le chemin /usr/local/nagios/libexec/ et nous pouvons aussi créer une autre macro par exemple $USER6$ pour spécifier le chemin d’accès à la clé privée SSH /usr/local/nagios/.ssh/id_rsa.

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

Cette commande est ensuite appelée pour définir un service :

define service{ 
    use                        actif-generic 
    host_name                  linux-01 
    service_description        Espace_Disque 
    check_command              check_disque_by_ssh!10%!5%!/! 
}

L’objet de service est de contrôler l’espace disque de la partition / sur la machine linux-01. Le seuil d’avertissement se situe à 10 %, le seuil critique à 5 %. Pour que ce service fonctionne correctement, il faut s’assurer que le plugin check_disk existe dans le serveur linux-01 sous le répertoire /usr/local/nagios/libexec/.

4. Diagnostic et solutions pour les problèmes du contrôle avec SSH

Si vous avez suivi soigneusement les étapes décrites dans la section précédente, tout devrait fonctionner sans aucun problème. Si ça ne marche pas et que vous rencontrez des problèmes pour exécuter le contrôle à distance sur les hôtes avec SSH, suivez la procédure ci-dessous pour trouver la cause racine et résoudre votre problème.

La première étape consiste à vérifier que le serveur distant accepte les connexions SSH depuis le serveur Nagios et qu’il n’y a aucun pare-feu qui bloque la connexion entre les deux serveurs. Nous pouvons utiliser la commande nmap pour scanner le serveur et savoir quel port est utilisé pour le SSH. Utilisez les commandes ci-dessous pour installer nmap sur le serveur Nagios.

Pour une distribution Ubuntu/Debian :

apt-get install nmap

Pour une distribution CentOS :

yum install nmap

L’exemple ci-dessous montre comment utiliser la commande nmap pour interroger la machine 192.168.16.5.

nmap 192.168.16.5

renverra :

Starting Nmap 5.51 ( http://nmap.org ) at 2016-03-13 07:06 EDT 
Nmap scan report for 192.168.16.5 
Host is up (0.0014s latency). 
Not shown: 997 closed ports 
PORT     STATE SERVICE 
22/tcp   open  ssh 
80/tcp   open  http 
5432/tcp open  postgresql 
 
Nmap done: 1 IP address (1 host up) scanned in 0.18 seconds

Si l’hôte accepte la connexion SSH, la commande nmap renvoie l’état ouvert (open) pour le service SSH avec le port qu’il utilise sur la machine. Si aucun serveur SSH n’est configuré sur l’hôte distant, la commande nmap renvoie l’état fermé (closed) pour le service SSH. Dans ce cas, il faut s’assurer que le serveur SSH fonctionne correctement sur la machine. Et si la commande nmap renvoie l’état filtré (filtered) pour le service SSH, elle indique qu’un pare-feu, un dispositif de filtrage dans le réseau bloque et filtre ce port.

Supposant que la machine distante accepte la connexion SSH depuis le serveur Nagios, l’étape suivante est d’essayer de s’authentifier avec l’utilisateur autorisé en utilisant les clés. Pour faire ce test, il faut ouvrir une session avec l’utilisateur nagios au niveau du shell et se connecter au serveur distant en utilisant la commande ssh avec le mode verbose pour afficher les journaux.

su - nagios 
ssh -v 192.168.16.5

Ensuite, vous pouvez analyser les journaux qui seront affichés sur le terminal comme ci-dessous, pour trouver la cause racine de problème.

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: Applying options for * 
debug1: Connecting to 192.168.16.5 [192.168.16.5] port 22. 
debug1: Connection established. 
debug1: identity file /usr/local/nagios/.ssh/identity type -1 
(…) 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: server->client aes128-cbc hmac-md5 none 
debug1: kex: client->server aes128-cbc hmac-md5 none 
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent 
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP 
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent 
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY 
The authenticity of host ’192.168.16.5 (192.168.16.5)’ can’t be 
established. 
RSA key fingerprint is 5b:57:f1:73:e1:89:b3:41:cf:34:12:e8:72:bc:c8:85. 
Are you sure you want to continue connecting (yes/no)? Yes 
Warning: Permanently added ’192.168.16.5’ (RSA) to the list of known hosts. 
debug1: ssh_rsa_verify: signature correct 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug1: SSH2_MSG_NEWKEYS received 
debug1: SSH2_MSG_SERVICE_REQUEST sent 
debug1: SSH2_MSG_SERVICE_ACCEPT received 
debug1: Authentications that can continue: publickey,password 
debug1: Next authentication method: publickey 
debug1: Offering public key: /usr/local/nagios/.ssh/id_rsa 
debug1: Server accepts key: pkalg ssh-rsa blen 277 
debug1: read PEM private key done: type RSA 
debug1: Authentication succeeded (publickey). 
debug1: channel 0: new [client-session] 
debug1: Entering interactive session. 
debug1: Sending environment. 
debug1: Sending env LANG = en_US.UTF-8

Si le client SSH vous demande de saisir un mot de passe, cela signifie que les clés de l’utilisateur nagios ne sont pas configurées correctement. Dans ce cas, vous devez vérifier attentivement les permissions sur les répertoires et fichiers de SSH comme nous l’avons décrit dans la section précédente. Supposant que l’authentification fonctionne correctement et que l’utilisateur nagios a pu se connecter en SSH sur l’hôte distant, il faut ensuite tester l’exécution d’une commande sur la machine à distance et vérifier que le résultat retourné est correct. Par exemple, nous pouvons exécuter à distance la commande uptimesur la machine 192.168.16.5.

su - nagios 
ssh -v 192.168.16.5 uptime 
 
08:30:08 up 37 days, 7:00, 1 user, load average: 0.00, 0.00, 0.00

Ce test montre que l’utilisateur nagios a pu exécuter une commande à distance sur la machine, même s’il remplace la commande ssh par le plugin check_by_ssh, elle devra fonctionner correctement. Si cela ne fonctionne pas, vérifiez que le plugin est bien compilé et installé sur le serveur Nagios.

su - nagios  
/usr/local/nagios/check_by_ssh -H 192.168.16.5 -c "/usr/local/nagios/check_procs"
-i /usr/local/nagios/.ssh/id_rsa 
 
PROCS OK: 70 processes

Si le dernier test est concluant, cela signifie que vous n’avez aucun problème avec le contrôle à distance en utilisant le protocole SSH. Si vous avez encore des problèmes avec le fonctionnement des contrôles, vous devez vérifier la configuration de votre serveur Nagios, surtout la définition des commandes et services.