Gérer la configuration du client SSH

Jean Baptiste FAVRE

février 2009

Introduction

On ne présente plus SSH. Il est utilisé partout (ou presque), afin d'accéder à une machine à distance et de manière sécurisée. Sa configuration est souple, ce qui fait qu'il peut être employé dans des scripts automatisés. Enfin, le support de l'authentification par clefs privée permet de se passer des mots de passe. Là encore, très utile pour les scripts automatiques.

Néanmoins, sa configuration par défaut ne convient plus pour de très grands parcs de serveurs. En effet, par défaut, toutes les empreintes RSA sont stockées dans un seul et même fichier: ~/.ssh/known_host.

De plus, toujours par défaut le nom d'hôte est stocké sous forme de hash, ce qui rend la lecture du fichier particulièrement mal-aisée.

Enfin, dans les architectures bien tenue, la même clef ne devrait jamais être employée pour tous les serveurs. En cas de compromission d'une clef, seule une partie de l'architecture est vulnérable.

Principe

Tâchons de remédier à tout cela. Pour cela, nous allons utiliser le fichier de configuration utilisateur ~/.ssh/config. Plus précisément, nous allons gérer les différents groupe de machines en fonction du nom de domaine.

Les exemples suivants partent du principe que vous devez accéder à 3 groupes de machines:

Afin d'augmenter le niveau de sécurité, nous utiliserons des clefs différentes en fonction des groupes de machines. Idéalement, il faudrait avoir un login par administrateur.

Création des clefs SSH

Avant tout, organisons nos fichiers. ,Pour ma part, j'ai adopté la structure suivante:

Strucutre de fichiers et répertoires
$ tree ~/.ssh
.ssh
|-- keys
`-- known_hosts

Commençons donc par créer les clefs SSH. Nous aurons besoin de 3 clefs, une par groupe de serveurs:

Création des clefs
$ ssh-keygen -b 4096 -t rsa -C clef_test2
Generating public/private rsa key pair.
Enter file in which to save the key (/home/admin/.ssh/id_rsa): /home/admin/.ssh/keys/grp2.domain.tld
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/admin/.ssh/keys/grp2.domain.tld.
Your public key has been saved in /home/admin/.ssh/keys/grp2.domain.tld.pub.
The key fingerprint is:
e0:1b:e9:7e:0e:8f:0c:35:4b:f7:6f:c7:22:33:86:12 clef_test2
The key's randomart image is:
+--[ RSA 4096]----+
|                 |
|                 |
|      .          |
|     . o         |
|      B S        |
|     +E* .       |
|    . =. ..  .   |
|     +.+o =.o o  |
|      ++o. =.o   |
+-----------------+

Vous pouvez retrouver certains détails de la création de clef dans le fichier contenant la clef publique:

Exemple de clef publique
$ cat /home/admin/.ssh/keys/grp2.domain.tld.pub
ssh-rsa AAAAB3N.....= clef_test2

Une fois les 3 clef créées, voici la structure de fichiers:

Structure des fichiers et répertoires après la création des clefs
$ tree .ssh/
.ssh/
|-- config
|-- keys
|   |-- domain.tld
|   |-- domain.tld.pub
|   |-- grp1.domain.tld
|   |-- grp1.domain.tld.pub
|   |-- grp2.domain.tld
|   `-- grp2.domain.tld.pub
`-- known_hosts

Le fichier .ssh/config contiendra toutes les directoves de configuration nécessaires, notamment le choix du login et/ ou de la clef.

Déploiement des clefs SSH

Les clefs créées doivent ensuite être déployées. Pour cela, la commande ssh-copy-id est votre amie:

Déploiement de clefs SSH
for srv in 1 2 3 4 5
do
    ssh-copy-id -i ~/.ssh/keys/domain.tld.pub admin@srv0$srv.mondomaine.tld
done

Configuration du client SSH

Il est important d'organiser la configuration demanière à ce que le cas le plus spécifique corresponde en premier. Dans notre exemple, matcher sur srv0*.domaine.tld permet de prendre en compte srv01.domain.tld et srv09.domain.tld, mais également srv02.grp1.domain.tld car le caractère * permet de remplacer un nombre indéterminé de caractères. Il faut donc préciser que nous souhaitons exclure les serveurs des groupes grp1 et grp2.

Nous aurions également pu employer le ? qui ne remplace qu'un seul caractère.

L'option HashKnownHosts no permet, elle, d'obtenir un fichier known_hosts plus lisible en conservant le nom d'hôte ainsi que l'IP en clair.

~/.ssh/config
HashKnownHosts no

Host !*.grp1.domaine.tld, !*.grp2.domaine.tld, srv0*.domaine.tld
    user admin
    IdentityFile ~/.ssh/keys/domaine.tld
    UserKnownHostsFile=~/.ssh/known_hosts/domaine.tld

Host *.grp1.domaine.tld
    user admingrp1
    IdentityFile ~/.ssh/keys/grp1.domaine.tld
    UserKnownHostsFile=~/.ssh/known_hosts/grp1.domaine.tld

Host *.grp2.domaine.tld
    user admingrp1
    IdentityFile ~/.ssh/keys/grp1.domaine.tld
    UserKnownHostsFile=~/.ssh/known_hosts/grp1.domaine.tld

Host *
    User root
    UserKnownHostsFile=~/.ssh/tmp_known_hosts

Ce fichier ~/.ssh/config permet de spécifier les options. Du coup, plus de besoin de les indiquer dans la ligne de commande.

Test de connexion
$ ssh srv02.mondomaine.tld
The authenticity of host 'srv02.mondomaine.tld (10.0.0.101)' can't be established.
RSA key fingerprint is 25:b4:ed:02:81:2a:5f:bc:24:c8:bc:37:fb:d7:c8:5a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'srv02.mondomaine.tld,10.0.0.101' (RSA) to the list of known hosts.
Linux xps-101 2.6.26-2-amd64 #1 SMP Thu Nov 5 02:23:12 UTC 2009 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Feb  7 14:57:24 2010 from 10.0.0.15
admin@srv02.mondomaine.tld:~$

Il est évidemment possible de spécifier bien d'autres options. Pour cela, rien de mieux qu'une lecture de man ssh_config.

Format

Ce document est disponible aux formats suivants:

À propos de Jean Baptiste FAVRE

Je suis responsable d'exploitation dans le domaine de l'hébergement. Je travaille, entre autres, sur la virtualisation et l'amélioration des performances web. De temps en temps, j'arrive à décrocher de mon clavier pour lire un bon bouquin en écoutant de la musique.

License

Creative Commons License Cette publication est publiée sous contrat Creative Common by-nc-sa

Valid XHTML 1.0 Strict |  Valid CSS |  contrat Creative Common by-nc-sa

Table des matières

  1. Introduction
  2. Principe
  3. Création des clefs SSH
  4. Déploiement des clefs SSH
  5. Configuration du client SSH
  6. Format
  7. À propos ...
  8. License