inetdoc.net

Génération automatisée de clé pour SSH sur un commutateur Cisco

Pour qui à l'habitude de l'arborescence des systèmes Unix, la gestion du système de fichiers de l'IOS de Cisco est pour le moins «singulière». Ce billet illustre les mésaventures rencontrées dans la gestion des configuration des commutateurs 2960 et 3560. Au départ, mon objectif est de rendre systématique l'utilisation de SSH pour l'accès à l'interface de configuration (CLI) des commutateurs des salles de travaux pratiques. Dans ce but, j'ai créé des patrons de fichiers de configuration dans lesquels figurait la commande de génération de clé. Une fois le commutateur relancé, la première tentative de connexion échoue. Mauvaise surprise ! Voyons si la génération de clés RSA peut être déclenchée automatiquement.

Tout d'abord, les choses qui fâchent

Comme annoncé, tout débute par une grosse déconvenue :

$ ssh admin@sw09-213.infra.stri
ssh: connect to host sw09-213.infra.stri port 22: Connection refused

En redémarrant le commutateur avec le cordon console connecté et l'outil minicom lancé, on relève le message suivant :

% Rsa keys can't be generated by the startup configuration

Après moultes recherches, notamment sur Cisco Technical Support Forum, l'argument qui explique ce comportement s'appuie sur le fait que la génération de clé est une opération unique effectuée lors du déploiement d'un équipement. Le premier message d'erreur ci-dessus est dû au fait que la clé n'a pas été générée et/ou sauvegardée. Or, dans un contexte de travaux pratiques, les configurations sont constamment effacées et réécrites. Nous sommes donc amenés à la question du lieu de stockage de clé.

Au niveau CCNA on apprend que, sur un commutateur, tout est stocké en mémoire flash. Nous devons donc observer le contenu de cette mémoire flash parallèlement aux opérations sur les clés.

sw09-213#sh flash: 

Directory of flash:/

    2  -rwx       10227  May 30 2014 11:26:18 +02:00  recovery-confg
    3  -rwx         556   Mar 1 1993 01:00:39 +01:00  vlan.dat
    4  -rwx    11792247  May 27 2014 22:34:31 +02:00  c2960-lanbasek9-mz.150-2.SE6.bin
    5  -rwx        3096  May 30 2014 11:46:43 +02:00  multiple-fs
    6  -rwx           5  May 30 2014 11:46:43 +02:00  private-config.text
    7  -rwx       16165  May 30 2014 11:46:43 +02:00  config.text

32514048 bytes total (20688896 bytes free)

Les deux fichiers de configuration sont marqués en couleur dans la copie d'écran ci-dessus.

• Le fichier config.text contient la configuration du commutateur utilisée lors d'un redémarrage.
• Le fichier private-config.text ne contient pas grand chose pour l'instant ; vu sa taille.

Allons-y pour la génération de clé. J'avais publié un billet «façon antisèche» sur cette question il y a quelques temps déjà : Compte utilisateur local & accès SSH sur un équipement Cisco. On reprend la démarche après avoir vérifié qu'aucune clé n'est déjà présente dans la configuration courante.

sw09-213#sh crypto key mypubkey all
sw09-213#
sw09-213#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
sw09-213(config)#crypto key generate rsa label SSH-KEY modulus 4096
The name for the keys will be: SSH-KEY

% The key modulus size is 4096 bits
% Generating 4096 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 504 seconds)

000023: May 30 14:54:30.551 MET: %SSH-5-ENABLED: SSH 2.0 has been enabled

On remarque que le service SSH s'est activé immédiatement après la création de clé. On peut aussi visualiser le résultat de l'opération en rappelant la commande sh crypto key mypubkey all.

Si on réinitialise le commutateur maintenant, tout le travail de génération de clé sera perdu sachant qu'aucune sauvegarde n'a encore été effectuée. C'est là que la bizarrerie commence. La seule commande de sauvegarde dont nous disposons est la suivante :

sw09-213#copy run start
Building configuration...
[OK]
sw09-213#sh flash: | incl config
    7  -rwx        6820  May 30 2014 15:00:54 +02:00  private-config.text
    8  -rwx       16165  May 30 2014 15:00:54 +02:00  config.text

Alors que le fichier config.text n'a pas changé de taille, le fichier private-config.text est passé de 5 à 6820 octets. Notre clé est stockée dans ce dernier fichier. La commande copy running-config startup-config copie les clés dans la mémoire flash: en plus de la configuration courante du système.

L'effacement fonctionne comme la copie. La commande erase startup-config efface les deux fichiers private-config.text et config.text. Au redémarrage suivant, le commutateur a perdu sa configuration et son jeu de clés RSA. Malheureusement, il semble qu'il soit impossible de préserver une copie de sauvegarde du fichier private-config.text. Seul le fichier config.text peut être recopié en mémoire flash.

Une fois que les manipulations sont terminées, l'utilisation de la commande erase startup-config est recommandée dans tous les supports de travaux pratiques des curriculums Cisco. Il semble donc que nous soyons dans l'impasse.

Kron à la rescousse

Fort heureusement, nous pouvons contourner la difficulté grâce au service de planification des tâches baptisé kron. Bien entendu, ce service est loin d'offrir les possibilités d'un cron Unix. Sur les modèles de commutateurs 2960, il est seulement possible d'exécuter des commandes dites globales. Il n'est pas possible d'entrer directement dans le terminal de configuration.

Cependant, il est possible de charger un fichier contenant une suite de commandes de configuration via TFTP ou d'autres protocoles comme FTP ou HTTP. Les commandes contenues dans le fichier sont exécutées directement si la destination du transfert est le niveau d'exécution courant : system:/running-config.

Voici une copie de la partie intéressante du patron de configuration d'un commutateur.

!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!~~~~~~~~~      kron
!
file prompt quiet
!
kron occurrence crypto-key in 3 oneshot
 policy-list crypto-key
!
kron occurrence backup-startup in 30 oneshot
 policy-list backup-startup
!
kron policy-list crypto-key
 cli copy tftp://cooper/crypto-key-confg running-config
!
kron policy-list backup-startup
 cli delete /force flash:recovery-confg
 cli copy startup-config flash:recovery-confg
 cli copy running-config startup-config
!
end

On relève deux suites d'instructions.

• La première phase baptisée crypto-key est exécutée un seule fois 3 minutes après l'initialisation du commutateur. C'est ce «script» qui sert à provoquer la génération de clé.

  $ cat /srv/tftp/crypto-key-confg 
  ! Génération de clés RSA pour SSH
  crypto key generate rsa label SSH-KEY modulus 4096
  !
  end

• La seconde phase baptisée backup-startup est aussi exécutée une seule fois au bout de 30 minutes après l'initialisation. Son but est de sauvegarder le jeu de clés RSA.

Attention ! Le choix des temps avant exécution des commandes n'est pas anodin. Il faut être sûr que le lien montant est actif et que le serveur TFTP est joignable avant de lancer un téléchargement. On tient compte notamment, du temps de convergence du protocole Spanning Tree.

Au final, on obtient les informations suivantes dans les journaux système. Le jeu de clés a bien été généré et il est enfin possible d'accéder au commutateur via SSH.

000020: Jun  2 18:58:36.092 MET: %SSH-5-ENABLED: SSH 2.0 has been enabled
000021: Jun  2 18:58:43.004 MET: %SYS-5-CONFIG_I: Configured from tftp://cooper/crypto-key-confg by admin on console

Cette méthode fonctionne aussi sur les commutateurs Cisco de la gamme supérieure comme les 3560 ou 3750.

Pour conclure, j'espère que ce billet pourra servir à quelques administrateurs d'équipements réseau et leur fera économiser un peu de temps pour faire des choses plus intéressantes. Avec ce genre de «Hack à 2€cts» nous sommes encore bien loin du Software Defined Network.