Création automatique lors de l'installation

Lors de l'installation de Shinken Enterprise sur un serveur Linux, l'installation créé automatiquement une clé SSH pour l'utilisateur shinken.

Chemin clé privée

/var/lib/shinken/.ssh/id_rsa

Chemin clé publique

/var/lib/shinken/.ssh/id_rsa.pub

Chiffrement

RSA

Taille de la clé

2048

C'est cette clé qui sera utilisée par défaut pour les connexions suivantes :

  • Les checks linux basés sur SSH.
  • La sécurisation des connexions MongoDB des différents démons et modules.

Connexion distante et déploiement des clés SSH

Principe des connexions SSH

Le SSH ( Secure SHell ) est un protocole de connexions sécurisé, basé sur un échange de clés privées et clé publiques. Il s'agit d'un chiffrement asymétrique.

Un utilisateur local ( qui sera dans notre cas l'utilisateur shinken ) utilise sa clé privée pour se connecter à un serveur distant avec un compte distant, qui a autorisé la clé publique de cet utilisateur.

Dans le cas d'une connexion vers un serveur démon ou module Shinken, il faudra utiliser comme utilisateur distant celui qui est créé par défaut : shinken


Utilisation et génération des clés SSH

L'utilisateur "shinken" dispose déjà d'une clé SSH qui pourra être utilisée pour se connecter à divers serveurs tels que :

  • D'autres serveurs Shinken
  • Le même serveur Shinken pour utiliser un tunnel SSH pour la base MongoDB
  • Un équipement supervisé

Vous pouvez être amené à générer de nouvelles clés :

  • Pour différencier des connexions entre différents clients
  • Dans le cas d'un cluster Mongo : l'installateur "root" doit pouvoir se connecter aux différents nœuds afin de garantir la mise à jour de ces serveurs
  • Dans le cas ou votre clé a été corrompue/volée

La génération d'une nouvelle clé se réalise avec l'utilisateur qui va utiliser la clé SSH ( dans cet exemple il s'agit de l'utilisateur shinken ) :

[root@shinken-server ~]# su - shinken
[shinken@shinken-poller ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/var/lib/shinken/.ssh/id_rsa):
/var/lib/shinken/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /var/lib/shinken/.ssh/id_rsa.
Your public key has been saved in /var/lib/shinken/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Dti4LZ9+IGe6NWBbIFRjpKed4g3zzYfTx/jDfJ9iu7E shinken@shinken-poller
The key's randomart image is:
+---[RSA 2048]----+
|  .o=            |
| . o .           |
|  o o            |
|   = *           |
|  = B + S        |
| . B.O+= o       |
|  . *=O.=oo .    |
|    .+ =.o+ +o . |
|    .o+.  .+E=o  |
+----[SHA256]-----+


Lors de la génération d'une clé alors qu'une clé existe déjà, il vous sera demander d'écraser la clé précédente. Si vous ne souhaitez pas écraser la clé mais en rajouter une :

  • Lors de la génération de la clé, utiliser l'option "-f ~/.ssh/nom_de_la_nouvelle_cle".
  • Pour l'utiliser en ligne de commande, pensez à utiliser l'option "-i chemin_de_la_clé"
  • Celle-ci devra être spécifié dans l'hôte/modèle d'hôte (Ex. : linux)
  • Penser a renseigner le bon chemin dans les fichiers de configuration Shinken



Autorisation d'un serveur Shinken vers un autre serveur Shinken

Dans le cas d'une installation de base

Dans le cas d'une connexion vers une base Mongo, ou d'un serveur shinken vers un autre, vous pouvez utiliser l'utilisateur "shinken" pour établir les tunnels SSH. La méthode est la même, que le serveur MongoDB soit en local ( 127.0.0.1 ou l'adresse du serveur ) ou soit un serveur distant.

L'utilisateur "shinken" ne dispose pas de mot de passe. Il n'est donc pas possible de passer par la commande "ssh-copy-id", il faut utiliser le compte root pour cela.


[root@shinken-server ~]# cat /var/lib/shinken/.ssh/id_rsa.pub | \
ssh root@groy-dev-02-08 \
"tee -a /var/lib/shinken/.ssh/authozied_keys"

Cela aura pour effet :

  • D'afficher la clé publique de l'utilisateur shinken dans la sortie standard
  • Puis de se connecter en SSH au serveur distant avec le compte "root" ( Si l'utilisateur "root" n'a pas sa clé publique déjà autorisée sur le serveur distant, le mot de passe "root" du serveur distant vous sera demandé )
  • Et enfin d'utiliser la clé présente dans la sortie standard pour ajouter la clé publique dans les clés autorisée pour se connecter à l'utilisateur "shinken"


Dans le cas d'un cluster Mongo

Pour les clusters Mongo, l'utilisateur "root" du serveur Shinken Central doit accéder à tous les nœuds du cluster Mongo avec les droits "root", afin de garantir la mise à jour de tous les nœuds.

Si votre utilisateur "root" ne dispose pas de clé SSh, générez une nouvelle clé SSH


Depuis le serveur Shinken central utilisez le compte "root" pour copier votre clé publique ( à faire avec tous les serveurs constituant le cluster Mongo ) :

[root@shinken-server ~]# ssh-copy-id root@AdressServeurMongo
The authenticity of host 'AdressServeurMongo(AdressServeurMongo)' 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
root@AdressServeurMongo's password:  XXXXXXXX 
 Now try logging into the machine, with "ssh 'AdressServeurDistant'", and check in:
  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.


Vous pouvez utiliser cette clé également pour configurer les tunnels SSH depuis les fichiers de configuration des démons/modules.

Autorisation d'un serveur Shinken vers un serveur tiers ( pour le superviser )

Pour autoriser une clé d'un utilisateur "shinken" vers un serveur distant, il faut se connecter sur le serveur Shinken en tant que l'utilisateur "shinken" et copier la clé SSH vers le serveur distant. Voici les paramètres de ce serveur utilisés dans cet exemple :

  • Adresse : AdressServeurDistant
  • Utilisateur : UtilisateurDistant
  • Mot de passe : XXXXXXXX ( si vous n'avez pas le mot de passe de l'utilisateur distant, mais celui de l'utilisateur root, utiliser la méthode suivante : Autorisation d'un serveur démon vers un autre serveur démon ) en remplaçant l'utilisateur "shinken" par votre utilisateur


[root@shinken-server ~]# su - shinken
[shinken@shinken-poller ~]#  ssh-copy-id  AdressServeurDistant
The authenticity of host 'AdressServeurDistant (AdressServeurDistant)' 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
shinken@remote_host's password:  XXXXXXXX 
 Now try logging into the machine, with "ssh 'AdressServeurDistant'", and check in:
  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.


Ceci aura pour effet de copier le contenu de la clé publique /var/lib/shinken/.ssh/id_rsa.pub dans le fichier ~/.ssh/authorized_keys de l'utilisateur du serveur distant.


Pour superviser un élément par SSH, il est conseillé de prendre une clé privée de l'utilisateur shinken car c'est l'utilisateur qui sera utilisé par le poller pour lancer les checks.



Autorisation d'un serveur Graphite/Grafana vers un serveur Shinken/MongoDB

Dans le cas où on utilise l'outil Grafana, Graphite va avoir besoin de se connecter à la base MongoDB pour faire le lien entre les noms d'éléments et les uuid.

  • Il est conseillé de protéger la connexion dans un tunnel SSH.
  • Pour plus de détail sur la connexion de Grafana avec Shinken, allez voir la page Grafana.


Graphite étant hébergé par le service apache, il n'a donc pas accès au répertoire /var/lib/shinken et donc pas accès à la clé SSH /var/lib/shinken/.ssh/id_rsa.

Deux solutions d'offrent à vous:

  • générer une nouvelle clé SSH pour apache/graphite.
    • Il faudra ajouter cette nouvelle clé publique sur le/les serveurs MongoDB
    • Cette clé sera indépendante et non impacté par un changement de clé SSH sur l'utilisateur "shinken"
  • utiliser la clé SSH de l'utilisateur "shinken" présent sur le serveur
    • La clé publique est surement déjà présente sur les serveurs MongoDB

    • Il faut copier la clé privée et changer les droits pour l'utiliser et la maintenir à jour en cas de changement

      cp /var/lib/shinken/.ssh/id_rsa /opt/graphite/conf/id_rsa
chown apache:apache /opt/graphite/conf/id_rsa



Attention : un lien symbolique entre les deux fichiers ne fonctionnera pas, car apache n'a pas les droits d'aller lire le fichier originel.


Test de connexion

Pour tester le déploiement d'une clé SSH il faut pouvoir se connecter depuis l'utilisateur qui dispose de la clé privée vers l'utilisateur sur le serveur distant. La connexion doit s'établir avec succès et sans authentification. Voici un exemple de connexion depuis l'utilisateur "shinken" vers l'utilisateur "shinken" d'un serveur distant :

[root@ServerShinken~]# su - shinken
[shinken@ServerShinken~]# ssh shinken@AdresseServerDistant -i /var/lib/shinken/.ssh/id_rsa
Last login: Tue Oct 19 15:53:19 2021 from ServerShinken
[shinken@AdresseServerDistant]#


Lors de la première connexion à un serveur, la commande SSH vous affiche l'empreinte de la clé SSH, vous permettant de vérifier auprès de l'administrateur de ce serveur que c'est bien la bonne clé SSH qui est utilisé pour chiffrer les communications depuis le serveur distant vers le serveur local. Une fois cette empreinte enregistré, cela ne vous sera plus redemandé.


Bonnes pratiques

Dans le cas d'une installation Shinken dédié

Si vous disposez de plusieurs serveurs Shinken et que vous superviser uniquement votre infrastructure, il est possible de

  • avoir une clé SSH pour l'utilisateur "root" sur le serveur central qui sera autorisé sur tous les serveurs Shinken
    • cela facilite la maintenance et la copie de fichiers lors de la configuration
    • C'est obligatoire dans le cas d'un cluster Mongo pour pouvoir effectuer les mises à jour
    • Cette clé peut être utilisée pour établir les tunnels SSH pour Mongo
  • avoir une seule clé SSH sur l'utilisateur shinken
    • la clé privée pourra être copié sur tous les pollers : Une seule et même clé publique a autoriser sur tous les équipements à superviser
    • la clé publique sera à copier sur tous les équipements de votre parc que vous souhaitez superviser par SSH

Dans le cas d'une installation Shinken multi clients

Si votre installation vous permet de superviser plusieurs clients, il est possible d'utiliser plusieurs clés SSH afin de séparer les connexions :

  • Une clé SSH pour l'utilisateur "root", dédié à votre infrastructure :
    • la clé publique devra être copié sur tous les serveurs Shinken, pour l'utilisateur "root"
    • pour les connexions à mongo/cluster Mongo
    • pour les checks de supervision shinken ( sup de sup )
    • cela facilite la configuration, la maintenance et la mise à jour
  • Une clé par client
    • La clé privée pourra être copié sur tous les pollers qui supervisent les équipements de ce client → une seule clé publique à copier sur les équipements à superviser
    • cette clé privée sera à renseigner dans les modèles/hôtes de la configuration

Cela permet de cloisonner les connexions entre votre infrastructure et vos clients. Cela permet aussi de pouvoir changer de clé SSH en cas de vol ou de corruption en limitant les impacts sur les autres clients.