Page History

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.

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

• les Les checks linux basés sur SSH.
• la 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 connexion sécurisé, basé sur un échange de clés privées et clé clés 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

Anchor
GenererNouvelleCleSSH GenererNouvelleCleSSH

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 Pour différencier des connexions entre différents clients
• dans Dans le cas d'un cluster Mongo : l'installateur utilisateur "root" doit pouvoir se connecter aux différents nœuds afin de garantir la mise à jour de ces serveurs
• dans Dans le cas ou où 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]-----+

Anchor
CopieCleSSHDemonShinken CopieCleSSHDemonShinken

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.

[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.

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 utilisés 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 décrite dans le chapitre suivant : 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.

Autorisation

du service Grafana vers un serveur Shinken

Dans le cas où on utilise l'outil Grafana, Graphite va avoir besoin de se connecter Si vous utilisez le service Grafana, celui-ci à besoin d'accéder à 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:

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

. La mise en place des clés SSH dans ce cadre est expliqué dans cette page : Grafana 7.4.2

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]#

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:

• d'avoir une clé SSH pour l'utilisateur "root" sur le serveur central qui sera autorisé sur tous les serveurs Shinken
  .
  
  • La clé publique devra être copiée sur tous les serveurs Shinken, pour l'utilisateur "root".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
  • , lors d'une installation ou d'une mise à jour.
  • Cela facilite la configuration, la maintenance et la mise à jour.
    
    
• d'avoir une seule clé SSH sur l'utilisateur shinken, dans le but de l'utiliser sur toutes les machines supervisées par SSH.
  • La
  • la clé privée pourra être copié copiée sur tous les pollers Pollers : Une une seule et même clé publique a à autoriser sur tous les équipements à superviser.
  • la La clé publique sera à copier sur tous les équipements de votre parc que vous souhaitez superviser par SSH.
  • Pour les tunnels SSH de connexion à Mongo.

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 d'avoir une clé SSH pour l'utilisateur "root" , dédié à votre infrastructure :sur le serveur central qui sera autorisé sur tous les serveurs Shinken.
  
  • La
  • la clé publique devra être copié copiée sur tous les serveurs Shinken, pour l'utilisateur "root".
  • C'est obligatoire dans le cas d'un cluster Mongo pour les connexions à mongo/cluster Mongopouvoir effectuer les mises à jour, lors d'une installation ou d'une mise à jour.
  • Cela facilite la configuration, la maintenance et la mise à jour.
    
    
• d'avoir une clé SSH sur l'utilisateur shinken
  • Pour pour les checks de supervision shinken ( sup de sup )
  • Pour les tunnels SSH de connexioncela facilite la configuration, la maintenance et la mise à jour à Mongo
    
    
• Une clé par client
  • La clé privée pourra être copié sur tous les pollers Pollers qui supervisent les équipements de ce client → une seule clé publique à copier sur les équipements à superviser.
  • cette 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.