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 mongo des différents démons et modules.

Connexion distante, et déploiement des clés SSH pour se connecter

Principe des connexions SSH

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

Un utilisateur local ( qui sera dans notre cas de 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 Mongo
  • 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 à utililiser 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 renseigné le bon chemin dans les fichiers de configuration Shinken



Autorisation d'un serveur Shinken vers un autre serveur Shinken

Dans le cas d'une connexion à une a base Mongo ou pour la supervision de Shinken

Dans le cas d'une connexion vers une base Mongo, vous pouvez utiliser l'utilisateur "shinken" pour établir les tunnels SSH. La méthode est la même, que le serveur mongo soit en local ( 127.0.0.1 ou l'adresse du serveur ) ou 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 :

  • afficher la clé publique de l'utilisateur shinken dans la sortie standard
  • se connecter en ssh au serveur distant avec le compte root
  • utiliser la sortie standard pour ajouter la clé dans les clés autorisé pour se connecter à l'utilisateur "shinken"

Le mot de passe de l'utilisateur root du serveur distant vous sera demandé si vous n'avez pas copié la clé ssh publique de l'utilisateur root du serveur démon Shinken.

Dans le cas d'un cluster Mongo

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

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 consitutant 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é pour configurer les tunnels SSH depuis les fichiers de configuration des démons/modules.

Autorisation d'un serveur Shinken vers un serveur tiers ( supervision )

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ètre de ce serveur :


[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 d'un serveur Grafana vers un serveur Shinken

Dans le cas où on utilise l'outil Grafana, Graphite va avoir besoin de se connecter à la base MongoDB.

  • Il est conseillé de protéger la connexion dans un tunnel SSH. 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.
  • Pour plus de détail sur la connexion de Grafana avec Shinken, allez voir la page Grafana.

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 bon déploiement de la clé SSH, il faut lancer depuis le serveur source :

[root@shinken ~]# su - shinken
[shinken@shinken ~]# ssh shinken@AdresseServerDistant -i /var/lib/shinken/.ssh/id_rsa

La connexion doit s'établir avec succès et sans demander d'authentification.

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 autorisé 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.